Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002435Zandronum[All Projects] Bugpublic2015-09-04 17:092021-12-17 14:37
ReporterZalewa 
Assigned ToKaminsky 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version2.1 
Target Version3.1Fixed in Version3.1 
Summary0002435: Global ACS variables are not reset upon map reset in survival.
DescriptionGlobal ACS variables are not reset upon map reset in survival.
Steps To Reproduce1. 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.
Additional InformationBuild:'http://zandronum.com/downloads/testing/3.0/ZandroDev3.0-150831-1814windows.zip [^]'
Attached Files? file icon globalvars.wad [^] (1,113 bytes) 2015-09-04 17:09

- Relationships

-  Notes
User avatar (0013397)
Hypnotoad (reporter)
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.
User avatar (0013398)
Zalewa (developer)
2015-09-04 17:36
edited on: 2015-09-04 17:37

 According to the ZDoom wiki ('http://zdoom.org/wiki/Scope [^]' ), 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.
User avatar (0013399)
Hypnotoad (reporter)
2015-09-04 18:08
edited on: 2015-09-04 18:09
Quote
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.

Quote
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.

Quote
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?
User avatar (0013400)
Dusk (developer)
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.
User avatar (0013401)
Zalewa (developer)
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).
User avatar (0013402)
Dusk (developer)
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.
User avatar (0013413)
Torr Samaho (administrator)
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.
User avatar (0013415)
Dusk (developer)
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.
User avatar (0013419)
Ivan (reporter)
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.
User avatar (0013420)
Torr Samaho (administrator)
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?
User avatar (0013421)
Ivan (reporter)
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.
User avatar (0013449)
Dusk (developer)
2015-09-06 18:15

 A compatibility flag and an automatic compat setting for zdcmp2 would be fine by me.
User avatar (0013450)
Zalewa (developer)
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.
User avatar (0013451)
Dusk (developer)
2015-09-06 19:43

 No. Like any other compatflag, it should be on when broken behavior is encountered, off otherwise.
User avatar (0017018)
Torr Samaho (administrator)
2017-03-19 17:00

 For the record, 2.1.2 and 3.0 behave the same in this regard.
User avatar (0017173)
StrikerMan780 (reporter)
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.
User avatar (0020028)
Ivan (reporter)
2018-10-08 20:51

 What is the conclusion for the behavior for this? Will it be the compatflag discussed?
User avatar (0021577)
doomjoshuaboy (developer)
2020-12-09 21:51
edited on: 2020-12-09 21:52

 This was added in zandronum but need further testing. Thanks to Kaminsky.
User avatar (0021919)
Kaminsky (developer)
2021-12-17 14:37

 By testing the example wad both offline and online in 3.1, if I press the switch several times then die and wait until the map restarts this is what happens:

- If "compat_resetglobalvarsonmapreset" is disabled, the counter isn't reset back to 0. This is how it's always behaved in Zandronum.
- If the compatflag is enabled, then the counter is reset back to 0.

So in general, if global/world variables must also be reset upon resetting the map, the compatflag above should be enabled.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2015-09-04 17:09 Zalewa New Issue
2015-09-04 17:09 Zalewa File Added: globalvars.wad
2015-09-04 17:14 Hypnotoad Note Added: 0013397
2015-09-04 17:36 Zalewa Note Added: 0013398
2015-09-04 17:37 Zalewa Note Edited: 0013398 View Revisions
2015-09-04 17:37 Zalewa Note Edited: 0013398 View Revisions
2015-09-04 18:08 Hypnotoad Note Added: 0013399
2015-09-04 18:09 Hypnotoad Note Edited: 0013399 View Revisions
2015-09-04 18:15 Dusk Note Added: 0013400
2015-09-04 18:22 Zalewa Note Added: 0013401
2015-09-04 18:23 Zalewa Note Edited: 0013401 View Revisions
2015-09-04 18:38 Dusk Note Added: 0013402
2015-09-05 11:48 Torr Samaho Note Added: 0013413
2015-09-05 12:38 Dusk Note Added: 0013415
2015-09-05 12:39 Dusk Note Edited: 0013415 View Revisions
2015-09-05 13:26 Ivan Note Added: 0013419
2015-09-05 13:27 Ivan Note Edited: 0013419 View Revisions
2015-09-05 13:27 Ivan Note Edited: 0013419 View Revisions
2015-09-05 14:20 Torr Samaho Note Added: 0013420
2015-09-05 14:35 Ivan Note Added: 0013421
2015-09-06 18:15 Dusk Note Added: 0013449
2015-09-06 18:53 Zalewa Note Added: 0013450
2015-09-06 19:43 Dusk Note Added: 0013451
2015-09-06 20:16 Dusk Assigned To => Dusk
2015-09-06 20:16 Dusk Status new => assigned
2016-11-20 21:39 Edward-san Product Version 3.0 => 3.0-beta
2016-12-24 22:42 Dusk Target Version => 3.0
2017-03-19 17:00 Torr Samaho Note Added: 0017018
2017-03-19 17:00 Torr Samaho Product Version 3.0-beta => 2.1
2017-04-08 10:38 Torr Samaho Target Version 3.0 => 3.1
2017-04-17 17:09 StrikerMan780 Note Added: 0017173
2018-10-08 20:51 Ivan Note Added: 0020028
2019-06-04 21:54 Dusk Status assigned => new
2020-12-09 21:51 doomjoshuaboy Note Added: 0021577
2020-12-09 21:51 doomjoshuaboy Status new => needs testing
2020-12-09 21:52 doomjoshuaboy Note Edited: 0021577 View Revisions
2021-12-17 14:37 Kaminsky Note Added: 0021919
2021-12-17 14:37 Kaminsky Status needs testing => resolved
2021-12-17 14:37 Kaminsky Fixed in Version => 3.1
2021-12-17 14:37 Kaminsky Resolution open => fixed
2021-12-17 14:37 Kaminsky Assigned To Dusk => Kaminsky




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker