Nice feature!
One question I have is that would using proximity prompt as distance trigger be worth it? ex. connecting to the show event to do something else than ui, such as streaming in and out the model on client. Right now i have to iterate through every objects that is meant to be streamed and decide whether to render or not, which results in pretty high script activity.
It has support for it already, clearly some people are confused on how it works so I might need to do a tutorial on the custom UI aspect of it.
Think this involves the Visible property.
You could parent the Seat and the ProximityPrompt into a model (separate from one another) to solve that, or by adding an Attachment/Invisible part for the ProximityPrompt to be placed within.
This is because itāll only be shown when it is parented to an Attachment, BasePart, or Model, as mentioned in the Developer Hub Article.
Are there any currently known caveats to this feature, specifically in relation to exploiters? I am extremely interested in ridding of my custom implementation in favour of this natively supported feature.
I am sure ProximityPrompt will outperform what I have now and its range of customisation so far seems great, but as always one thing on my mind is regarding the security behind this feature so I can understand what steps I might need to take to mitigate such problems. For example, activating prompts without being close to them could be problematic, like with ClickDetectors.
Good point. We have accounted for this, as there is a server side check that the player is in range when a prompt is triggered.
This is now fixed, was an error with the web page. Thanks again.
ProximityPromptService/MaxPromptsVisible
ProximityPrompt/InputHoldBegin
These pages do not exist
(I also think that it shouldnāt have the same icon as ClickDector)
other than that good job on the Feature!
Glad to hear thereās a serverside range check in the system.
Is there a serverside check for whether or not the player actually has a line of sight when the RequiresLineOfSight
property is set to true, or is that still clientside like in the Beta?
Youāre able to disable the default gui and implement your own, no hoops to jump through.
Iāve always wanted to implement some sort of way to use a keybind to actually activate a certain event, and trying to figure out magnitude with UIS (UserInputService) always got in the way. Thank you for releasing this! This will help out a lot, and will definitely make games look a lot smoother. Keep these awesome updates coming!
You can click on the purple text to view itās descriptions.
This is a great feature!
Unfortunately, it came out late for me to use the key interact system and I already coded my own key interact system. Iām not sure if Iām going to use it on an upcomming RPG game Iām working on because I donāt want to take the extra time to work on it but maybe instead, Iāll use some parts off the API and use the existing GUI as the custom one.
If it came out earlier, I would have used the feature right away because it saves a lot of time from coding the key interact system which is time consuming.
I wonder how much this new feature will impact performance. I want my upcoming game to run at an acceptable and playable frame rate on mobile devices.
Pretty sure theres a property for that named āRequiresLineOfSightā.
Will this mean deprecation of Click Detectors?
I donāt see how this post has any relevance to click detectors, but I do agree that click detectors could be deprecated due to their unreliability.
For those who want to easily customize prompts, I really recommend using Prompts+:
Itās really useful
Is this hard-coded to work with player.Character?
I assume this uses some sort of spatial partitioning algorithm to speed up distance checking between proximity prompts and players. Is there any way Roblox can expose that as well so we donāt need to implement our own? This would be able to be used much more versatily/generically.
I was hoping for a way to add multiple interactions to one ProximityPrompt instance. This would likely require a toggle switch on the instance itself and a way to add the interactions through scripting. Something like Prompt:AddInteraction(name, key, ...)
I mentioned this on the last post and was hoping it might have been added by release. Maybe thereās still time who knows. Unfortunately without this ability Iām going to have to resort to the old way. It just doesnāt make sense for me to have to do the hacky things I did to make it work the way it should have to begin with. I wish some features that are released could have features aimed specifically at the scripting side of things, obviously they need to be developer friendly but handicapping the feature isnāt a great idea either.
Just my two cents.