Hi!
GZDDoom 4.7.1 crashes out of program when exiting map 19 in NoSp2.wad (https://www.doomworld.com/idgames/level ... wads/nosp2) and Russian Overkill mod (viewtopic.php?t=29915)
To reproduce, simply load this wad with RO mod, go to map 19 and exit the game (type: warp -8419 -3508 -280 in console and exit lindef is nearby).
The bug is that GZDoom simply exits the program. I expect that if there is a error in mod's code then zscript/decorate engine would catch it and write error message in console/log. Currently no error is shown or logged, GZDoom simply exits.
GZDoom 4.7.1 + RO + NoSp2.wad map19 = crash
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
-
Kappes Buur
-
- Posts: 4120
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoom 4.7.1 + RO + NoSp2.wad map19 = crash
After investigating with UDB I suggest to change the linedef special from 97
Probably a momentary aberration by NoReason.
Spoiler:to 52, as was done in previous maps, to go to the next level.
Probably a momentary aberration by NoReason.
Re: GZDoom 4.7.1 + RO + NoSp2.wad map19 = crash
Tnx for that info. Dno if he fixes his map. But in my opinion it still shouldnt crash. I mean we should kinda expect maps to contain all kinds of garbage as they come from users with all sorts of backgrounds and all sorts of technical knowledge and so so on unless it's technically very hard to try-catch this issue. I think it would still be proper to exit with error message at least.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.7.1 + RO + NoSp2.wad map19 = crash
This is not fixable. It's some interaction between a huge group of more than 600 barrels and some bad DECORATE coding in RO that causes a stack overflow.
The barrel in RO calls A_Explode right in its death state without any delay - this means that one barrels goes boom, then inflicts radius damage to the next one, and so on for the entire group. This all happens recursively right in the first barrel's death state which eventually makes the engine crash. If there was a one-frame delay, it'd work as expected.
The barrel in RO calls A_Explode right in its death state without any delay - this means that one barrels goes boom, then inflicts radius damage to the next one, and so on for the entire group. This all happens recursively right in the first barrel's death state which eventually makes the engine crash. If there was a one-frame delay, it'd work as expected.