I think we can all agree, proximity prompts are a great feature. Creating systems similar on our own used to be very difficult and create many game issues. Proximity prompts are fantastic. They do, however, have their downsides which has deterred me from using them in most cases, which could be easily fixed!
Firstly, proximity prompts need a hide feature. Sometimes I just want certain players, or certain characters to be able to access certain prompts. Right now, the only thing you can really do easily is set the distance so it can’t be used by your own player, but that still allows every other player to use them. I purpose some kind of blacklist/whitelist similar to how when we can create rays, something where we can define what kind of character or player, we want to be able to use it. A hide feature is something Roblox has fallen short of on recent systems, I’m not sure why. Highlights don’t have them (and they definitely should). I would even extend that every kind of feature in Roblox should have a distance feature, and a hide feature. Something that we can make complex, but easy to customize. (like blacklist/whitelist descendants in rays)
Secondly, Proximity prompts while efficient, having multiple in one part is such a hastle! You have to manually scan how many there are and set the offset individually for each one. This is a simple thing that I think ROBLOX could add to improve them and make them simpler, rather than making devs do it.
Hiding proximity prompts, in this case using blacklist and whitelist, IS THE MOST niche thing and completely redundant I ever heard. Is the equivalent of a person asking for a coins and kills service to save their coins and kills… Making games or any code in general is about solving puzzles putting things together that match in the most efficient and easy way possible making a small list and simple just looping through your prompts is not that hard.
Proximity prompts are mostly used 1, not sure why you have multiple on a single part, and also if you want to get the prompts without having to loop and identifying which one is a prompt use collection service tags, and just loop through it, it really isn’t that complicated.
It would better help engineers if your feature request focused on one thing at a time and had a clear title relating to what you want to see on the platform.
There’s a lot of things that we may think should be added but don’t exist for a number of reasons, be it that we can make it ourselves and the work to do so is trivial, or it’s just not a right fit. Contextual hiding I feel could just be done by you; ProximityPrompts are highly customisable, you would mainly be looking to configure the Enabled property of individual prompts. It’s also something that’s heavily specialised in every codebase. A method for contextual hiding would be unnecessary noise unless, for example, it were a definable callback only on the server - but even that’s sort of a stretch.
Multiple prompts in one part are a pain point to work around as a developer and it’s not trivial to add proper support for that though, I sort of agree there. The intended scope is probably only one interaction per part but I would really love to be able to easily have multiple actions (either with the same or differing keys) on one part without carrying my boilerplate around for every project.
The easiest way to do this that I can think of it grouping each kind of prompt you use in your game, detecting when one is added to a group locally and then disabling. That’s not convenient. A lot of things technically can just be created by us, and they should be in some cases. But this is Roblox, the point is to make developing easy. Beginning developers don’t know how to do that kind of stuff and most are kids.
As I’ve been looking into custom prompts, they are very confusing, and I consider myself an experienced scripter. We must consider the fact that this is Roblox, developing is meant to be easy for kids; things are supposed to be convenient.
You may want to consider getting help from the support categories after making an attempt; the OSS community Discord, while not formally a help server and having more to deal with the discussion and development of Roblox/Luau tooling, also has a mini-section for help questions.
I do agree about the nature of the audience that Roblox serves, but that doesn’t mean that anything and everything will pass through for the sake of “convenience”. There still needs to be an effort on the part of Roblox developers to create what they want. Too many abstractions, black boxes, API bloat and handholding at a high level takes away the opportunities for experience writing lower-level programs, and in this area of proximity prompts, experiences are highly individualised about them.
“Start shift” and “End shift” job prompts which share the same key (but you will see only one anyway)
There’s no convenient way to use one prompt on the server, because you’d be changing ActionText for everyone. Instead you have to track the prompt via a LocalScript, which gets difficult with the on-by-default StreamingEnabled, and you might as well script your own prompts then.
“Place handcuffs” prompt on players for police/guards
… and so many more
This very issue has required me to create a whole system tracking proximity prompts. The entire purpose for the 250 LOC script is and execute ONE FUNCTION to check if they should be showing. This can very well just be a client side solution:
Personally, I have utilized the custom proximity prompt feature. While it is difficult due to not supporting multiple actions in a single prompt (you have to work around a lot to add it in), if you were only using the normal 1 action, it is very easy to implement because it has a prompt shown/hide function that is used for the custom to appear. In which I just run the blacklist/whitelist that I add to the specific prompts if they have any and it returns or continues to show the prompt based on those specifications.
While this has been a functional way of reaching my goal, I am also an experienced scripter being on the platform for years, we must consider many people could be children or simply not as experienced. These users are in the majority and if ROBLOX really wants to empower creators, this is a very necessary area of improvement.