Talk:Arch-Vile gluing monsters together


A technical discussion of this issue may need to make a distinction between visible sprites and Thing radius (a subject which seems to be a bit beyond my grasp, although I did understand section 3H of the BFG FAQ).   Ryan W 04:30, 30 Sep 2005 (UTC)

When I wrote the first paragraph of this article, I was sure I'd seen this happen in real play.  I was sure.  Then I started looking for it on purpose to make a demo, and now I'm wondering if I imagined the whole thing... I can't even find a reference to it on the rest of the web.

Maybe it only works with ghost monsters, since they don't clip?

Can anybody here educate me?   :7

Ryan W 23:05, 11 Oct 2005 (UTC)

This article is wrong[edit]

This article is incorrect on several points. First, the idea that a creature doesn't become solid until the end of its resurrection frames is refuted by the fact that in the function A_VileChase, which starts the resurrection process, the corpse's flags are restored to their defaults from the monster's corresponding mobjinfo_t record. This is the line below reading corpsehit->flags = info->flags;. In addition to this, the function PIT_VileCheck makes sure that the monster fits. If anything is standing over it, the vile ignores the corpse for the time being.

In addition, the idea that the vile and the monster aren't touching is incorrect. PIT_VileCheck does a somewhat rough distance determination and if the monster is too far away, it is ignored.

I believe there is a reason for this misconception however. In MBF, Lee Killough made a change to P_CheckPosition's PIT_CheckThing callback which broke Nightmare respawning, Arch-vile resurrections, and any other checks involving non-solid objects, but only while in actual game play -- because of a demo_compatibility check around the bugged code in question, it did not affect demo compatibility and thus went unnoticed -- and was unwittingly adopted into many other source ports -- for a very long period of time. This can be dramatically demonstrated by playing the MBF demo level which contains two boss brains (one friendly, one evil) for an extended period of time. Groups of monsters will eventually become glued together near the spawn points.

Code from A_VileChase:

  if (!P_BlockThingsIterator(bx,by,PIT_VileCheck))
     // got one!
     temp = actor->target;
     actor->target = corpsehit;
     A_FaceTarget (actor);
     actor->target = temp;
     P_SetMobjState (actor, S_VILE_HEAL1);
     S_StartSound (corpsehit, sfx_slop);
     info = corpsehit->info;
     P_SetMobjState (corpsehit,info->raisestate);
     corpsehit->height <<= 2;
     corpsehit->flags = info->flags;
     corpsehit->health = info->spawnhealth;
     corpsehit->target = NULL;

Code from PIT_VileCheck:

   maxdist = thing->info->radius + mobjinfo[MT_VILE].radius;
   if ( abs(thing->x - viletryx) > maxdist 
        || abs(thing->y - viletryy) > maxdist )
      return true;		// not actually touching
   corpsehit = thing;
   corpsehit->momx = corpsehit->momy = 0;
   corpsehit->height <<= 2;
   check = P_CheckPosition (corpsehit, corpsehit->x, corpsehit->y);
   corpsehit->height >>= 2;

Lee Killough's bugged PIT_CheckThing change from MBF. This code is wrong because it assumes the non-solid object is moving and will no longer be blocked in the future. This is not the case when doing Nightmare respawns, Archvile resurrections, or other similar things:

 // killough 3/16/98: Allow non-solid moving objects to move through solid
 // ones, by allowing the moving thing (tmthing) to move if it's non-solid,
 // despite another solid thing being in the way.
 // killough 4/11/98: Treat no-clipping things as not blocking
 return !((thing->flags & MF_SOLID && !(thing->flags & MF_NOCLIP))
          && (tmthing->flags & MF_SOLID || demo_compatibility));

--Quasar 06:58, 7 June 2006 (UTC)

Possible merge[edit]

While I have no idea if this article is accurate or inaccurate if it was accurate I would consider it to be merged with Arch Vile in any glitch section.If this is inaccurate then I support it being deleted.Just suggestions. —The preceding unsigned comment was added by (talkcontribs) .

If Quasar's explanation above is correct, then I would propose merging the article into Arch-Vile (and MBF too, I guess, since we've established a precedent by adding a "Bugs" section to Doom95).    Ryan W 19:04, 11 November 2006 (UTC)


Edit-paste.svgThe content associated with this talk page was considered for deletion, and either was deleted, or was kept after a period of discussion. This page has been retained for historical reference regarding the deletion process, or in case of future restoration of any deleted content.
  • merge , for reasons stated in the section above. -- Jdowland 17:18, 18 November 2006 (UTC)
  • I guess you should delete it. (guest) —The preceding unsigned comment was added by (talkcontribs) .
  • Merge.    Ryan W 19:41, 25 November 2006 (UTC)     EDIT: Just to be clear, I advocate merging this into MBF, not into Arch-Vile, since it's port-specific.
  • Merge, under the assumption we're clear that this is an MBF bug and not a problem of the original engine ;) --Quasar 07:40, 3 December 2006 (UTC)

Arch-Viles can definitely create stuck monsters. I witnessed an Arch-Vile glue ITSELF to a Former Human Commando in Plutonia MAP01. After you exit the first area, there's a sniper post with the human. Later the wall behind him moves and an Arch-Vile is released. This one I witnessed resurrect the FHC I killed before and managed somehow to glue himself to the FHC.

Note this was in Doom Legacy 1.42. But it can still classify as a bug if it was in the released source code.

I'm against deleting the article. But it definitely needs cleaning up. g6672D 04:28, 18 January 2007 (UTC)

But it wasn't in the released source code — that's the whole point of Quasar's long explanation above.  Legacy includes some Boom source AFAICT, so if you saw this happen in Legacy, it was likely inherited from MBF.
By the way, G6672D, you can sign your posts on talk pages with ~~~~.    Ryan W 20:04, 17 January 2007 (UTC)

The great preponderance of technical evidence argues against a vanilla bug (as opposed to a bug in MBF and its descendants), and playtesting has failed to refute this conclusively.  The outcome therefore is merge.    Ryan W 14:04, 10 March 2007 (UTC)

Apparently I merged this into MBF#Bugs but not Arch-vile, so I never checked it off my list.  Looking at the former, I think I'll bag that since the phenomenon is more general than arch-viles, applying also to monsters respawning in those ports.    Ryan W 20:35, 16 March 2014 (UTC)

Change of opinion:[edit]

Haha. Didn't notice the earlier comments. I guess I should change my opinion on this...

If there's a bug list here that's for other Doom versions, then it should be part of that instead. If not, I'd be for a section dealing with code inconsistencies. Or otherwise, just delete it.

g6672D 16:50, 20 January 2007 (UTC)

Bugs specific to a port should be listed in the article about that port.  Most ports nowadays either are still active or their code has been subsumed into a more recent port, so the number of outstanding, confirmed bugs actually affecting gameplay at a given time should be low.    Ryan W 22:34, 10 January 2008 (UTC)

NM Hardness Level[edit]

Like with Arch-Viles, Playing on NM can also glue things together. I first found this out on Doom 2 MAP11, when a Cacodemon respawned inside me. so don't just think Arch-viles, and don't just think monsters. ---drake raider