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
cl_run is not synced
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Marisa the Magician
- Banned User
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
- Contact:
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: cl_run is not synced
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.
Code: Select all
speed = buttonMap.ButtonDown(Button_Speed) ^ (int)cl_run;
- Marisa the Magician
- Banned User
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
- Contact:
Re: cl_run is not synced
This would be ideal, yes (since just checking for BT_SPEED isn't enough).
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: cl_run is not synced
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.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: cl_run is not synced
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.
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.
Last edited by Matt on Sun Jul 19, 2020 4:24 pm, edited 1 time in total.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: cl_run is not synced
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.
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.
- Zhs2
- Posts: 1299
- Joined: Fri Nov 07, 2008 3:29 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Maryland, USA, but probably also in someone's mod somewhere
- Contact:
Re: cl_run is not synced
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: cl_run is not synced
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.