Using Humanoid:SetStateEnabled on the server does not replicate the change to the client. Changing the Dead state to false, for instance, and then using GetStateEnabled, will return false on the server and true on the client, or vice versa if SetStateEnabled is called from the client. It doesn’t replicate at all and that isn’t documented.
11 Likes
Would this mean that you’d have to call Humanoid:SetStateEnabled(Enum.HumanoidStateType.Climbing, false) on both server and client to improve performance?
Just came across this issue too. Is this intended?
Can we get an update on this behavior? It’s really obnoxious working with Humanoid states, shooting blind and guessing what will happen, it’s a massive waste of time.
2 Likes
Sorry for reviving this topic, but I just tested if they have fixed the replication for :SetStateEnabled() and unfortunately bool values were not synced when I fired print(Humanoid:GetStateEnabled(<state>)) on client and on server. Just letting you know. I hope they change that soon.
Still haven’t seen a Roblox engineer reply to any of these posts regarding whether or not this is really intended behavior; seems silly if it would be intended.
2 Likes
I just ran into this issue where I disable most of my server NPC buildables humanoidstates to improve performance, but found on the client side it’s still seeing those disabled states (which caused one of my weapons to think it was getting an airshot on a tower despite humanoidstatetype.Falling being disabled for towers). This seems stilly that disabling humanoid states on the server doesn’t replicate to the client to save performance- so do I have to force every client to disable the same humanoid state separately? Seems like not replicating disabled humanoid states on a SERVER OWNED object to clients is an oversight.
1 Like