Talk:Monsters stuck in doortracks, walls or hanging off lifts


I'm not sure this description is right, or the article at least needs some deeper discussion. This is the comment on the bug from p_enemy.c in Boom:

     /* if the special is not a door that can be opened, return false
      * killough 8/9/98: this is what caused monsters to get stuck in
      * doortracks, because it thought that the monster freed itself
      * by opening a door, even if it was moving towards the doortrack,
      * and not the door itself.
      * killough 9/9/98: If a line blocking the monster is activated,
      * return true 90% of the time. If a line blocking the monster is
      * not activated, but some other line is, return false 90% of the
      * time. A bit of randomness is needed to ensure it's free from
      * lockups, but for most cases, it returns the correct result.
      * Do NOT simply return false 1/4th of the time (causes monsters to
      * back out when they shouldn't, and creates secondary stickiness).

Fraggle 23:57, 7 Jul 2005 (UTC)

I marked this article as a stub because it doesn't address the doortrack bit — I have seen that bug, and exploited it, many times while playing, but I have no idea how often it occurs or why.  Heck, I've even seen barons (COMPBAS2.WAD) and spiderdemons (1SQUARES.WAD) suddenly get stuck on perfectly ordinary walls; what's going on there, do you suppose?   Ryan W 05:49, 28 Sep 2005 (UTC)

Well I think it's safe to say that our last contributor has rather improved the article... -- Jdowland 14:29, 30 Sep 2005 (UTC)
Quite.  :>   But the second phenomenon I describe above has still not been addressed or even mentioned (in this article or elsewhere).  I could easily make a demo of it on 1SQUARES.WAD, if anyone would like one.     Ryan W 22:56, 18 January 2006 (UTC)

What don't you understand? :) The monster moves towards a door track to follow an enemy. The doortrack stops his motion. He decides what to do next. In original Doom, he would look at the sector he was in, and if it was considered an unkeyed "door", he would try to open that door. Since a doortrack does not become passable when a door opens, he remains stuck there, because his assumption that opening the door would free him is false. He doesn't even try to move around. He single-mindedly keeps trying to walk into the door track and opening the door, which is already open. Is that hard to understand? The easiest exploitation of it is the Baron on E2M4's blue room with the lift up to the Cacodemon crusher area. You open the door, and then move so that the door's track is between the Baron and you. He tries to move towards you and hits the doortrack. He remains frozen there because he assumes that opening the door is the way to free himself, while simply turning around 30 degrees might be all he needs to do. As long as you are on the opposite side of the plane of the doortrack as him, you can shoot him with impunity.

Being "stuck on ordinary walls", if you mean not being able to walk around them intelligently, is a phenomenon not unique to Doom. It's caused when the AI logic causes the monster to get stuck in a "local minimum". If the monster always moves in the direction of the shortest Euclidean path between itself and its target, it can get stuck hovering around a wall. But we don't normally think of that as being "stuck". Here's a list of pages on pathfinding AI, which addresses this and related issues: Unfortunately, I never had the time to improve the pathfinding in Boom/MBF. I wanted to, but there were so many other concerns.

And as the article says, there are other causes of monsters getting stuck, such as if the the monster gets trapped on the other side of a wall, such as if a lost soul flew one pixel too many. Or take the Sergeant on E1M6 for example -- a ghost out in null space. A low ceiling may also cause monsters to appear stuck.

I can't help you with the demo since I don't run Doom anymore, but if you give me a step by step decription of what happens, I might be able to explain it.

--Leekillough 15:09, 2 March 2006 (UTC)

SPSQUARE.WAD: how to paralyze a spider by making it butt its head against the wall.
Sorry this took so long (graduate school, fneh).
I made a level based on 1SQUARES.WAD, which basically just contains me, one ammo dump, and one spider (see map at right).  The spider is in a large courtyard with an enclosed central room, and I run around the edge through some smaller square rooms.
I start at point A.  I pick up the weapons and items, then briefly open the door at point B to wake up the spider (triangle).  I then run to point C.  The spider, chasing me, gets stuck against the wall at point D.
If I walk a short distance eastward, away from the door, the spider's shortest path to me is away from the wall and it can suddenly move again.  I can then return to point C, and the spider is stuck again, a little closer to me.
What's interesting is, when I shoot the spider with the chaingun the first time, the impact pulls her toward me, so that by the time I disengage (and run around the west side of the map to attack from the south), she is far enough around the northeast corner of the box to shoot at me, which she wasn't before.  My first thought was that this was related to wallrunning, but it is equally trivial to get the spider stuck on any of the four walls.  Spider paralysis also describes a spider overlapping with an object, but the wall isn't moving as another monster would be (also, I have done this with barons, which would violate the "64 unit" criterion).
So I still don't know what's going on, but it smells a lot more like roundoff error than a simple AI "attractor".
For those who wish to follow along at home, get the map (file info) and the demo (file info).
Ryan W 16:56, 19 September 2006 (UTC)