GZAP: Sync bug when loading saves
I noticed there's a bug in which if you open GZDoom and load a GZAP saved game, it will load everything including the state your run was in at the time and doesn't re-sync with the current state of your run.
How to reproduce: -Start GZDoom Archipelago client and connect -Start GZDoom, play for a while and save -Quit both -Have friends in other games do checks where they give you keys and levels -Start GZDoom AP client again and reconnect -Start GZDoom and reload your save
Things like unlocked levels and keys will be out of sync with current AP run despite being connected to the server.
I did find a workaround:
-Start GZDoom AP client and connect first -Start GZDoom -Load Save -While game is running Alt-Tab to the GZDoom AP client and click 'Disconnect' -Wait 2 seconds then simply click 'Connect' again on GZDoom AP client -Alt-Tab back into GZDoom that is still running. Missing levels, keys, etc. will have been re-synced.
First of all, a simpler workaround (which is in fact the recommended way to start up and connect):
- Start the AP client, but do not connect to the server
- Start GZDoom and load your save so that it connects to the client
- Tab out to the client and connect to the AP server
That said, what you're doing should still work even if it's not recommended. The intended internal behaviour in those last two steps is:
- You start GZDoom AP client and connect to the server
- It gets from the server a list of all items you've received
- It then sits and waits for GZDoom to connect to it
- You start GZDoom
- But it's not connected to client yet, so no data is exchanged
- and reload your save
- It both restores the saved internal AP state, and opens the connection to the AP client
- The AP client doesn't know if you've loaded a save or not, so it sends over everything it has
- GZDoom ignores anything the client sends it that it remembers receiving last time you played
- Now GZD and the AP client are in agreement with each other (and the server) on what you have and you may begin playing
From your description it sounds like what's happening instead is that the client is sending stuff to GZDoom before you load your save, which shouldn't happen because it doesn't try to open the link to the client until the first level is loaded -- just sitting at the main menu isn't enough.
Are you playing a megawad or gameplay mod that uses a TITLEMAP? Looking at the code, I think it entirely possible that in that case the "don't connect until in-game" behaviour breaks and it connects as soon as the main menu loads, which would cause this. If not, are you doing something that puts you in-game before you load your save, like starting with the -warp flag?
Just did a quick test and yeah, with MetaDoom (which uses a TITLEMAP) loaded, it connects to the AP client as soon as the main menu loads, without waiting for you to load your game. So something like that could easily cause this problem.
Ah, that makes sense. Sorry for slow reply it's been a busy week.
I am playing Guncaster mod which very likely has a titlemap too so that makes sense. If I don't connect the AP client first before launching the game I get a VM Crash within GZDoom, which is why I assumed I had to do it in the order of AP Client connected, then launch GZDoom.
My workaround still works though at least. I'm not sure how easy it is to add a 'refresh' button to the menu to simply force a re-sync if a player suspects a desync caused by their mods.
It's a bit of a weird quirk. I figure lowest effort solution is either my workaround or a force-refresh button.
If you'd like me to test anything with Guncaster I can try. The key mod is Guncaster 3.8 I believe. All my other mods were just better textures, liquids, and music replacement mods.
Note that Guncaster doesn't work with the latest GZDoom because of the data type restrictions. The dev PillowBlaster is working on a newer version though.
I'm playing the last GZDoom version that both supports GZap and mods before the datatype restrictions.
This was fixed in 0.5.0, I just forgot to close the bug.