Is there like an invisible wall in E1M6?

In the final large room just before the exit door, before hitting the switch to open up the exit areas, the openings in the room close, preventing you from leaving the room for 30 seconds. When this happens, I find like this invisible barrier that I keep running into near the southern entrance into the room, as if, an impassible line was there or something. I only come across this "barrier" when the doors are closed, by the way.

Has anybody else ever encountered this? I don't see any mapping errors that could cause this, what could possibly be the problem?

Damn - you're right!!! Never noticed that. The invisible bit of a barrier is there!

But I think I've found the cause. This unclosed sector, creating a HOM and a slime trail. (taken in ZDoom)
Still I don't comprehend how it can make an "anomaly" like it does.

The invisible barrier is just in front of me, a little on the left.

Fascinating discovery

Huh, never have noticed this before, but I've never left the switch alcove during this part of the level either during the fighting.

Clonehunter said:

Huh, never have noticed this before, but I've never left the switch alcove during this part of the level either during the fighting.

Hehe, me too (at least "almost never"). I bet it's true for many people, since it's simply the one safe way to survive.

Woah. Nice find!

What Doom version is it? I don't see this. I'm running The Ultimate Doom on the latest GZDoom SVN build. All I did was to walk up to the switch that opens the exit hallway without activating it. In the process, two linedefs I purposely walked closed the room entrance doors and opened the monster trap ones. I stood on the same position, facing the same direction that scifista42 did in his screenshot.

What did I do wrong?

Hectic said:

What Doom version is it? I don't see this. I'm running The Ultimate Doom on the latest GZDoom SVN build. All I did was to walk up to the switch that opens the exit hallway without activating it. In the process, two linedefs I purposely walked closed the room entrance doors and opened the monster trap ones. I stood on the same position, facing the same direction that scifista42 did in his screenshot.

What did I do wrong?

Might be that you're using ZDoom, which possibly fixes things like this. Try something like Chocolate Doom.

EDIT: Hm, I did reproduce this in ZDoom. It's not directly right in front of the door, it's a little bit out from it.

Clonehunter said:

Huh, never have noticed this before, but I've never left the switch alcove during this part of the level either during the fighting.

This.

I wonder how many pieces of trivia are still undiscovered in Doom levels. Kudos to OP for the find!

Hm, I don't see any closed sectors or anything in this part. In fact, I ran an error check in Doom Builder and no closed sectors were found (just stick things, like those Demons).

Could it possibly be the Node builder or something just having a hiccup on that part of the map?

peach freak said:

Could it possibly be the Node builder or something just having a hiccup on that part of the map?

Quite possible, since ZDoom rebuilds the nodes of every map it loads everytime, so this particular "trivia" might actually not be there at all, but be an artifact of node (re)building. After all, ZDoom's goal is not 100% vanilla compatibility.

peach freak said:

Hm, I don't see any closed sectors or anything in this part. In fact, I ran an error check in Doom Builder and no closed sectors were found (just stick things, like those Demons).

I see. I've even manually checked all nearby linedefs for anything suspisious (wrong flag, sector number), but didn't find anything like an unclosed sector or other flaw.

peach freak said:

Could it possibly be the Node builder or something just having a hiccup on that part of the map?

Sounds possible (the node builder), I'd guess so. I'm interested what the truth is and if anyone can find it out and explain.

I've tried to mark an exact position of the barrier. Indeed it's there only when the Doors are closed. But it is there even in ZDoom and GZDoom. I've noticed something like a "tooth" at the northern part of the anomaly, see picture.

Maes said:

Quite possible, since ZDoom rebuilds the nodes of every map it loads everytime

No, it doesn't, unless you tell it to.

If gennodes is false, ZDoom will only build a map's nodes if they are missing or bogus. (It might build GL nodes, if they are missing and you use the textured automap feature.)

I don't see any unclosed sectors there, it's just a nodebuilder derp I think. Nothing very unusual: happens even with modern tools, see Da Werecat's Doom 1 map he posted some months ago.

That damn invisible wall has gotten me killed before. This is in 1.9, right? If so, is it also in versions older than 1.666? I'm pretty sure when I played the map in my younger years, the glitch wasn't present back then. In this older version, the spectres were also not stuck in the walls, if I'm recalling correctly that is.

EDIT: Nope, I'm way off. Early as Shareware v0.99, the invisble wall is there, and the spectre is stuck in the exit room. Wonder how they missed these glitches after so many iterations? I guess they are quite minor though.

Yes this is a "sliver" in the BSP tree, a region of misclassified space created by bad seg splitting. idbsp was not flawless; the famous "slime trail" of E1M1 is another place that it fucked up, possibly a result of the same glitch.

That wall has caught me before multiple times in vanilla v1.9. Sometimes they end up in my maps which is annoying.

OK, now I have it. I tested it with the same things on no target mode. The invisible wall acts as a prop: it lets hitscan attacks go through it, but not projectiles. I shot a rocket and it exploded before it hit the wall the shotgunner usually stands at.

I'd like to add that it's very likely caused by the sharply angled wall just outside in the hallway. I bet if that had been a 90 degree corner, that glitch wouldn't exist.

I will further add that the BSP is not used for collision checking, that is done using the blockmap.

So Quasar's explanation of a BSP "sliver" didn't make sense at first, until I realized that the BSP tree is used for figuring out what sector an object is in (after it has moved), and in this case it must be picking up the sector of the closed door.

andrewj said:

So Quasar's explanation of a BSP "sliver" didn't make sense at first, until I realized that the BSP tree is used for figuring out what sector an object is in (after it has moved), and in this case it must be picking up the sector of the closed door.

That would also explain why I encountered pwads where moving sectors were stuck along with some monsters which clearly weren't in a critical range. Somehow, this glitch must have assigned the monster to the sector which was supposed to move. I posted one such case some time ago, but don't remember the name of the map. I was particularly confused as the text file said vanilla compatible, but it only worked in source ports with the stucked sector fix in place.

This glitch would also explain a bug in forgex.wad. In the computer room near the door where you enter it, there is one spot with an invisible hole where monsters (dead or alive) and also the player can fall into. Apparently, the engine mistakes that spot as part of a much lower sector.

Gez said:

(It might build GL nodes, if they are missing and you use the textured automap feature.)

But those GL nodes will only be used for rendering, not for position determination in the playsim. For that ZDoom will keep the originally loaded nodes around.