Reproduction Steps
By creating a ProximityPrompt and binding an action through ContextActionService to a key such as E (Enum.KeyCode.E), you will notice that when the prompt appears, the action assigned to the KeyCode E will not fire at all.
Expected Behavior
I expect the key to work, as this is a regression that first appeared today.
Actual Behavior
The action never fires. This was not an issue before, and is currently impacting our games negatively.
Workaround
The current work around is to have the action play whenever a prompt is triggered. This is not ideal, as the action should still work through ContextActionService as it did before.
Issue Area: Engine Issue Type: Other Impact: High Frequency: Constantly Date First Experienced: 2021-06-14 00:06:00 (+00:00)
Something that was also changed today that caused parts of our game to break is that ProximityPrompts now register the input as already processed for UserInputService events when it did not before. This specifically seems like a valid and intentional bug fix to me, but it can definitely break games relying on older behavior and should have been announced beforehand.
It’s true, in part, developers often try to avoid this problem with other methods, but not always everything can be bypassed ContextActionService has quite sporadic problems with logging or any action in this matter
We apologize for not making this change in behavior clear ahead of time. It was an intentional change, as we expect user input to prioritize a nearby ProximityPrompt over a global action triggered with ContextActionService.
For a workaround, you may be able to use UserInputService instead of ContextActionService to detect this input even when the input key conflicts with a nearby ProximityPrompt.
In order for us to evaluate supporting the old behavior, can you share the use cases where this behavior is desired? Do you want the ProximityPrompt to trigger, and also another action to happen when the user presses a certain key?
For what it’s worth, I would expect e.g. the attack key not to work if it was the action key for a nearby prompt. This behavior makes way more sense to me and I imagine if it was changed to what OP wants I would end up fighting with it.
I agree here. If I see a proximity prompt on my screen for the “E” key, and I press the “E” key only for the proximity prompt to not trigger and instead something entirely different happens, that would be confusing to me as a player - it’s bad UX.
Proximity prompts overriding contextactionservice bindings of the same key forces good ux design choices.
Sorry if this post might come as conflicting with the original bug report (it most likely is), though I believe, after you’ve mentioned about how this was intentional, that this should not be classified as a bug. Using UserInputService can work just as fine. (main reason ContextActionService was being used in my use case was that it’s a good way to shorten the code, as only one line is needed to register the actions for all key codes and a mobile button)
I made this bug report because I believed this was not an intentional change since it could be game breaking in a lot of cases (such as was in ours partially), but as clarified that it was indeed intentional, this bug report no longer stands.
I’ve already done the necessary changes on my game, and I’d recommend that anyone facing the same issue also does. (moving to UserInputService for example)