This topic was automatically opened after 10 minutes.
What sort of clientside functions would be affected by this change (not including the usage of level 5/6 exploits)?
2 Likes
It makes no difference whether it’s level 5 or 6. The update literally just prevents deleted character parts from replicating to the server.
12 Likes
I’ve most commonly heard levels 5 and 6 being associated to exploits so I specified it here. But thanks for answering though.
2 Likes
This implies that disabled will be forcefully removed at some point, is this true?
3 Likes
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”.
Exploiting Explained - Local Software. Accessed March 31st, 2023 @ 4:18 PM EST.
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).
13 Likes
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
4 Likes
Thank you! My game interacts a lot with players characters and having to check deep within the characters hierarchy for nil parts was a pain.
I suspect most old games will still work, how often do you need a client to delete themselves or part? 
5 Likes
10/10 update man. I really love this.
DO IT!
One of the biggest dev-unknown security holes is about to not need to be dev-known, which is dev-tacular 
18 Likes
Is this strictly for deletion of descendants? Does it reject replication of values such as IntValues being altered inside the Character?
does this apply to deleting humanoid on client too?
Games that expired longer than my grandfather’ s years.
1 Like
i guess all of those surveys asking people if their places get affected by exploiters really amounted to something lmao
AFAIK you could never change IntValues on client and have it replicate. Same with Humanoid.MaxHealth
1 Like
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.
4 Likes
So whats the news? Did it change? its 1st of may
1 Like
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?
3 Likes
We’ve just enabled an additional fix and are monitoring to make sure it’s working correctly before proceeding.
We recommend setting Workspace.RejectCharacterDeletions to Enabled for your experience manually instead of waiting for the default transition.
3 Likes