Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
ukiro

Linedef triggers partially break without -nomonsters

Recommended Posts

I've made a fairly elaborate puzzle/trap bonanza using lots of dummy sectors. I've built and tested this with -nomonsters like any sane person would. But when it was done and I tried with monsters, it partially breaks; around 30% of the tagged sectors do nothing. This is without any monsters in or even near any of these sectors. Going back to -nomonsters makes it work perfectly again.

Has anyone encountered something similar? How can the presence of monsters elsewhere in the map block some, but not all, sectors from moving?

Share this post


Link to post

Does the addition of monsters cause you to do things differently in-game?

Something else to consider, if you have a lot of lines all getting activated at the same time, it wouldn't be uncommon for one to fail to trip here and there, which after the snowball effect of chain-of-reaction -type triggers could make 30% of actions not work.

*edit*
Never mind, I missed the part about sector movement. Scifista is likely right on the money.

Share this post


Link to post

Yes, it's a known quirk of the Doom engine. If there are any stuck things within the area of the bounding box of the sector that's about to move, the sector will not move (at least under vanilla compatibility). Point is: If you join 2 sectors, they technically become one sector despite being physically disjoint, and this one sector's bounding box will be a rectangle containing both parts of the sector, spanning all areas in the map between those parts. This way, the bounding box can end up being really large and covering a large part of the map, and any stuck thing within this area will prevent the sector from moving.

Share this post


Link to post

No. The section I'm working on has no monsters at all yet, so I can run through it the exact same way with and without monsters. Their presence elsewhere in the map however makes this section behave differently. If they were somehow blocking floor/ceiling movement I'd understand, but they are truly nowhere near the entire section of the map nor the dummy sectors.

scifista42 said:

Yes, it's a known quirk of the Doom engine. If there are any stuck things within the area of the bounding box of the sector that's about to move, the sector will not move (at least under vanilla compatibility). Point is: If you join 2 sectors, they technically become one sector despite being physically disjoint, and this one sector's bounding box will be a rectangle containing both parts of the sector, spanning all areas in the map between those parts. This way, the bounding box can end up being really large and covering a large part of the map, and any stuck thing within this area will prevent the sector from moving.


Wow I did not know this, that's bizarre! How have I not encountered this in 22 years of DOOM?!

Moving the dummy sectors to reduce the size of the bounding box indeed fixes the problem. Big thanks!

Share this post


Link to post

This is a really useful behavioural quirk to know for WadC. I have a "control" library that draws control sectors out of the map area. If I were to extend it to dummy sectors too, I might have to consider this issue. Thanks!

Share this post


Link to post
ukiro said:

Wow I did not know this

When I said it's "a known quirk", I did NOT mean it like it's a widely-known quirk. :)

Share this post


Link to post
scifista42 said:

stuck things


What do you mean by "stuck"? Like in a wall? In another thing?

Share this post


Link to post

Actually, it means stuck between a floor and a ceiling. It happens when the difference between the lowest ceiling height and the highest floor height of sectors that overlap the thing's bounding box is smaller than the thing's own height. Example:



The thing (red) overlaps 2 different sectors (green, yellow). The lowest ceiling height of these sectors is 128 (one sector has ceiling height 128, the other one has 192, and 128 < 192). The highest floor height is 64. The difference between 128 and 64 is 64. The thing's height is 72 (unlike floor/ceiling heights, height in this context means the thing's size, not its Z position in the map). 64 < 72. Therefore, the engine will consider the thing being stuck, no matter its current Z position.

If the thing's height was lesser or equal than the difference between lowest ceiling and highest floor, it wouldn't be stuck - however, if the thing's current Z position was lower than the highest floor level overlapping the thing's bounding box, the thing would be instantly moved upwards to match the highest floor level - this is why things near walls (frequently item pickups) become "floating" in some Doom maps. Hanging corpses can also be affected by this by being instantly moved downwards if the lowest ceiling height they touch is lesser than their Z position.

If the thing protrudes through a 1-sided linedef, overlapping the "void" space of the map, the engine will consider in being in potentially any sector(s) that the respective part of the "void" neighbors with, depending on how the map's nodes are built - which may or may not result in the thing being stuck.

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
×