Off the top of my head mate? Not a clue right now, but I imagine you could just upload a segment of the arc/circle and make a script to duplicate it and rotate each duplicated instance according accordingly.
cc: @Timelens
UIGradient solves that. This has also been done on the DevForum before.
Regardless, it might have been better to leave the replies for relevant issues, not for scripting or UI support.
When you create your custom UI, you can listen for InputBegan and InputEnd on your button, and call these from within:
prompt:InputHoldBegin()
and
prompt:InputHoldEnd()
You can see an example of that in the customization code sample here:
This is cool! Really nice to finally have a dedicated tool for this, akin to the ClickDetector instance.
One thing I’d say that could be improved is that when a part has multiple ProximityPrompt instances, that it displays one UI with both of the buttons shown. This would be useful for cases like doors where you have the option to either open it or lock it, or the option to break down a door vs. lockpicking it. Right now, the ProximityPrompt just creates two GUIs that overlap:
EDIT: I realize this is possible with the UIOffset property, but it would be nice if Roblox handled that automatically out of the box.
No, because countless games are using ClickDetectors
I would like to point out that, countless games relied on legacy lighting, outlines and legacy terrain, yet roblox removed them, in such a way that the games were still playable, I believe a similar thing will happen to Clickdetectors, roblox will slowly start deprecating them like it did to the above mentioned features, before announcing a final deadline for it’s removal, I believe that they will convert existing Clickdetectors in games to proximity prompts, similar to how they converted legacy terrain to smooth terrain, this way, they will ensure old games do not break
100% support for this.
We use proximity interactions in all of our games, however they also require showing multiple/variable options at once. This requires writing a large custom wrapper on top of ProximityPrompts to handle building these lists and setting their keybinds in real time.
Here is a demo I wrote but it required a significant amount of custom code.
Here is how we use interactions in Robloxian High School:
I think if this feature supported multiple-options there would be hardly any reasons to use a custom implementation anymore!
Absolute lifesaver, thank you!
That is technically possible with the current system. Although you will have to mess with the UI Offset quite a bit for each one.
Thanks, Roblox! It helped a lot!
Yes, you can do that with a script in my opinion. Scroll up, there are a few examples😄
This has removed alot of work for something so simple and helped performance. Great addition
This is great, the only thing that I want to be added to this is automatic handling for multiple prompts in one position, so like if you have 2 prompts in one part, it will show 2 nicely aligned prompts, and thats all .
I’m sure that would be helpful but eventually someone will write a script to do that automatically.
This is great! I’ve always a ClickDetector for KeyInputs. I’m a bit concerned what will happen when two entities with ProximityPrompts are close to eachother though. I’d rather priority be based on the where the player is facing instead of just distance.
This is a really awesome feature, it’s great to see compatibility for games and platforms becoming much better.
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.
Why don’t you just make a Sphere part, make Transparency = 1, and CanCollide = false, and then add a Script that uses .Touched?
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.