Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
printz

E3M5 vigilant cacodemon

Recommended Posts

I'm sure anyone who's played Doom has encountered the situation when a cacodemon suddenly wakes up in E3M5: Unholy Cathedral. It happens when you come back from the Demon&Berserk yard to the cloister, via the teleporter. The cacodemon from the hallway with metal niches wakes up as you teleport back into the 2x2 glowing pad.

To my sadness this effect doesn't happen any more in (the latest) Eternity, let alone ZDoom, but it still happens in MBF (actually MBF-mode through PRBoom). I haven't checked it for current PRBoom mode, because for some reason I couldn't get it to work, and unfortunately I don't have PRBoom-plus by me now (too little time).

Still, if anyone knows, what triggers this? A leak in the node tree or blockmap grid? Can it be reproduced to work on modern ports? Would be interesting to be able to wake up monsters (in plain Doom) without having to shoot.

Share this post


Link to post

After teleporting, the player and the caco both have y-coordinate exactly 928. Best I can tell is there's also a bsp node line running along linedef 195, i.e. with constant y-coordinate of exactly 928 as well. So you have a horizontal node line, and both player and caco are directly on top of it.

The fact that it is horizontal (dy==0) means P_DivLineSide gets the answer wrong due to comparing against the wrong coordinate (x instead of y) as described on the sleeping sergeant bug fix page. So in old complevels where the bug is emulated the caco can "see" you even though it really can't.

It's probably a bad idea to try to make a level that relies on this kind of thing.

Share this post


Link to post

I'm guessing it's a node/blockmap issue accompanyed with the linedef stuff above. Kinda like the MAP02 sergeant, which would be fixed with a node rebuild (in the MAP02 case, yes..dunno about the E3M5 caco)

Share this post


Link to post

EE still does this incorrectly when demos are playing, but this kind of minor fix wasn't considered significant enough to have a comp variable.

RjY's description was 100% accurate so there's no need for further speculation on the cause of this.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×