You seem to misunderstood. I do not mean physics exploit but the parts-deletion access of the exploiter.
An exploiter could theoretically teleport a part to the workspace.FallenPartsDestroyHeight
so long as the part in question is not anchored nor rigidly constrained (Motor6D, Weld, WeldConstraint) to the root part, such as when ragdolled, assuming the game has an implementation of ragdoll.
Fantastic addition. Great work
Thank. You. So. Much. The updates lately have been amazing! Keep it up!
Nice to see changes like this being implemented but in future when making posts like this it might be useful for some developersâespecially those newer to the platformâif you stated why these changes were made and give examples of how people are using this to exploit. It just helps people better understand the nuances of the platform.
Definitely worth checking out! Thank you for making a good security update to Workspace!
thanks a lot roblox keep it up
Great, now we just need server authoritative character so that pretty much every character based cheat in existence becomes useless.
Something like this:
However, thatâs physics exploitation and not parts-deletion access. This update made it harder for exploiters! Props to those whoâs involved in this fixing.
This is great, solves a plethora of exploiting possibilities! 10/10 great work!
Excuse my ignorance, I didnât know about this type of exploit.
But I understand that an exploiter can only change his own client, so he could only change his own character, right?
So, what benefit would an exploiter have in changing his own character and this being replicated on the server, since only he will suffer the consequences of this?
For example, the ability to delete items from your character and having it replicate to the server allowed a lot of exploiters to create god mode exploits where they could swap out their characters and humanoids
Thank you very much! It will fix A LOT OF godmode exploits, and maybe, every godmode exploit!
osyris da
im not even sure why this wasnt done before, such a huge vulnerability.
Wow this is great and was long overdue. Glad that this was released as it was a pain to account for client deletion. Iâm wondering if theres a reason this feature was kept exactly (perhaps something related to humanoid dying, and if so why did it apply to every type of an instance).
However this legacy Filtering Disabled compatibility loophole should be fixed as well: Client can change Tool.Grip on Server
Also the fact that the client can entirely halt the behavior of Players.RespawnTime should be fixed as well (because it allows a quasi god-mode).
This probably exists to prevent desyncing of the client (and thats fine), but it should be nerfed so that if the client is normally sending data then it shouldnât be able to throttle respawning.
The fix for this should be that if the clienât is sending network data normally but not just respawning then the server should just enforce the respawning by respawning the character after a set period of time which would nerf this.
Of course the server should allow some leeway for this. (And this behavior should be toggleable)
That would be quite impossible.
Also what if the player has a ping of 10-120 seconds this is common if Roblox is loading a lot of assets (eg when ContentProvider.RequestQueueSize is over 100 or when the network send and network receive are high).
It should be able to account for infinite ping and data delay. How it should work is that it gathers the path a player walked to and records the time of each position and then sends that to the server.
This would allow supporting infinite ping.
Anchored parts already have network ownership on the server.
This is an incredible improvement! Character deletion exploits are horrible to deal with, this is a huge step in the right direction! Loving the transparency from Roblox recently! Keep it up!
Amazing, i can worry less now about watching players in my game and banning less people
This is actually a blessing. This will fix so much. Keep up the good updates.