Weird problem in map

So I just finished up a map and when I go to test it in PrBoom+, there's a Demon in the room directly in front of you past a fully closed door in a totally different sector which wakes up right off the bat and seeks the player through the door (it's set to allow monsters to open it). In ZDoom/GZDoom, this doesn't happen. The Demon stays where he should. But in PrBoom, he is immediately awake and is already coming for the player.

Some info:
- Nodebuilder used is ZDBSP 1.19 Normal (zero reject)
- Using extended nodes
- Lots of voodoo dolls in use but none in view of monsters

Could this have something to do with the way PrBoom handles REJECT lumps? Since I'm using zero REJECT, could that be screwing with the sight lines and somehow the Demon can see me through the wall even without shooting or it even having a sight line on me to begin with? There's like 835 monsters and the map is pretty big (6784 wide, 11136 tall).

Any ideas as to what the hell is going on?

Questions like this normally cannot be answered without seeing the map.

One question: What compatibility level are you using? This sounds suspiciously like the bug in the Doom 1.2 sight checking code.

I was testing using -complevel 9.

I think even other enemies on the map might have been detecting me too, but the weirdest part is it seems like it was only Demons.

Anyway, here's the map if you wanna check it out. Everything else on the map works flawlessly in PrBoom+ like it's supposed to.

The map requires cc4-tex.wad right now, it's part of a project coming soon, MAP25 slot:
http://www.mediafire.com/download/7abf2jc64bdn618/64x64_TrialsofIniquity_v1.zip

Uses some ZDoom stuff but the map itself still works and all. See if the Demon I'm talking about tracks you too, if you start the map and just wait, it should reach the door in front of you within 30 seconds.

Try another nodebuilder. ZDBSP was made for ZDoom, as the name says.

bzzrak said:

Try another nodebuilder. ZDBSP was made for ZDoom, as the name says.

Please stop spreading such misinformation.

Should I try saving with normal REJECT? No zero or empty?

Try moving the monster several map units along both x and y axes. If your problem is a case of the "sleeping sergeant" bug, it should help.

Got another weird thing going on.

The start position of the map is a symmetrical area with four Imps and four Hell Knights around you facing outwards. If you fire and just stand still, the Imps and HKs to the North, West, and South will all immediately converge on your position (which is intended and expected), but the Imp and HK to the East will instead travel to the East (the same direction they are facing) for about 64-80 units before turning around towards the player and attacking as expected.

This wouldn't be a concern except for the fact that there is a door within that same range that the HK reaches and will open about 75% of the time, which is an unintended mechanic that early in the level. Unlike the previous problem, this DOES happen in ZDoom.

So... what the hell?

http://doomwiki.org/wiki/Monsters_fleeing

You can use Boom generalized doors; you can control whether monsters can use them or not.

rdwpa said:

http://doomwiki.org/wiki/Monsters_fleeing

You can use Boom generalized doors; you can control whether monsters can use them or not.

Ok, but how does that explain the fact that only the two monsters to the east flee? The others facing north, south, and west all engage the player and they are set up exactly the same as the ones to the east. And I know about doors, but the thing is I DO want monsters to be able to use them, just not at this moment.

EDIT: Ok WTF... I moved the Hell Knight right beside the player and he still walks all the way to the door and then back. There's nothing blocking his view or path to the player. ???

This happens when monsters have a direct path too. For example at the end of Doom II map03, with the pinkies on the ledge. It's easy to see in UV-Speed and Nightmare runs -- the pinkies just run away.

rdwpa said:

http://i.imgur.com/0upWK7b.png

This happens when monsters have a direct path too. For example at the end of Doom II map03, with the pinkies on the ledge. It's easy to see in UV-Speed and Nightmare runs -- the pinkies just run away.

Yeah I see that all the time even when I'm just casually playing Doom II through for whatever reason. Also, I got a good laugh out of that troll Hell Knight picture. That's basically what he's doing is trolling me hard right now.

It doesn't seem to occur if the player moves around first or even moves around in a radius of about 32 units, which most players will most likely do right away.

Nevander said:

Ok, but how does that explain the fact that only the two monsters to the east flee?

Behavior of Doom engine's monster AI logic isn't perfectly symmetric/rotation-equivalent at different axes. See also this picture by Linguica.

Nevander said:

Unlike the previous problem, this DOES happen in ZDoom.

Source ports just keep the behavior the way it is, because they have no reason to do otherwise (it might have already got intuitive for experienced players), especially if they want to maintain at least some kind of compatibility with previous engines.

scifista42 said:

Behavior of Doom engine's monster AI logic isn't perfectly symmetric/rotation-equivalent at different axes. See also this picture by Linguica.

Huh. So that explains why monsters spaz out when sitting on top of a tight space and can't move vertically or horizontally. They are constantly trying to move in all 8 directions. Like if you put an Arch-Vile on an elevated sector the same size as its hitbox and too tall to walk down. Or have a ton of monsters in a tight space (which causes problems of their own if they are stuck, most notably skips in sound effects like the Chaingun).

Yes, a monster must keep moving at all times while it's active, and if it can't make a step in either direction, it considers itself stuck. That's actually how "being stuck" works in principle. It's not that the monster's current position is blocked, it's that all of the monster's potential next positions are blocked.