MantisBT - Zandronum |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0002435 | Zandronum | [All Projects] Bug | public | 2015-09-04 17:09 | 2021-12-17 14:37 |
|
| Reporter | Zalewa | |
| Assigned To | Kaminsky | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | 2.1 | |
| Target Version | 3.1 | Fixed in Version | 3.1 | |
|
| Summary | 0002435: Global ACS variables are not reset upon map reset in survival. |
| Description | Global ACS variables are not reset upon map reset in survival. |
| Steps To Reproduce | 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. |
| Additional Information | Build:'http://zandronum.com/downloads/testing/3.0/ZandroDev3.0-150831-1814windows.zip [^]' |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  globalvars.wad (1,113) 2015-09-04 17:09
https://zandronum.com/tracker/file_download.php?file_id=1639&type=bug |
|
| 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 | bug_revision_view_page.php?bugnote_id=13398#r8010 |
| 2015-09-04 17:37 | Zalewa | Note Edited: 0013398 | bug_revision_view_page.php?bugnote_id=13398#r8011 |
| 2015-09-04 18:08 | Hypnotoad | Note Added: 0013399 | |
| 2015-09-04 18:09 | Hypnotoad | Note Edited: 0013399 | bug_revision_view_page.php?bugnote_id=13399#r8013 |
| 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 | bug_revision_view_page.php?bugnote_id=13401#r8015 |
| 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 | bug_revision_view_page.php?bugnote_id=13415#r8026 |
| 2015-09-05 13:26 | Ivan | Note Added: 0013419 | |
| 2015-09-05 13:27 | Ivan | Note Edited: 0013419 | bug_revision_view_page.php?bugnote_id=13419#r8030 |
| 2015-09-05 13:27 | Ivan | Note Edited: 0013419 | bug_revision_view_page.php?bugnote_id=13419#r8031 |
| 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 | bug_revision_view_page.php?bugnote_id=21577#r13275 |
| 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 |
|
Notes |
|
|
|
|
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. |
|
|
|
(0013398)
|
|
Zalewa
|
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.
|
|
|
|
(0013399)
|
|
Hypnotoad
|
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?
|
|
|
|
(0013400)
|
|
Dusk
|
|
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. |
|
|
|
(0013401)
|
|
Zalewa
|
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).
|
|
|
|
(0013402)
|
|
Dusk
|
|
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. |
|
|
|
|
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. |
|
|
|
(0013415)
|
|
Dusk
|
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.
|
|
|
|
(0013419)
|
|
Ivan
|
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.
|
|
|
|
|
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? |
|
|
|
(0013421)
|
|
Ivan
|
|
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. |
|
|
|
(0013449)
|
|
Dusk
|
|
2015-09-06 18:15
|
|
|
A compatibility flag and an automatic compat setting for zdcmp2 would be fine by me. |
|
|
|
(0013450)
|
|
Zalewa
|
|
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. |
|
|
|
(0013451)
|
|
Dusk
|
|
2015-09-06 19:43
|
|
|
No. Like any other compatflag, it should be on when broken behavior is encountered, off otherwise. |
|
|
|
|
|
For the record, 2.1.2 and 3.0 behave the same in this regard. |
|
|
|
|
|
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. |
|
|
|
(0020028)
|
|
Ivan
|
|
2018-10-08 20:51
|
|
|
What is the conclusion for the behavior for this? Will it be the compatflag discussed? |
|
|
|
(0021577)
|
|
doomjoshuaboy
|
2020-12-09 21:51
(edited on: 2020-12-09 21:52) |
|
This was added in zandronum but need further testing. Thanks to Kaminsky.
|
|
|
|
|
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. |
|