ZDoom

So, couple people found a desync issue with a mod of mine, apparently caused by autorun. As it turns out... the state of cl_run for remote players is always false. I depend on a cl_run check to play the correct walk/run animations on a custom player, and it seems that a desync quickly happens if one player has autorun enabled and they walk around for a bit.

What I'm saying is:

- Player 1 has cl_run set to true, reading their client cvar returns that it is true
- Player 2 reads the same cvar, from player 1, but it returns that it is false

This is not a bug. cl_run, as the name implies, is a "CLIENT" CVar, its value gets applied to the player input on the client side and is surely not safe to access on the game side of things, especially when you look at how it gets used:
In short: Even it it was synchronised you wouldn't get what you want out of it anyway! The best that could be done here is to somehow transmit the 'speed' bit in the network packets in a way that honors both BT_SPEED and cl_run and any other future addition to control the run state.

This would be ideal, yes (since just checking for BT_SPEED isn't enough).

Yes, I noticed that. I'd consider that part a bug but changing it now is bound to cause even more problems, so we need another flag.

Would using player.cmd.forward/sidemove work in this particular case?

EDIT: i.e., check if the absolute number is the higher or lower one and you'll know which run/walk animation would be appropriate.

No, they can vary depending on the player's properties or even on the RunHealth setting.
If you want a reliable info "player input was in run mode" you need a new bit, but always keep in mind that this information by itself does *NOT* tell you that the player is actually running, it only tells you that the client input was made while run mode was on.

Guncaster ran into the issue of checking cl_run in the player class a long, long time ago, for footstep interval immersion. To fix it, I ended up disabling it if the multiplayer variable was true. It's interesting to see this pop up for multiplayer support consideration now.

added the needed bit as BT_RUN. This will always transmit the current run state, regardless of what user-side setup triggered the run mode.