ZDoom

Hi there,

To produce this bug, go to E2M6 "Terro Cube" and use the 'warp' command with these coordinates:

X:2844, Y:-2362

and 'notarget' so monsters won't give any trouble.

After you warp, turn left and you will see three poly pillars with skulls textures. Press the green one to spin it and wait for few seconds (give it 30 seconds max?? and I think it needs to be in your fov). ZDoom will simply freeze after that.

There is no crash so I can't upload a Crash Report. In fact, if you check on ZDoom's status in Windows Task Manager you will notice that it's 'Running'
not 'Not Responding'. So Terminating ZDoom's process will close ZDoom normally.

The 'freeze' also happens with GZDoom in case you're wondering.

This is only relevant if it doesn't happen with older versions of ZDoom. It may well be a problem with the map. Can you verify this? (I don't want to bother going looking for my copy of ZPack)

ChronoSeth wrote:This is only relevant if it doesn't happen with older versions of ZDoom.

I'm not sure why. If it's a problem, then its a problem. It still happens with new versions so it needs to be looked at and fixed or eliminated as a "not Zdoom". If it also happens with old versions it could just mean that no one noticed it before.

Anyway, yes, following the instructions in the original post, I am able to replicate this in GZdoom and Zdoom SVN versions and also in the last official Zdoom release. GZdoom took about 40 seconds to freeze after activating the pillar whereas both versions of Zdoom only took about 10-15 seconds the first time but it was nearer to 40 seconds the next time I tried.

I tried this with an older version of (G)ZDoom, 2.4.1.2435 for ZDoom and 1.4.8.842 for GZDoom. I waited for two minutes and few seconds and the result that there was no freeze no crash, they just worked fine.

Maybe this has to do with polyobjects since the poly code has been improved/changed in 2.5.0.

Actually, ZPack crashed on me pretty badly on GZDoom, too. I can't remember which map it was since it has been some time ago since I fired it into the corner with frustration, but it might have been on the same map. You would open a door to a room, and as soon as you take a look inside, instant crash. Eventually, this made the whole episode unplayable, so I gave up on it.

Wrong reaction! You are supposed to post a bug report with the crash log. Now it can't be investigated anymore.

Well, I will try to reproduce it again as soon as I can. It's pretty easy to do, I know the places where it will crash.

NightFright wrote:Actually, ZPack crashed on me pretty badly on GZDoom, too. I can't remember which map it was since it has been some time ago since I fired it into the corner with frustration, but it might have been on the same map. You would open a door to a room, and as soon as you take a look inside, instant crash. Eventually, this made the whole episode unplayable, so I gave up on it.

I wonder if it is related to the crashing I got when verifying the bug from this thread?

I reported it here.

http://forum.drdteam.org/viewtopic.php?f=24&t=5315

It's probably not it though because I only started noticing it with the latest GZdoom.

It runs into this error condition while building the BSP for the rotating polyobject:
(nodebuild.cpp line 831)

and if that happens the node builder goes into an infinite loop.

Alright, so the dynamic node building algorithm introduced for the enhanced polyobjects is hitting an infinite loop? I guess the question from me then is this is a bug or problem with the algorithm or is there something incorrectly set up with my polyobject?

This issue is nothing new.

Here you find more info about the problem. It can be avoided but it wasn't done yet because it would have an impact on performance and no map ran into it since the last round of fudging.

But I leave this to Randy. He knows this stuff better and may find another solution.

As per GZ's request, here's my map that reports an error in the console when the polyobj is activated: This is the message that pops up in the console: Last tested with R3152. It doesn't crash, freeze or anything though. As far as I can tell, everything works just fine.
[EDIT]
Still happens in R3279, and again, it doesn't crash or freeze me. I just get the message in the console.

I can't reproduce the freeze in r3179, I'm using linux, release and debug builds.

So, the problem also happens with Virus MAP03.

Fixed.