This coincidentally happened to me in Studio Test Server, giving me a chance at a better analysis:
-
For all other clients other than the victim, Player3 in this case, it appears normal:
-
There is no additional modifications to the player/character logic here. Normal system occurrence.
-
Without moving any player characters, this persisted for well over 18 minutes; the behavior is stable without interuption.
Humanoid State Info for each:
Player3; Victim:
(All visually lazy characters are in the “FallingDown” State.)
Player1:
(All visually upright characters are in the “Running” State.)
Player 2:
(All visually upright characters are in the “Running” State.)
Source: Studio Output. Command Bar Luau code:
for i,player in ipairs(game.Players:GetPlayers()) do
print(player,player.Character.Humanoid:GetState())
end
Now, after all that time, let us move the characters!:
First, I move Player 1, a nonvictim.
Second, I move Player3, the victim.
We only have to focus on Player3’s screen, the far right of them all, because they are the victim of this effect.
We see, when a nonvictim moves they correct themselves quick and clean like a state change.
When we see the victim move their character, the nonvictim player (Player2 all that is remaining) falls like a bowling pin. As to persist in FallingDown. Only after some time (perhaps network replication going back to P2 and forcing a backfeed assertion to P3, do we finally see a nonvictim character resolve).
(P.S: Victim player means client afflicted, not character afflicted, as that really is the player who has character copies, albeit of everyone but themselves, that are affected.)
Also:
State check on Player3, post interaction. (Has returned to normal in State to complement appearances.)
Hope this helps @ContextLost.
