trying not to wake monsters

[cycloid]

i have a room, in this room is a linedef that, when crossed, opens several doors to spring a trap, obviously. except the fighting generated in the room beforehand wakes up the monsters in the secret side rooms. spoiling the surprise i reckon. it goes: the main room | architrave sector | door | sector with monster in. that's 3 whole "blocks sound" linedefs. could it be simple proximity to the player or something? the "deaf" flag doesnt help either so that's what i'm guessing.

thoughts?

[Ichor]

If you're using ZDoom, just make them dormant, and set a line trigger or make a script when you want to activate them.

[cycloid]

i'm making it boom compatible ... next!

[Grimm]

Deaf the SOBs. Or rebuid the nodes. Or rebuild the reject. Or delete them and put them back in again.

[Mordeth]

Monsters wake up for three different reasons: (1) they can hear the player, (2) they can see the player, or (3) they are hurt (directly or indirectly) by the player.

If you only want monsters to be awakened on sight, then just flag them 'deaf'.

There needs to be, at a minimum, TWO sound barriers (that is, TWO block sound linedefs) between one sector A and another sector B to prevent sound from reaching B from A. Sound does not travel from the point of origin, but from the SECTOR of origin. The origin can be a player firing but also the impact from weapons... so if you shoot your pistol across a sound barrier that barrier is breached even if you stayed outside. In case of a split sector, sound reaches ALL sector parts when entering any one of them. All sector parts then continue to transmit sound.

Closed doors always act as sound barriers unless opened, but you have to keep in mind that ALL access points to a particular sector (windows, other entrances) need to be soundproofed to prevent monsters inside from hearing you. Raised walls do not act as sound barriers.

[The Flange Peddler]

I don't remember this ever being mentioned, but I swear there's a bug in zdoom where the deaf flag doesn't work properly always (at least not for vanilla doom levels). I swear I've put deaf monsters in places before quite often, where they simply should not be awoken, and yet they get woken up early. This includes deaf monsters waking up on the other side of closed doors (where the room has no other entry), and coming through the door.

I don't know I'f I'm imagining this, but I'm sure it happens. Maybe it's a reject problem or something...

[Fredrik]

Sometimes monsters wake up earlier than they should despite being flagged deaf or put behind sound-blocking lines. This seems to be more common with complex maps and I assume it's a problem with the nodes builder. Could also be a bug in the engine, but results do vary with the change of nodes builder. The problem can sometimes be fixed by moving the monster just a few units to the side.

[sargebaldy]

if you're using zdoom, this is a reported error that's been fixed for 53.cab.

[Nanami]

Yeah, Randy made improvements to how the blockmap is applied, I believe.

[cyber-menace]

I know what ya mean on that part. Zdoom can be a pain in the but sometimes. Some of my monsters are awake that can be on the other side of the level only seconds into the map sometimes. It's really wierd and I hope Zdoom 2.53 won't be too long coming out.

[Nanami]

That bug has existed since the original Doom I believe.

[The Flange Peddler]

Nanami said:

That bug has existed since the original Doom I believe.

I don't actually remember this happening in the original .exe. But I might be wrong. And if it has something to do with complexity of levels it might just be that most doom2.exe compatable levels aren't complex enough to cause it. That said, I think I remember testing this once in doom2.exe and zdoom. And I had monsters wake up in zdoom that didn't wake up in the original .exe

[myk]

I know what you're talking about: just do -warp 1 3 -skill 4 with ZDoom (we'll assume not the latest version) and a particular monster will wake up before you open the door out of the entry room; an Imp, if I remember correctly.

So you can rest assured it has or had nothing to do with map complexity... and, yeah, it does not affect Doom.

[Fredrik]

I'm pretty sure I've seen it happen in other ports than ZDoom though...

[sargebaldy]

Nanami said:

That bug has existed since the original Doom I believe.

no, it's because randy switched to hexen's method of activation, which is faster but not as efficient as doom's method of activation. he merely changed it back to doom's blockmap method for 53.cab.

[Fredrik]

sargebaldy said:

faster but not as efficient

Certainly as (if not more) efficient, but indeed so due to speed and not accuracy.

[Graf Zahl]

sargebaldy said:

no, it's because randy switched to hexen's method of activation, which is faster but not as efficient as doom's method of activation. he merely changed it back to doom's blockmap method for 53.cab.

Doom does't use the BSP for sight checking but the BSP. Hexen uses the blockmap. The cause of these problems is most likely an incorrect blockmap. Now that someone gave information about a level where I can test this I'll try to find out what exactly causes this behavior.

[Graf Zahl]

Heh, I did a little debugging and found that the blockmap traverse function contains a nasty bug when crossing a block diagonally so that the next block would be offset in both x and y direction. Apparently id hat this problem themselves and 'fixed' it by limiting the function to maximally iterate 64 blocks instead of doing it right. No need to mention that this can cause odd situations in totally different parts of the code that also use the blockmap...

The thing is this occurence is so rare that it won't probably show up anywhere else but in Raven's sight checking code (which, btw, is significantly more efficient than the one used in Doom.)

I'm wondering whether Raven changed the sight checking code to make it more efficient or id changed it in later versions of Doom because they were too stupid to fix a simple bug...

[cycloid]

yer, well i said in my first post that i was using the deaf flag and 3 sound blocking lines. it's possible i'd have fired at the door itself (in the architrave sector), reducing it to 2 block lines. but the doors are lowering walls... which means the sidedef that was shot was a sound blocking one meaning it probably filled both sectors each side of it with sound including the door thus leaving only one sound blocking line for it to traverse.

i'll try adding another sector in then, heh