I understand parts to be destroyed, but any other object like Humanoid, Scripts, BindableEvents, and other Instances shouldn’t be included. I believe this to be an old behavior of Roblox that has stayed here for years even when filtering enabled came into place. The only instances that do not destroy are the clothing, which is probably to prevent people from getting a nude character.
Why not fix this for all the other Instances as well though? No one should be using such a feature at all. Imagine you from a LocalScript destroying objects because you want to destroy them on the server too, it makes no sense.
That said, I totally agree with this post. (If anyone knows the actual reason why this feature should remain, other than to avoid certain games that use this feature to break, please let me know)
Oh man, you’re worried about games breaking?? I don’t think many games destroy your limbs from the client, and even if that one game that’s one out of the millions does that, it wouldn’t be hard to fix by using a remote event.
Name me at least one game that takes advantage over the client deleting objects inside the character. If you do name one, it’ll be a game with literally no players. It’s time that old games just deal with it.
No experience should be relying on unintended behaviour like this. Clients should never have authority over removing anything in their character. It should be strictly limited to certain simulation such as physics and animation replication. This should’ve been introduced with FilteringEnabled but since it hasn’t, it should face a rollout where it eventually becomes the default behaviour. Experiences need to update off that behaviour.
It’s called creating player character on server and manually setting .Character and applying Network Ownership
But now i wonder if it’s just .Character + client networkownership thing or just engine itself giving StarterCharacters full authority?
Eitherway, shouldn’t this be a toggle option or a new method on server that allows developer to give or take full authority over an instance? (e.g whether client is allowed or disallowed to change or have authority over child objects)
Either way just manually :Clone() a character and set the player.Character manually, assuming this bug only affects models created by StarterCharacter
I’d argue that it isn’t unintended behaviour, the Roblox engine itself uses this behaviour for breaking joints, etc. Some experiences likely also use this behaviour for the realtime destruction of players during an explosion, etc.
The whole idea of clients still being able to delete instances from their characters is a relic of pre-FilteringEnabled days; such artifacts are present in various places in the engine and in developer code. That existing doesn’t mean this behaviour is intended[1]. It’s incredibly undesirable and gamebreaking (especially for those who put needed instances in characters).
There is no case where you want a client deleting instances from characters, especially ones created by the server, with obvious exception to if we had replication control to allow the server to permit the client to do that. In all other cases, regardless of where, client deletions should not propagate on their own, only simulated content.
[1] See other cases where engine/developers relied on unintended or undesirable behaviour that is or will later be changed: SignalBehavior and animation blending.
The only issue with this is that it is deleted on the client too. Local scripts will not run once deleted.
Once again, this feature isn’t needed once Roblox adds a built-in anti exploit. However, I oppose of that idea (mainly because programs like ReShade and fps unlocker will break), so I support this feature.
If you are talking about an exploiter doing this, they can do this anyway, no matter what protections are added against it.
Just want to make it clear that Roblox already has a client anti-cheat and it does not detect these minor modifications, I doubt Roblox will invest more into client securing as a server anti-exploit would be much more secure.
This would be nice, but let’s say you have a game where players’ characters are teleported to places. How would it detect if the player was intended to teleport somewhere or if they’re exploiting?
By having you call a function in some service to teleport them, instead of using :PivotTo (assuming the server teleports the player), but if they really wanted to get rid of teleport exploits they’d need to make humanoids server-sided.
