ACS world variables reset to 0 on reload (not always)

[Player701]

I'm describing a specific case here, since, unfortunately, I have failed to isolate this issue so far - it doesn't manifest itself in the test maps I have built. But there is one case where it always happens - Daedalus.

The scripts in this WAD use world variables to track some of the player's stats, for example, the state of his "aural translator". It uses two variables for this purpose: TRANA_STAT and TRANA_CHARG. Defined in D2KIncl.acs, lines 172 and 174:

Code: Select all

world int 1:TRANA_CHARG; // Aural translator charge - 20 min
...
world int 3:TRANA_STAT; // Aural translator status - 1 owned and working, 2 needs charge

At the start of the game, a script sets the value of TRANA_STAT to 1 and TRANA_CHARG to 1240. This happens in script 1 of D2KGG01.ACS (lines 97 and 98):

Code: Select all

Script 1 OPEN
{
...
   trana_stat = 1;
   trana_charg = 1240; // granularity is 10 seconds
...
}

However, as soon as the game is saved and reloaded, the values of these variables are reset to 0 for some reason. This triggers the following part of the code in function "msgpush" to execute in LIBMOut.acs when a new message arrives (lines 282-286):

Code: Select all

if (TranA_Stat == 0) // no translator
{
   // msgNormal("Can't understand anything. Maybe you need a translator.");
   print(s:"Can't understand anything. Maybe you need a translator.");
}

The player will see the "Can't understand..." message as soon as he leaves the shuttle after the crash, provided that the game has been saved and reloaded at least once. If the game hasn't been reloaded, some messages will be printed before the translator's charge runs out. This is normal behavior.

I have failed to find any place in the code where the value of TRANA_STAT is explicitly set to 0. I have made a WAD with a script which logs the values of the TRANA_STAT and TRANA_CHARG variables to the console every 5 tics, and it seems they are indeed reset to 0 as soon as the game is loaded. Thus, I conclude that it is an engine bug.

As I have already mentioned, I couldn't reproduce this issue in a clean environment. I made a test map with a world variable in its scripts file, and then added a library which accessed and changed this variable. But the value is preserved after reloading in all of my tests. There must be something in the Daedalus scripts which somehow breaks the normal behavior.

I am attaching the WAD with the logging script in case it might be needed for testing.

P.S. TeamTNT website seems to be down for unknown reasons but you can get the Daedalus ACS source files from the Web Archive in case you don't have them. Link

[Lord Misfit]

I don't have a good test map or so for this myself, however I'm also having a similar issue where it seems like a lot of ENTER scripts that are supposed to loop when they finish executing don't load/work when reloading a save game [unless you pukename one of those scripts to reactivate it], but it ONLY seems to act up like this when playing on Hexen-specfic maps. Doom/Doom2/Heretic/Strife maps as I can tell don't have this problem.

I don't know if I can accurately isolate this problem to make a test map though, but this is related to reloading a saved game like what you're experiencing and it could even be related to your problem. Sadly this means I can't really play my mod with the Hexen compatibility patch I've made since reloading a map or going back to a level from another will basically kill all of the running ENTER scripts for some reason. [and no, this wasn't an issue for me a month or so ago, so this is not something that's always been lingering around, but I also have no real idea what SVN the problem starts at the moment]

[Graf Zahl]

I actually fixed a bug in the savegame code recently that made the garbage collector throw away a lot of scripts. So if you got old savegames affected by this bug (one pointer in DACSThinker) was not serialized and load these with a fixed version, it won't crash any longer but of course the information is lost. This sound like it may be related.

[Player701]

Still happens in zdoom-x64-2.9pre-1486-g43b2584 (the latest devbuild available). Can't test with the latest GZDoom devbuild - for some reason, it closes (no fatal error and no Windows error dialog) after "Init texture manager" if I load daedalus.wad.

[Edward-san]

Graf is taking some time to merge the latest fixes to gzdoom, including the fixes to the texture manager, surely.

[Rachael]

He's probably just not working on it at the moment, due to his focus on ZScript.

Ask anyone who is able to do it to compile GZDoom with the latest ZDoom changes pulled though, and it should work fine. All you have to do is "git pull https://github.com/rheit/zdoom" on the GZDoom source tree and it will merge without conflicts (most of the time).

[Player701]

I used to compile everything myself in the past, but after a few system upgrades and reinstalls I'm just too lazy to install all the prerequisites again, especially those SDKs (several hundred MB each to compile a 6 MB program - wut?). I guess I'll just wait until the next devbuild is available.

[Rachael]

I used to compile everything myself in the past, but after a few system upgrades and reinstalls I'm just too lazy to install all the prerequisites again, especially those SDKs (several hundred MB each to compile a 6 MB program - wut?). I guess I'll just wait until the next devbuild is available.

QZDoom does exactly that, although it's got a lot of other things piled on top of it. (Nothing bad though!)

You have to enable OpenGL mode yourself (+vid_renderer 1) or copy your GZDoom config over - either way, it will work. It's in line with both GZDoom and ZDoom and usually stays up to date with both, and I try to keep it updated daily.

[Graf Zahl]

This is caused by one of Daedalus's global strings containing a character which is part of Windows Codepage 1252 but not the ISO 8859-1 charset and makes the JSON string verifier puke all over the place and fail, producing a broken output file which cannot be read back. That's why this wasn't noticed before. Now I need to find a working conversion routine between Codepage 1252 and UTF-8 to bypass that verifier...

[Graf Zahl]

fixed