ProximityPrompt can be fired server-side regardless of being Enabled

[ForbiddenJ]

Given that Tools were recently changed to where one cannot be dropped if its CanBeDropped is set to false, I’m assuming this is unintended replication behavior.

To put it simply, if an object has a ProximityPrompt, but then its Enabled property is false on the server side. A client script can simply re-enable it on its end and still trigger the server’s event.

Disabled ProximityPrompt Repro

DisabledPromptRepro.rbxl (30.4 KB)

Steps to Reproduce

1. Create a Baseplate in Roblox Studio.

2. Create a Part with a ProximityPrompt in this manner.

   

3. Replace the script’s contents with this code:

   script.Parent.ProximityPrompt.Triggered:Connect(function(player)
       print("Brick!")
       script.Parent.BrickColor = BrickColor.Random()
   end)
   

4. Play Solo.

5. Interact with the brick. You will see that the server prints “Brick!” to the output.

   

6. Switch to the server side and run this code:

   workspace.TestPart.ProximityPrompt.Enabled = false
   

7. Switch to the client side and run this code:

   workspace.TestPart.ProximityPrompt.Enabled = true
   

8. Interact with the brick again. You should see this output:

   

[dollychun]

I think this is the intended behavior.
I think you can get the same behavior with ClickDetector.

[ForbiddenJ]

Why do you think this is intended behavior?

Also, ClickDetectors cannot be disabled to begin with.

Spoiler

[dollychun]

@ForbiddenJ

Why do you think this is intended behavior?

For example, if you want to enable it for only one client, the server Enabled property is replicated to the client, so you can send a RemoteEvent to only one client.

Also, I don’t think the Enabled property will be read by the server. Just replicate to the client.

[ForbiddenJ]

Perhaps that’s a good use case for this ProximityPrompt behavior, as long as developers are aware they need to sanity check the events themselves in a similar manner to other basic detectors.

I’ll just have to wait and see what the staff thinks.

[crypto_mancer]

Good catch, thanks for the report! We will fix this in the coming weeks.

[Hippie_ofDoom]

This issue should now be resolved! If this issue is still occurring, please create a new topic for us to look into.

[BuilderAtWork]

Not sure if related, but it seems that all client-side ProximityPrompts in my game are now broken…

Washware [PRE-ALPHA]

[shvkti (knee)]

This issue is happening for me too. No errors

[MrKonvicted]

ProximityPrompts are currently not working. We have searched for any type of errors, but none have been found.

[Hippie_ofDoom]

sounds like a new issue to me. I would file a new bug for the prompt not working at all

[crypto_mancer]

@BuilderAtWork

Not sure if related, but it seems that all client-side ProximityPrompts in my game are now broken

Hello, thank you for the report. I apologize for the inconvenience. I looked into what’s happening here.

Our new expected behavior is that enabling a ProximityPrompt on the client will not enable it on the server, so server-side events won’t trigger.

This is intended to make the feature more secure - if a ProximityPrompt is supposed to be disabled, we don’t want a client to be able to enable it locally and cheat.

Ideally, we would like to not revert to the old behavior, though I do understand it has broken functionality in your game.

I have a recommendation to get your game up and working as it was. Can you let me know if this solution will be acceptable?

• Start all applicable ProximityPrompt objects enabled
• In a LocalScript, disable them all on startup

This will have the effect of keeping the ProximityPrompts enabled on the server, but start disabled on the client.
This way you can enable/disable them on the client per player as you were.

If there are any other new problems that I haven’t addressed, or if I misunderstand the issue, please let me know. Thanks!

[BanTech]

In the future can we be notified of changes like this before they are made. It seems to be getting more and more frequent that we get features broken by rushed changes without notice and now I’ll have to work to fix our game instead of working on my university assignment due to the change.

Especially as it just silently fails rather than providing a warning or something to indicate the sudden change in behaviour, and the only mention of this change coming up is buried in this post on the forum which I had no reason to discover until today.

[mew903]

This is another entry in the ever-growing list of behavior changes that Roblox makes but does not tell anyone about. Users have been yearning for these behavior changes to be announced ahead of time for at least the past year, yet here we are again.

I’d like to think nobody in particular is at fault here, so I’ll say that Roblox as a whole needs to be better with communicating these changes to developers.

[shvkti (knee)]

@crypto_mancer

This will have the effect of keeping the ProximityPrompts enabled on the server, but start disabled on the client.
This way you can enable/disable them on the client per player as you were.

This is assuming that you were changing them on the client. If disabled proximity prompt gets enabled when you join the game, but you are still listening to a .Triggered event on the server, this solution is not applicable. Do you have a work-around for this?

[crypto_mancer]

We have decided to revert this change for now.

Thank you for bringing this to our attention. We underestimated the number of games that rely in this behavior. We will carefully consider how to roll this back out without breaking functionality.

[PeZsmistic]

Not sure if you’re considering keeping this weird broken behavior, but for what it’s worth I would consider the intended behavior that was rolled back very desirable. The other behavior is very unexpected and would undoubtedly lead developers to insecure code. Hope that the correct behavior is pushed after a PSA.

[BanTech]

@PeZsmistic

Hope that the correct behavior is pushed after a PSA.

I totally agree with PeZsmistic despite myself being one of the developers relying on the current (less secure) behaviour.

I did have my own checks in place anyway but I agree the new behaviour is more secure without needing extra checks from the developer.

Generally devs don’t mind patching code and adapting to security improvements, we just need a PSA and some time to avoid disruption.

Thank you for the temporary rollback and the response to our concerns.