As a Roblox developer, it’s currently too hard to stop exploiters from being able to delete things like limbs and the humanoid.
If you want to damage someone, you’re going to have to see if their humanoid is THERE and THEN damage them, although if there was a small tweak on the backend, it would only go straight to damaging.
If this issue were addressed, it’d save me on so much time and :FindFirstChild-s.
This is a possibly game-breaking change and would have to be rolled out with major caution due to the fact that some games rely on this behaviour. If this were to be implemented, I would personally like to see it only affecting newly updated games or it being a toggle that defaults to off for games that were created before the change.
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.
That’s why Roblox introduces flags that get set in the workspace (scalable solution to that already has a thread I think). I support this change.
Roblox plans to remove each of these properties eventually.
The issue is that most of the games that do do this are no longer updated and will not be getting any ‘simple fixes’
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.
Roblox is working on a feature for this right now.
Check out the gif below.
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.
It’s a big day for us:
Pretty cool to see this actually happen, no more annoying checks for humanoids or other body parts.
It got bypassed, I am now depressed
It’ s okay, they updated it now they lose ownership even if not enabled so they won’ t be able to do anything effective with it!
