Crash on startup in Congestion 64 MAP20, Hexen MAP40, etc.

Bugs that have been resolved.

Moderator: Graf Zahl

User avatar
Gez
Developer
Developer
Posts: 1395
Joined: Mon Oct 22, 2007 16:47

Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3

Post by Gez » Mon Dec 26, 2011 22:47

NeuralStunner wrote:There are indeed a lot of overlapping flames on the map. They shouldn't be telefragging one another, though. :?
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.

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4598
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3

Post by Enjay » Mon Dec 26, 2011 23:26

Gez wrote:One may imagine an OPEN or ENTER script which activates or deactivates lights, for example.
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.

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.

User avatar
Gez
Developer
Developer
Posts: 1395
Joined: Mon Oct 22, 2007 16:47

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Gez » Tue Dec 27, 2011 15:45

Confirmation enough; I'm merging both threads.
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.
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.

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4598
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Enjay » Fri Mar 02, 2012 19:16

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.

User avatar
Graf Zahl
GZDoom Developer
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

Post by Graf Zahl » Fri Mar 02, 2012 19:29

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.

User avatar
Gez
Developer
Developer
Posts: 1395
Joined: Mon Oct 22, 2007 16:47

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Gez » Fri Mar 02, 2012 23:03

Well, in the meantime, I have a very simple hack fix to the issue:

Code: Select all

	if (level.maptime == 0) return;
It's not elegant, but it's simple and it'll mask the problem for the time being.

User avatar
Graf Zahl
GZDoom Developer
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

Post by Graf Zahl » Sat Mar 03, 2012 2:00

Where would that be?

User avatar
Gez
Developer
Developer
Posts: 1395
Joined: Mon Oct 22, 2007 16:47

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Gez » Sat Mar 03, 2012 12:33

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.

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4598
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Enjay » Sat Mar 03, 2012 23:17

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:

Image
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)

Image

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]

User avatar
Gez
Developer
Developer
Posts: 1395
Joined: Mon Oct 22, 2007 16:47

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Gez » Sat Mar 03, 2012 23:29

Fixed.

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4598
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Enjay » Sun Mar 04, 2012 3:17

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:
Image

how it should be:
Image

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

And more (not just slopes)...

r1297 one side of each light cuts off abruptly:
Image

and how it should look:
Image

r1297 sloped light has a strange bright band:
Image

and how it should look:
Image[/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.

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4598
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Enjay » Sun Mar 04, 2012 3:27

Map attached

Incorrect:
Image

Correct:
Image
Attachments
badlight.zip
(1.02 KiB) Downloaded 66 times

User avatar
Gez
Developer
Developer
Posts: 1395
Joined: Mon Oct 22, 2007 16:47

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Gez » Sun Mar 04, 2012 10:04

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.
Last edited by Gez on Sun Mar 04, 2012 10:08, edited 1 time in total.

User avatar
Graf Zahl
GZDoom Developer
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

Post by Graf Zahl » Sun Mar 04, 2012 10:06

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.

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4598
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: Crash on startup in Congestion 64 MAP20, Hexen MAP40, et

Post by Enjay » Sun Mar 04, 2012 13:30

Gez wrote:I think broken static dynamic lights in complex maps are preferable to random crashes on startup in IWAD maps.
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".

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 :?:

Locked

Return to “Closed Bugs”