Also this ruins client-sided effects for FilteringEnabled. Even if I only want my client to see changes made to the character, I now need to worry about handling the changes replicating to the server.
It’s a huge web I need to work through now that I’m aware of this behavior. This should 100% be changed instead of forcing me to make my own hacky replication for stuff I expected to function properly out of the box.
The reason I said it becomes useless is because there are otherwise better places to put your (server-side) scripts so that exploiters can’t just delete them. Why be wary when you could just put it somewhere else?
I actually created a vanilla Humanoid system in which the character is controlled by both the server and client, however the client only has limited control. I’ll have to unarchive it when I get a chance. I may uncopylock the place as well, we’ll see. Currently it’s a little unstable but it fixes a majority of movement exploits. Additionally, due to it being custom replication this fixes touch issues as well.
As for deleting descendants of the character, it is possible to detect this (e.g. such as how I’ve done above), however it’s a similar situation where it’s hard to filter between client vs server changes so you’d have to implement custom destruction of instances as well.
I really really REALLY think most of this behaviour needs to change though. It defeats the purpose of filtering enabled and causes a TON of issues in 95% of games not to mention the fact that it’s completely undocumented.
Except property changes made to the local character don’t replicate; only the destruction of objects do; so there is no “control over the entire character instance.” It’s either a bug or a very stupid feature.
I personally cannot see any reason why the client should be authorized to delete instances of the local character (considering, especially, that property changes do not replicate).
Only physics-related data (position, velocity etc) and calculations handled by the client (should) replicate. This is true for all other BaseParts which the client has network ownership of (deleting those doesn’t replicate).
I think I am going to make a custom character controller to alleviate this (it’s apparently been 6 years without a solution). It’s a little sad that it renders StarterCharacter/etc effectively useless in that case, because otherwise I would use them.
Exploiters can’t work around a server sided instance removal check. If they remove something from their character and it replicates, then the server will see it removed.
Does this still happen? Does this mean I can’t trust humanoid.health and the default health script to be accurate?
@Defegne
Humanoid.Health is a property, and as such isn’t affected by this. The only thing that is replicated is when the client deletes an instance under their character. As for the default health script, the client can delete that however all they’d be doing is stopping their own health regeneration, as the health script is only for managing the player’s health regeneration over time. Overall, this means the player can’t do much by default unless they want to stop their own health regeneration, if you’re worried about exploiters doing game-breaking things I’d check for what you parent under the character like scripts or instance tags. (E.g: using a folder parented to the player’s character for managing whether the player is stunned. You can fix this by using CollectionService and using AddTag as that won’t replicate from the client.)
Ok so I’d also need the server to check if a player destroys an instance they’re not supposed to under their character
I hope this is addressed properly. Developing a game on this platform feels like I’m diving through a dumpster of broken and undocumented ‘features’. We are taught again and again to “never trust the client”, but so many Roblox features ignore that lesson so now we’re stuck having to patch it ourselves. Now not only do I have to worry about making sure my own code is secured, I have to dig around on the forums to find all of the weird miscellaneous exploits with the engine and write hacky alternatives to them as well.
11 months later and this bug has still been around. It would be nice if we could get any sort of acknowledgement from the staff about this.
This makes the existence of StarterCharacterScripts pointless and that really sucks because I relied on the folder a lot during the development of my game. Now I’ll have to reorganize everything…
Is this not intended? I’d think the client needs network ownership of the Character model to function properly.
It’s understandable for the client to have network ownership of their own character; however, it gets frustrating once you realize the client is also able to replicate destruction of Instances within their character model, which leads to people dropping hats, removing meshes from parts, deleting clothes, and making floating accessories.
AFAIK networkownership doesn’t require them to be able to delete instances and it replicating.
Bumping this because this issue is the bane of my existence. I am trying to manually replicate content between clients and servers, but this makes it impossible, as I can’t just delete the server sided objects on the client otherwise they will be gone for everyone else too. No idea how else I am supposed to be replicating things such as character look or the facial expressions of the characters without having a local and server sided copy, and without using animations.
I’m surprised nothing has came out of this.
Recently there has been a bombardment of exploiters running around without limbs and breaking some key scripts on our game. Not only that, Deleting other “hitboxes” in the character can make them invincible and immune from any damage. This took us forever to figure out because this was not documented anywhere and was only noticed recently because of the Devforum. :Destroy() should never be replicated from client>server because that’s only asking for trouble.
It’s nice to have scripts in the character, because you don’t have to put systems in place to make sure the character exists. I understand CharacterAdded works, but it’s a pain to disconnect all the connections from the old character.
For anyone following, I just recreated it and this is now completely fixed. Probably since the introduction of Byfron.
I used the same local script but included deleting values and scripts aswell, nothing replicated to the server.
It’s actually because of the feature called “RejectCharacterDeletions” which patched most of the exploits, Byfron is just an anti temper software and nothing else, It isn’t an anti cheat.