MantisBT - Zandronum
View Issue Details
0002435Zandronum[All Projects] Bugpublic2015-09-04 17:092020-12-09 21:52
needs testingopen 
0002435: Global ACS variables are not reset upon map reset in survival.
Global ACS variables are not reset upon map reset in survival.
1. Run the attached globalvars.wad on a server in survival mode.
2. Press the switch as many times you want. It will increment counter each time it's pressed.
3. Die so that map restarts.
4. Press the switch again - counter doesn't get reset.
Build: [^]
No tags attached.
? globalvars.wad (1,113) 2015-09-04 17:09
Issue History
2015-09-04 17:09ZalewaNew Issue
2015-09-04 17:09ZalewaFile Added: globalvars.wad
2015-09-04 17:14HypnotoadNote Added: 0013397
2015-09-04 17:36ZalewaNote Added: 0013398
2015-09-04 17:37ZalewaNote Edited: 0013398bug_revision_view_page.php?bugnote_id=13398#r8010
2015-09-04 17:37ZalewaNote Edited: 0013398bug_revision_view_page.php?bugnote_id=13398#r8011
2015-09-04 18:08HypnotoadNote Added: 0013399
2015-09-04 18:09HypnotoadNote Edited: 0013399bug_revision_view_page.php?bugnote_id=13399#r8013
2015-09-04 18:15DuskNote Added: 0013400
2015-09-04 18:22ZalewaNote Added: 0013401
2015-09-04 18:23ZalewaNote Edited: 0013401bug_revision_view_page.php?bugnote_id=13401#r8015
2015-09-04 18:38DuskNote Added: 0013402
2015-09-05 11:48Torr SamahoNote Added: 0013413
2015-09-05 12:38DuskNote Added: 0013415
2015-09-05 12:39DuskNote Edited: 0013415bug_revision_view_page.php?bugnote_id=13415#r8026
2015-09-05 13:26IvanNote Added: 0013419
2015-09-05 13:27IvanNote Edited: 0013419bug_revision_view_page.php?bugnote_id=13419#r8030
2015-09-05 13:27IvanNote Edited: 0013419bug_revision_view_page.php?bugnote_id=13419#r8031
2015-09-05 14:20Torr SamahoNote Added: 0013420
2015-09-05 14:35IvanNote Added: 0013421
2015-09-06 18:15DuskNote Added: 0013449
2015-09-06 18:53ZalewaNote Added: 0013450
2015-09-06 19:43DuskNote Added: 0013451
2015-09-06 20:16DuskAssigned To => Dusk
2015-09-06 20:16DuskStatusnew => assigned
2016-11-20 21:39Edward-sanProduct Version3.0 => 3.0-beta
2016-12-24 22:42DuskTarget Version => 3.0
2017-03-19 17:00Torr SamahoNote Added: 0017018
2017-03-19 17:00Torr SamahoProduct Version3.0-beta => 2.1
2017-04-08 10:38Torr SamahoTarget Version3.0 => 3.1
2017-04-17 17:09StrikerMan780Note Added: 0017173
2018-10-08 20:51IvanNote Added: 0020028
2019-06-04 21:54DuskStatusassigned => new
2020-12-09 21:51doomjoshuaboyNote Added: 0021577
2020-12-09 21:51doomjoshuaboyStatusnew => needs testing
2020-12-09 21:52doomjoshuaboyNote Edited: 0021577bug_revision_view_page.php?bugnote_id=21577#r13275

2015-09-04 17:14   
I believe that's the entire purpose of global variables, they're at a higher scope than map scope, so that their values persist after map change or map reset.
2015-09-04 17:36   
(edited on: 2015-09-04 17:37)
According to the ZDoom wiki ( [^] ), global variables are reset upon starting a new game. In case of survival it produces some behavior ambiguity. For example, restarting the map with "(rcon) map mapxx" ccmd will reset the global variable, but restarting the map because all players died won't.

It's probably better to resolve such ambiguity in Zandronum's behavior before modders start depending on current behavior.

I've only reported this because it produces erroneous behavior in ZDCMP2.pk3. In there, picking up some items always produces a message popup, even after survival reset, but picking up guns, which are tracked by global variables, produces the message only once.

2015-09-04 18:08   
(edited on: 2015-09-04 18:09)
global variables are reset upon starting a new game.

I believe starting a new game in this context means literally going to the menu and click on new game. I don't consider the map resetting under survival when everyone dies equivalent.

For example, restarting the map with "(rcon) map mapxx" ccmd will reset the global variable, but restarting the map because all players died won't.

I don't think it's ambiguous, assuming using changemap rather than map will not reset the variables. The 'MAP' command is basically equivalent to starting a brand new game and warping to the desired map, so it makes sense to reset everything there, while 'CHANGEMAP' is equivalent to exiting to a new (or the same) level within the same game session, so global variables should not be reset.

It's probably better to resolve such ambiguity in Zandronum's behavior before modders start depending on current behavior.

Global variables have been in Zandronum and skulltag for a while, what makes you think modders don't already depend on this behaviour?

2015-09-04 18:15   
Resetting the map does not restart the game and thus shouldn't reset global variables, IMO. The WAD should be keeping track of weapons at map scope instead of global scope but isn't and is thus doing something wrong that only shows symptoms in Zandronum's survival.
2015-09-04 18:22   
(edited on: 2015-09-04 18:23)
It's only a matter of what was the intended behavior for global variables here.

Since ZDoom doesn't have similar situation where map is reset by a game mode, the issue resides only in Zandronum and description in ZDoom wiki doesn't fully relate. So far, map reset in survival was resetting everything, up to breaking hub WADs (although I don't know what's the current status here). In my opinion, having a method to persist variables between map resets can be useful. Global variables can be used for this right now. However, I want to emphasize my question: was this the intended behavior for global variables from the start, or did it occur simply by omission? Bug history shows that there were other things that didn't reset in survival simply because they were omitted by mistake. If this global variables behavior is due to an omission, then it should be explicitly decided upon and documented somewhere (Zandronum wiki, or even ZDoom wiki if possible).

2015-09-04 18:38   
I don't know whether it was intended or not but nevertheless I don't think a map reset should trigger a world or global variable reset. You're still staying on the same map, after all.
Torr Samaho   
2015-09-05 11:48   
I think we need to look at the issue from a different perspective. Whether global variables are intentionally or accidentally not reset doesn't really matter, although I'm quite sure that this is an oversight.

What matters is that survival works on non-hub maps. If it doesn't work properly, it's a bug and we should try to fix it. So if not resetting global variables breaks survival on a proper ZDoom map, we'll have to reset the variables. In case existing mods rely on the buggy behavior, we'll have to introduce a compat flag that allows to re-enable the buggy behavior.
2015-09-05 12:38   
(edited on: 2015-09-05 12:39)
I think we should do the opposite and introduce a compatibility.txt setting for zdcmp2 that resets global variables in map resets. The game is not reset so global variables shouldn't be reset either.

Just because a wad is doing something wrong that only causes effects in Zandronum doesn't mean it's not wrong.

2015-09-05 13:26   
(edited on: 2015-09-05 13:27)
Well, on this regard I'll agree with Dusk as I use this behavior quite often. In fact I've been using this behavior for quite a while now. (Due to the needs to store many information that shouldn't be lost despite a simple map restart, and not just Survival but for modes like TLMS too). This entire topic is something that Zandronum and ZDoom are entirely different on and we shouldn't feel obligated to follow ZDoom as the "right" example here.

Torr Samaho   
2015-09-05 14:20   
Quote from Dusk

Just because a wad is doing something wrong that only causes effects in Zandronum doesn't mean it's not wrong.

After reading the ZDoom Wiki description of global vars, I'm beginning to think that the concept of global vars is simply incompatible with our map reset handling, i.e. neither resetting global vars nor keeping them is correct for all constructions that work perfectly fine in ZDoom. So to me it looks like we'll have to add a flag that allows to toggle whether global vars are reset or not.

Since many mods apparently rely on the current behavior, the default value of the flag should be not to reset the vars. Opinions?
2015-09-05 14:35   
I'd like this. Off the top of my head your default is the current behavior in GvH and DnD. Any other mod that save stuff also benefits from this, which I'm sure there are more than these two.
2015-09-06 18:15   
A compatibility flag and an automatic compat setting for zdcmp2 would be fine by me.
2015-09-06 18:53   
Compatibility flag is a good idea, and it will even be simple to know when it should be on or off. Zandronum mods - globals don't reset unless readme states otherwise, ZDoom mods - globals do reset unless readme states otherwise.
2015-09-06 19:43   
No. Like any other compatflag, it should be on when broken behavior is encountered, off otherwise.
Torr Samaho   
2017-03-19 17:00   
For the record, 2.1.2 and 3.0 behave the same in this regard.
2017-04-17 17:09   
I don't think they should be reset entirely, just reverted to whatever the value was at the start of the map (like what would happen if you loaded a save). Global variables carry between maps, in both Zan and ZDoom, and should be kept that way.
2018-10-08 20:51   
What is the conclusion for the behavior for this? Will it be the compatflag discussed?
2020-12-09 21:51   
(edited on: 2020-12-09 21:52)
This was added in zandronum but need further testing. Thanks to Kaminsky.