While converting some legacy systems (e.g. doors) to the new ProximityPrompt class I’ve come face with an issue that I have been unable to fix without resorting to the old methods (thus defeating the point in using ProximityPrompts).
Currently, if you have two or more ProximityPrompts within range and RequiresLineOfSight is false and Exclusivity is set to OnePerButton or OneGlobally for all available prompts, there is a chance Roblox will select a ProximityPrompt that is not the closest to the camera / character.
This makes it incredibly difficult to achieve proper mechanisms such as keycard readers, levers, buttons, etc. since there is no accurate way of having the expected item (the closest) be the one interacted with.
For example, I currently use keycard readers on my doors. One of them is a Push Door. There are two scanners, and depending on the prompt that’s activated (one prompt per scanner), the door can open in a different way. The current behavior of not selecting the closest prompt causes players to have the door opened in the wrong way. This also makes it incredibly difficult to add effects such as trails or indicators in the proper location.
Having an option to make ProximityPrompts with the Exclusivity set to OnePerButton or OneGlobally only display the closest prompt to the character would be a life saver and allow me to use ProximityPrompts.
I’m a bit confused. After reading your post. Line of Sight seems like it would be the best option for this.
It should appear as the closest anyway but Line of Sight should just make it more accurate. Is this not the case? Any reason in particular that you’re avoiding using the Line of Sight option?
As described in op, I already have RequiresLineOfSight off. Unfortunately this does not fix my issue.
RequiresLineOfSight affects if the person should be able to see the prompt depending on if the prompt is within the viewing area; my issue is about the fact that the ProximityPrompt that appears has a chance of not being the closest one. RequiresLineOfSight works great, it’s just that the ProximityPrompt being shown is not the ideal one.
And that’s what line of sight is for. I’m not sure what you mean by “turn it off”. I never recommended turning it off. I recommended turning it on.
See, I’ve made proximity prompts months before it came out. The logic for Roblox’s and mine is largely the same. Enough that switching over was a piece of cake. Line of sight is more so to figure out which prompt is the closes. Not that you have to immediately look at it. Otherwise, I would have opted to keep my own system.
What use case are you determining where the player needs to be nearby a proximity prompt without looking in it’s direction and still interact with something? When I get on elevators I don’t press the button with my back.
Oh I see what you mean; misinterpreted it on my first reply.
On my game, I used to resort to magnitude checks every so intervals to determine if a player is within the range of an interactable. This is mostly UX and simplicity.
See, near the keycard scanners there is a possibility of there being a lot of moving objects, such as players or AIs, which by blocking the sight would make it impossible to interact with the doors / whatever interactable object the game might have.
Another reason would be that if I do resort to RequiresLineOfSight, ignoring the possibility of the sight being blocked during cases such as described above, I would have to set up different attachments for every single interactable object with their own offsets in order for the parts making the interactable not block the prompt. (there are over 150 different interactables - considering this is meant to be available within a specific range and considering the scenario described above, there should be in theory no need for this, given simply making the closest ProximityPrompt be the one displayed would fix all our problems)
Lastly, only displaying the closest ProximityPrompt is already what I would expect as behaviour. The fact it’s not the current behavior is the very reason I’m making this post. Same thing happens when RequiresLineOfSight is true, there’s still a chance that the displayed prompt is not the closest one. For example, in one of my games users can place down craftable items such as ammo boxes or sandbags. Some times, the prompt displayed is not the closest, which leads to some very odd and confusing UX.
That’s understandable. So are you asking for a priority property or something? So that the highest priority prompt is shown first?
Or just in regards to being close to the player itself? I do believe Proximity Prompts is based on the distance from the camera. Not the player, that’s what I’ve noticed in my testing.
Yes, I am pretty much looking for the ability to set the ProximityPrompt to display the closest to the camera instead of the current behavior (which can either show the closest or not). (Or even better, have this be the default)
This is mostly only really an issue when Exclusivity is being applied, since when it’s set to allow multiple prompts there isn’t really much of a need to prioritize visibility.
Hello, thank you for letting us know of your needs here.
The expected behavior is that if multiple prompts are in range, the one closest to the center of the screen will be shown. This was intended to give the player control over what to interact with, so they can aim the camera and look at something to select a different prompt instead of having to move their character. Our testing has shown this to be a fairly good method of interaction.
I understand that in your case, you prefer to strictly use the player’s position, not taking into account where the camera is looking. This behavior is unfortunately not available currently.
We are always looking for ways to improve, so we will take note of this request.
You could try reducing MaxActivationDistance, but that will have a side effect of requiring the player to be closer.
If I understand your use case, I have a recommendation here if you wish to apply effects to the object that currently has a visible prompt - use the PromptShown / PromptHidden events to disable / enable your effect.
Such as the following code in a LocalScript:
prompt.PromptShown:Connect(function()
-- enable the effect
prompt.PromptHidden:Wait()
-- disable the effect
end)