[Fixed] Server CVars keep prev. values for 1 tick after loading save

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Server CVars keep prev. values for 1 tick after loading save

Postby Player701 » Sun Oct 11, 2020 9:57 am

When a save file is loaded, server CVars are not immediately restored to their proper values from the save file. Their previous values (i.e. those that were in effect before loading the save) are retained for 1 tick. This may cause glitches in mods if an actor checks the value of a CVar every tick.

Addendum: This doesn't happen when loading a save file on startup with -loadgame. Regardless of the value found in the config file, the saved value will take effect immediately. However, the bug can still happen when loading further saves during the same session. The bug also does happen when loading a save file from the title screen.

I've attached an example WAD to this report to reproduce the bug. Steps to reproduce:

  1. Load any map.
  2. Type in the console: give testinv
  3. Close the console and make sure the game is now spamming messages saying that the current value of the test CVAR is 0.
  4. Save the game. Remember, the saved CVAR value is 0.
  5. Now reopen the console and type: cvar_save_bug 1
  6. Close the console. Now the game is spamming messages saying that the value is 1.
  7. Load the save file and immediately reopen the console. The very first message that appears after loading the save will say that the current value is still 1, although the saved value was 0. This is not expected behavior.
  8. Notice that the rest of the messages again say that the value is 0.

Tested in GZDoom 4.3.1, 4.4.2, and g4.5pre-251
You do not have the required permissions to view the files attached to this post.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Server CVars keep prev. values for 1 tick after loading

Postby Player701 » Sun Oct 11, 2020 11:06 am

I have identified the cause of the problem. Server CVars use callback functions D_SendServerInfoChange and D_SendServerFlagChange which cause the value update to be delayed. These callbacks return false when the game is starting up (gamestate == GS_STARTUP), causing the change to be reflected immediately instead. However, there is no special case to handle save file loading.

This issue can be fixed by adding a check for !savegamerestore to D_SendServerInfoChange and D_SendServerFlagChange, but the code to set savegamerestore to true in G_DoLoadGame must be moved to the point before CVar deserialization. I'm not sure that such a change wouldn't break anything else, though.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Server CVars keep prev. values for 1 tick after loading

Postby Player701 » Mon Oct 12, 2020 1:20 am

I have reviewed the code further and came to the conclusion that the proposed changes should probably not break anything. However, I cannot be absolutely sure. Proposing a PR to fix this issue, please review.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Server CVars keep prev. values for 1 tick after loading

Postby Graf Zahl » Sat Oct 17, 2020 1:24 am

I added the PR so that it can be tested. I cannot judge myself if this is proper or not.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Server CVars keep prev. values for 1 tick after loading

Postby Player701 » Sat Oct 17, 2020 1:51 am

What I can say for sure is that it fixes the bug in question. Any potential unwanted side effects might only appear as a result of moving the savegamerestore assignment to another place in the code, but I'm fairly certain it's not going to affect things much, if at all. However, in case something comes up, I'll of course post a reply here and maybe open a new bug report.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support


Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests