We hope you’ve had a chance to explore and opt into our recently announced replication security feature, Workspace.RejectCharacterDeletions. As part of our ongoing commitment to improve security and user experience, we’d like to inform you of an upcoming change in the default behavior of this feature.
Mark Your Calendars
On May 1st, we will be updating the Default setting for Workspace.RejectCharacterDeletions to mean Enabled. This update will enhance the security of your experiences by automatically preventing client-side deletion of descendants in a player’s character from being replicated up to the server.
What You Need to Do
To ensure a smooth transition and avoid unexpected changes in behavior, we recommend that you:
Review your current setting for Workspace.RejectCharacterDeletions and update it to Enabled if you haven’t already.
Test your experiences and make any necessary script changes to accommodate this feature.
If you need more time to transition your experience, update the setting to Disabled.
Need Assistance?
If you encounter any issues or have questions about implementing this feature, please don’t hesitate to reply to this thread.
The names “Level 4”, “Level 7”, and “Level” alongside any number ever were made to refer to these kinds of exploits and the fact they could access functions from higher context levels. The number itself doesn’t mean anything, and the terms are usually misquoted as meaning different things. A “Level” anything is just a fancy way of saying “script executor”.
It’s explained right in the thread what this update’ll do. Glad we’re moving forward with this, felt overdue as one of the retained pre-FilteringEnabled behaviours. It is unfortunate that some older experiences that don’t get updated will break but in the face of security this is one important piece of the puzzle regarding character exploits.
That mainly just leaves me with network ownership exploiting. I really do not like giving the server network ownership of anything because of how expectedly slow it simulates physics but I otherwise can’t avoid exploiters teleporting around NPCs or even doing something strange with their own character (notwithstanding how I also need client character control to a degree).
I dont see why they wouldnt do this, although it could break old games. But then again, it was the same for FilteringEnabled, and they forced it anyway
Not sure if this has been reported, but we’re refraining from enabling this setting because of one issue. When players are killed their limbs do not fall apart as is usual, instead the character freezes up and does not move, this harms our games User Experience as users become confused on what just happened as falling into parts is what usually happens when you die.
We’re killing players client side using :BreakJoints() in order to have instant feedback for the player when they die.
Hi @OutlookG, we’ve just enabled a fix for this. Could you please verify your game is working as expected now with Workspace.RejectCharacterDeletions enabled?
