An annoyance I frequently encounter as a player is that rotating or zooming out my camera while holding down a ProximityPrompt input may cause the prompt to hide and my input to be cancelled.
This feels bad because my perception is that when I am holding the input I am “locked in” to the interaction provided my character or the prompt object doesn’t move.
This is especially annoying in prompts that have a long hold duration, as I will get restless and want to do things like look around to see what’s happening around me while I’m waiting. I will often do this unconsciously. But that cancels my input and now I need to start the whole prompt from scratch again.
It would improve my experience as a player if prompts were more reliably locked in when I hold an input. And as a developer, to achieve this behavior now I have to reimplement the whole ProximityPrompt system which is silly, I wish it were more of a one-click kinda thing (if not the default).
I am not saying prompts should ignore game state. If the actual game state changes, such as the player character moving or the object moving in a way that would invalidate the prompt, then as a player I would expect the prompt to be cancelled.
The issue is simply that there are certain pieces of user input (mainly camera input) that are unconsciously perceived to be “free”, which have no effect on the game state, yet which are always treated by ProximityPrompts as if they are super important.
While this would be a good quality-of-life improvement, proximity prompts ultimately need to be completely predictable for developers, meaning they have a hard cut-off when line-of-sight(?) or distance is broken, hence why this feature request isn’t… apt. You can achieve your desired behaviour by creating your own system
The whole point of their feature request is for Roblox to implement a first-party way of doing this, not to look for overkill workarounds that they already mention in the OP.
ProximityPromps are already overkill engine bloat. As I said, they must act predictable which means rudimentary behavior, simple visibility and distance check.
You are kind of right, but this is a genuine UX problem that happens in many different experiences.
In all of the games I’ve played, I have never seen a game design where it was like “it is important to keep the camera looking at the prompt while you are holding down the input”. It’s simply not a thing that seems to matter very often, if at all. People don’t design for it.
So It seems like that behaviour of ProximityPrompts is designed for the very rare scenario rather than the common scenario. Which kind of defeats the purpose of having a drop-in engine feature.
Either way, I think it’s important to make a feature request so that it’s identified as a problem.