Could an alternative use case for this be as a generic proximity trigger? (without need for display or interacting with the prompt)
So, you’d make an invisible(custom) proximityprompt, set up a listener in the player localscript to trigger various events when the player is near or moves away. For example turn lights on and off automatically or play a sound when a player is near the proximityprompt parent. I know this could be done before, I’m wondering, would this simplify such a setup?
I tested it and it worked, just didn’t know if I’m adding overhead, or saving work or neither, or both.
Touch detection is not the most reliable method to use, + i would rather avoid having additional physics calculation that is unnecessary when i can just complete using few vector math. However, since this feature is out i am exploring of whether it is performant enough to get rid of looping through all objects to check distance and do stuff.
That wouldn’t trigger again when you moved away from it. ProximityPrompt.PromptHidden does.
I know there are ways to do this with touched and measuring distances, I have done it, I’m just wondering if this new detector will simplify it and if that is a good alternative use for it. (when you don’t necessarily need a prompt and interaction)
I don’t see a way to not have a key defined, like why couldn’t you leave the key blank and have the click prompt (same as the mobile prompt). There is an ‘unknown’ option in the dropdown, but that just makes the script throw an error when the prompt is to be shown.
Anybody know if that is possible?
Just because the user has a keyboard, doesn’t mean I want to use it for the trigger.
Will there be a way to prevent a ContextActionService binding from being invoked if a prompt is being used?
At the moment, for example if I have a button bound to a menu - but a proximity prompt shows up with the same binding, it will invoke both if I press the button. Possibly a boolean property like SinkUserInput ?
I wouldn’t really want to do some hacky checks for if prompts are invoked etc with each bound action. I don’t think this would be as much of a problem on PC, where there’s plenty of options here for keybindings, but on console with a more limited button selection… probably going to be a problem.
Are we able to use the Left-Mouse for the interaction? I know we have click detectors but the UI is cool looking and also, the proximity feature as well as the mobile appropriate prompts seem like a nice thing to have.
I already have all the keys near WASD called for, so I want to just use this with Left-Click
Those are based on proximity, not looking at a task.
ProximityPrompt has a function to only be enabled if there is nothing between the player and the parent.
I found a bug where if the gui is active and the holdduration is changed to something else the tween animation is bugged (gets fixed if the gui get’s deactivated and then activated)
Well, not bad, but I do have one complaint:
I played around with this via a simple revive system. The prompt is enabled when the player becomes downed. Only the downed player can see the revive prompt. Another player, even when standing ontop of the downed player, never sees it. (Visibility is handled by a server script, and I checked, the enabled property is set for the other player.)
I checked to see if this was a character problem and tied the prompt to an external part welded to the downed player’s HumanoidRootPart but that changed nothing. When a prompt is tied to a part in the workspace however, two players can see the prompt at the same time, regardless of who is closer.
Is this intended or not? There is no option to only make prompts visible to the nearest player, or all players.
