I’d like to request a super easy-to-implement feature that apparently was already the case before 2021… namely, about this post:
My request is to simply add a “sink input” boolean property within proximity prompts, to ensure proximity prompts do NOT sink contextactionservice inputs. I’ve been using contextactionservice to make the controls more seamless and easier, but finding out proximity prompts sinks input specifically for contextactionservice has been a great inconvenience… and I’m honestly not sure why this wasn’t done in the first place.
I tried that first, but when i go there, the “New Topic” button is greyed out… and this specific request kind of falls in line with scripting, since in order to get around this, I’d need to create UIS support for a single key, when all other keys use CAS. Another feature upgrade that would solve my specific problem (more directly, I might add) would be to allow for proximity prompts to have a nil KeyCode (ie: no keys can trigger it), but I figure that would be more niche than me original request.
I would think, as someone playing a game, that a prompt would sink input, just as much as typing in Chat does. This seems to be what people are agreeing on in the thread you linked, even the author of the Bug Report. I really do not believe most players will intend to use a global action simultaneously with a Proximity Prompt, unless it is an intentional mechanic.
Also, this won’t be in their actual system for Feature Requests. They are not paid to lurk the other Forum categories and it probably isn’t high on their personal list of priorities to do so.
I’d say if anyone wants to make a quicktime event in conjunction with skill presses on completely modifiable keybinds, this would apply, but I guess Roblox devs aren’t really rushing to try new things, and the few who are figure out ways around the limitations…
I would think this is because most people use Prompts as something to interact with an Object, making it a part of the 3D world, because that’s sort of what they’re intended for. They’re intended to mimic prompt systems that allow players to walk up to stuff and interact with them.
Although, I don’t see why you can’t have your actions also tied to on-screen prompts when these QTEs occur. I don’t know the specifics of your gameplay, but it’s just a suggestion if you’re already using ContextActionService. If you really wanted to use Proximity Prompts, you could set a super long HoldDuration and make it use a custom UI, and then use PromptButtonHoldBegan and PromptButtonHoldEnded as replacements for UserInputState.Begin and UserInputState.End.
For my game, what I needed ultimately was a way to have a nil input for proximity prompts because in my game you can change all your keybinds - including removing them - and i wanted to still show the proximity prompt even if there was a nil input… but the way proximity prompts work now, if you have a “nil” input on load, the prompts simply don’t show up because you can’t have a nil input for them.
A way around this is to set the input as a random keycode, and in the prompt triggered code, check whether the prompt key exists in the keybind table (and don’t trigger the prompt if it doesn’t). Since inputs are customizable in my game, this gets into issues of: if the random keycode i arbitrarily picked is bound to something else, then that something will not trigger because the prompt sinks the input whether or not the trigger executed anything other than “return”.
Either allowing nil inputs or not sinking inputs when a prompt triggers would “solve” my problem, and I figured not sinking inputs was more likely to be agreed with, but I stand corrected.
My way around it for now was to just assign the keycode to a completely unused and unassignable key (ie: F12), but idk how long that will be viable…
What would be the point of that to the player? Why would they want a useless GUI on screen telling them to press nothing to do something? If it’s important to tell them an action would have been possible if they didn’t unbind a key, maybe it shouldn’t even be possible to completely unbind it in the first place.
