I don't think telefragging is necessarily the culprit. I think anything that changes the state on a light-bound actor in the very first level tic will trigger the issue. Telefragging does (because it kills, and therefore sets state to Death), but other circumstances may cause it. One may imagine an OPEN or ENTER script which activates or deactivates lights, for example.NeuralStunner wrote:There are indeed a lot of overlapping flames on the map. They shouldn't be telefragging one another, though.
Crash on startup in Congestion 64 MAP20, Hexen MAP40, etc.
Moderator: Graf Zahl
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3
- Enjay
- Developer
- Posts: 4723
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3
There is an open script that basically randomises which flame is active (to give the fires a more natural look I suppose). However, removing the scripts in the map and replacing them with a BEHAVIOUR lump that has no scripts did not stop the crash.Gez wrote:One may imagine an OPEN or ENTER script which activates or deactivates lights, for example.
Digging a bit further though, many of the flames in the map are set to be dormant. So I guess that they spawn and then immediately go to their inactive state creating the "change of state in the first tic" necessary to cause the crash. Certainly redefining the flame so that it is not a switchable decoration stops the crash as does setting all the flames on the map so that their dormant flag is not set.
So, yes, that does seem to be the explanation. The flames are set to be dormant so they spawn and immediately change to their inactive state causing the change of state needed to make the crash happen.
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
Confirmation enough; I'm merging both threads.
As demonstrated with the Hexen situation, this is not the actual problem. The actual problem is the uninitialized light stuff. It does seem like moving PrepareSegs() out of PreprocessLevel() so that it can be called before spawning map things is the only sane way to proceed. Delaying all state changes by one tic would be incredibly hacky.Graf Zahl wrote:Why not fix the actual problem: Telefragging in the spawn code must be delayed until after the level is completely set up. I have had problems with that before but it seems I didn't fully fix them.
- Enjay
- Developer
- Posts: 4723
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
Just giving this one a gentle nudge (not nagging) to see if there are any thoughts on the matter as to how to address it. With ZDoom in a position where it looks like an official release might not be far away, it struck me that this bug in particular prevents GZDoom running one of the stock IWADs if the ancillary files packaged with GZDoom are loaded and enabled.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
Because this is not a trivial thing that's fixed easily without introducing side effects into the engine. Reshuffling the init code is not a solution.
And as it stands, I simply don't have time to work on this for at least one more month.
And as it stands, I simply don't have time to work on this for at least one more month.
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
Well, in the meantime, I have a very simple hack fix to the issue:
It's not elegant, but it's simple and it'll mask the problem for the time being.
Code: Select all
if (level.maptime == 0) return;
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
Where would that be?
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
In CollectWithinRadius() of course. See r1295.
Really, the fundamental design flaw is that when a seg is created, its partner seg is not immediately nulled and is allowed to hold random garbage until the level is preprocessed.
Really, the fundamental design flaw is that when a seg is created, its partner seg is not immediately nulled and is allowed to hold random garbage until the level is preprocessed.
- Enjay
- Developer
- Posts: 4723
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
Unfortunately this band-aid fix has a side effect (at least I assume that it's an effect of the "fix").
Here is Heretic with GZDoom official and lights.pk3:
The key gizmo things, ammo and staff-wand puff are all giving off dynamic lights.
Here is much the same scene with r1296 (ignore the fact that sector lighting mode is different - it doesn't affect the result)
The key gizmo things and ammo have lost their lights but the wand puff still glows.
I'm not sure what the "rules" are for what shows up and what doesn't. I thought it might be something to do with being present in the map versus spawned at game time but the armour helmet in the first room of Doom2 MAP01 is glowing green just as I would expect.
[edit] Just looked a little further in Doom and things like pickups seem to have their lights but other objects (eg torches) do not. [/edit]
Here is Heretic with GZDoom official and lights.pk3:
The key gizmo things, ammo and staff-wand puff are all giving off dynamic lights.
Here is much the same scene with r1296 (ignore the fact that sector lighting mode is different - it doesn't affect the result)
The key gizmo things and ammo have lost their lights but the wand puff still glows.
I'm not sure what the "rules" are for what shows up and what doesn't. I thought it might be something to do with being present in the map versus spawned at game time but the armour helmet in the first room of Doom2 MAP01 is glowing green just as I would expect.
[edit] Just looked a little further in Doom and things like pickups seem to have their lights but other objects (eg torches) do not. [/edit]
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
- Enjay
- Developer
- Posts: 4723
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
Unfortunately, it's still not right. Map placed dynamic lights (and perhaps other ones too) don't seem to be getting clipped properly in some cases.
The following screenshots with odd looking lights were taken in 1297. The ones showing how things shold look were taken with r1294.
[edit] Spoilered to take up less space [/edit]
[spoiler]r1297 no coloured lights in the tunnels:
how it should be:
Up close, you can see that the lights are there, they are just being clipped wrongly. Rather than filling the tunnel with light, the lights are only illuminating a small area and cut off abruptly.
And more (not just slopes)...
r1297 one side of each light cuts off abruptly:
and how it should look:
r1297 sloped light has a strange bright band:
and how it should look:
[/spoiler]
I haven't managed to get a good demo map that shows off the problem but if one is needed I'll try and get one where one of these problems occur.
The following screenshots with odd looking lights were taken in 1297. The ones showing how things shold look were taken with r1294.
[edit] Spoilered to take up less space [/edit]
[spoiler]r1297 no coloured lights in the tunnels:
how it should be:
Up close, you can see that the lights are there, they are just being clipped wrongly. Rather than filling the tunnel with light, the lights are only illuminating a small area and cut off abruptly.
And more (not just slopes)...
r1297 one side of each light cuts off abruptly:
and how it should look:
r1297 sloped light has a strange bright band:
and how it should look:
[/spoiler]
I haven't managed to get a good demo map that shows off the problem but if one is needed I'll try and get one where one of these problems occur.
- Enjay
- Developer
- Posts: 4723
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
Map attached
Incorrect:
Correct:
Incorrect:
Correct:
- Attachments
-
- badlight.zip
- (1.02 KiB) Downloaded 100 times
- Gez
- Developer
- Posts: 1399
- Joined: Mon Oct 22, 2007 16:47
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
The only ways to fix that is to either reinstate the crash on startup or to properly init the segs before map objects are spawned.
Apparently I can't give a constructor to segs. Because somehow it makes LoadGLSegs() into a "function that requires object unwinding", whatever that means.
So, this will have to wait for Graf to devise a better fix. In the meantime, I think broken static dynamic lights in complex maps are preferable to random crashes on startup in IWAD maps.
Apparently I can't give a constructor to segs. Because somehow it makes LoadGLSegs() into a "function that requires object unwinding", whatever that means.
So, this will have to wait for Graf to devise a better fix. In the meantime, I think broken static dynamic lights in complex maps are preferable to random crashes on startup in IWAD maps.
Last edited by Gez on Sun Mar 04, 2012 10:08, edited 1 time in total.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
The only way to fix it is to disable the light linking on map start but then explicitly do it once everything has been set up.
And the check for maptime is clearly in the wrong function.
And the check for maptime is clearly in the wrong function.
- Enjay
- Developer
- Posts: 4723
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et
I don't know about "complex" (eg the raised square thing in the demo map) but I suppose, on principle, I agree with that. However, in practical terms, I suggest that breaking how dynamic lights behave is likely to generate just as many, if not more, bug reports as the crash and might gain GZDoom a reputation for "not handling dynamic lights properly".Gez wrote:I think broken static dynamic lights in complex maps are preferable to random crashes on startup in IWAD maps.
I know that I can't remember the last time I wanted to play Hexen MAP40 (other than to check this crash) but I do edit maps with dynamic lights all the time and the stop-gap fix makes the current SVN builds an unsuitable base for doing that.
Perhaps it would be better to simply revert the fix and not produce an "official" GZDoom release until this problem can be properly addressed, even if ZDoom "goes gold" in the meantime