Weird voodoo bug

[Gez]

This was posted in the Doom picture thread which is a bit a too obscure place for a bug report.

Six said:

Unusual cock up during play testing of my custom map in PrBoom+:

Weirdness

i really need fix that misaligned bookcase, which somehow i missed.

Oh! and also there's the problem with one experimental action event that caused me to lose all my weapons (including fist), developing a weird ammunition glitch, not being able to activate anything, and an imp forever imprinted on the left of the screen (it looks like a giant one there though heh).

Six said:

Sure thing

Here is a link to the demonstration wad hosted on Mediafire.

As a heads up, when you start the wad, the crushing ceiling at the beginning will reduce your health to 40% or lower, this is required for the glitch to work. Just run straight through it, you don't need to stop under it.

A voodoo doll is required for this to work, but basically what happens is that, if you've taken 60% (or higher) damage, when you activate a crushing ceiling that destroys a barrel, and the splash damage radius is close enough to almost kill you via voodoo, but 'pushes' the voodoo doll into an invulnerability and megasphere power-up almost simultaneously, it causes this unusual glitch in PrBoom+. Nothing unusual happens in Zdoom (which is my default source port), but as for others, i'm not sure, i haven't tried.

As a note, i'm using PrBoom+2.5.0.6, which is the newer release. I'm not sure how this takes effect in earlier versions. Also if the glitch doesn't work straight away, try it again.

Edit: Also you can activate things when the glitch takes effect i've found out.

In Eternity, this provokes a crash.

[Quasar]

Gez said:

This was posted in the Doom picture thread which is a bit a too obscure place for a bug report.

In Eternity, this provokes a crash.

I am going to go ahead and guess from that fantastic screenshot that this is an overflow stomping some portion of the player_t structure. However, through what mechanism I do not know, so it will be interesting to track this down in the debugger. Thanks.

[Quasar]

Posting a new reply to note that I have fixed this in r1054. Here's what was happening:

• player->health would hit 0, which caused A_WeaponReady to detect the player as being dead and start the weapon lowering by setting it to its lower state.
  
• Still in the same gametic, the voodoo doll would be pushed by the explosion into the powerups, giving the player 200 health.
  
• On the next gametic, cycling through the lower state again calls A_Lower another time, but it detects that the player is alive. It decides, incorrectly, that this weapon change must have originated from a player button press and that therefore player->pendingweapon is set to a valid index into weaponinfo[]. However it is not, it is set to wp_nochange, a special ordinal which is higher than NUMWEAPONS in value (10 to be exact, vs 9 weapons). It blindly assigns player->pendingweapon to player->readyweapon and calls P_BringUpWeapon.
  
• An illegal access occurs to weaponinfo[wp_nochange].upstate - depending almost entirely on the values that are in RAM here, something different will happen - a crash, or you end up using an imp as a weapon, etc.
  

This is an example of a precondition violation, caused only by there being more than one body for the same player, and the implicit assumption that weapon changes can only occur due to input if the player's health is currently positive.

I am calling this DOOM's equivalent of the Space Time Beam glitch from Super Metroid. The effects are nowhere near as spectacular, but it functions in a similar manner by using non-existent weapons :)

[Csonicgo]

Wooo! All taht stupid shit in the debugger pays off, eh? :3

[Gez]

Quasar said:

However it is not, it is set to wp_nochange, a special ordinal which is higher than NUMWEAPONS in value (10 to be exact, vs 9 weapons).

So that's why ZDoom does not get this bug. Among the other adjustments that have been done to support custom weapons, P_BringUpWeapon() aborts before changing the weapon in such case. (Also, PendingWeapon, ReadyWeapon and the likes are actually pointers to weapon objects, with WP_NOCHANGE being the invalid pointer ~NULL.)