"Static Cannon" in Doom

[Linguica]

Well, sort of...

http://www.doomworld.com/linguica/hax/static.deh

Load in Chocolate Doom or PrBoom-plus, IDKFA yourself a BFG.

1) Stand still and try to fire it
2) Move around and fire it

It's more powerful the faster you are moving (to a point), but this is difficult to tell, really, since you get up to full speed so quickly.

[scifista42]

I figured that the value of player's speed is somehow being used as ammo. Only the last 3 digits display on the ammo counter. The maximum value is probably 1048576, which is 16 * 65536 (where 65536 = fixed point value equal to 1 map unit). I wonder why this number? Player's speed is higher than 16 map units per tic, or isn't it? Also, it doesn't increase any more if the player is straferunning in comparison with normal running.

EDIT: Well, it appears that player's normal running speed actually is 16 units per tic, but this still doesn't explain why straferunning isn't giving greater value.

[Quasar]

Please explain.

[Memfis]

Some fucked up overflow resulting in reading wrong part of memory? Reminds me of the -statcopy experiments.

[Quasar]

Memfis said:

Some fucked up overflow resulting in reading wrong part of memory? Reminds me of the -statcopy experiments.

Well if I'm forced to guess, it's abusing the lack of range checking on the ammo number to read part of the player_t structure. You should know that will be port-specific of course, which would be why he's saying it only works in two ports.

[Gez]

Reminds me of when the pistol had been changed into a visplane counter. I think it was entryway who made that patch.

[Tristan]

Gez said:

Reminds me of when the pistol had been changed into a visplane counter. I think it was entryway who made that patch.

I thought for a moment this could make for a half-decent puzzle WAD (find the visplane overflows!), then realised it's almost certainly impossible to actually set something like that up :(

[RestlessRodent]

Actually the BFG uses ammo from the player's bob.

(gdb) print players[0]->ammo[-32]
$5 = 272085
(gdb) print &players[0]->ammo[-32]
$6 = (int *) 0x1016f5f4
(gdb) print &players[0]->bob
$8 = (fixed_t *) 0x1016f5f4
(gdb) print players[0]->bob
$9 = 272085

Running at full speed of course gives you a really high bob count, which is enough "ammo" for his modified gun to kill a cyberdemon easily.

Would have to determine which value in the player_t struct is read (in Vanilla) for each ammo index that is underflowed or overflowed.

Also hypothetically with this, you can make a "Soul Cube". Use the player's level kill count as ammo so that the more they kill the more powerful their "soul cube" becomes (or they can just fire more shots with it). This will mess with 100% kill total however.

[Linguica]

GhostlyDeath is right. The player_t structure has a "bob" member for the player's weapon bob, which is effectively a rough counter of the player's overall momentum in any direction. I use a negative ammo type for the BFG to make the game peer into the player_t structure to find the ammo count for the BFG, move backwards, and end up landing on the bob value. Because the bob value is so large (it quickly gets up to its max of 1048576) I then change the "ammo per BFG shot" value to 65536, and I also change the lengths of the BFG firing frames to 0. The result is that when you fire the gun while moving, it fires (current bob / 65536) shots simultaneously, which means you can fire anywhere from 0 to 16 BFG shots (well, I changed them to arachnotron plasma) at once when you press the trigger.

Yes, this was inspired by entryway's visplane overflow detector hack, and also by Doom 4, obviously.

(somewhat surprisingly, it crashed the hell out of doom2.exe in DOSBox - my initial thought is that trying to use normal Dehacked to set the BFG to use 65536 cells probably doesn't work and the game is trying to shoot like a million BFG shots at once.)

[RestlessRodent]

Is there a memory map of how DOOM2.EXE lays out static variables and such in memory? This would be nice information for the Wiki.

[Linguica]

GhostlyDeath said:

Is there a memory map of how DOOM2.EXE lays out static variables and such in memory? This would be nice information for the Wiki.

Entryway probably made something like that when he was creating doom+, but I don't think he's ever shared it with anyone.

[IMX]

Ouch, my ears.

[Imback55]

This dehacked static cannon crashes ZDoom when I use it.

[Arctangent]

Imback55 said:

This dehacked static cannon crashes ZDoom when I use it.

Unsurprisingly, because ZDoom probably interprets the ammo count way differently and leads to the weapon having infinite ammo. Which, considering the Fire state is a 0-tic loop that relies on running out of ammo to break, leads to an obvious 0-tic infinite loop.

Though with actual Decorate usage it wouldn't be that difficult to replicate the general behavior, although it's impossible to draw on the play's bob speed in ZDoom and the exact behavior would probably be really hard to reproduce. Then again, the exact behavior isn't exactly clean, so if you actually wanted to use this weapon concept seriously then making use of the fact that ZDoom can properly execute it is a far better alternative.

[scifista42]

Arctangent said:

Though with actual Decorate usage it wouldn't be that difficult to replicate the general behavior, [...] making use of the fact that ZDoom can properly execute it is a far better alternative.

It's impossible to do with DECORATE / ZDoom. There is no way to define accessing arbitrary memory data in a way that the DECORATE parser would understand or accept as OK.

[Captain Ventris]

Not with just Decorate, no, but an ACS script tracking the player's velocity returning a value to the weapon's decorate code is definitely doable. So it would have the same effect, via a different method than accessing memory data. If that's what you meant, then I apologize.

[Arctangent]

scifista42 said:

It's impossible to do with DECORATE / ZDoom. There is no way to define accessing arbitrary memory data in a way that the DECORATE parser would understand or accept as OK.

I think you're completely underestimating what they can do, because ...

Captain Ventris said:

Not with just Decorate, no, but an ACS script tracking the player's velocity returning a value to the weapon's decorate code is definitely doable. So it would have the same effect, via a different method than accessing memory data. If that's what you meant, then I apologize.

You don't even need ACS. All the variables you'd need to modify a weapon's damage / number of projectiles fired based on the player's velocity are accessible directly through Decorate itself.

Sure, you wouldn't be basing it off of the player's bobspeed, but that's not the point of the concept; the entire reason bobspeed is chosen is because it acts as an appropriate stand-in and can be accessed via rollover. Since velocity on each axis is something readily accessible normally, there is no reason a more properly coded version of this can't be done.

[scifista42]

I didn't consider calculating the value (which cannot be accessed) from other values (which can be accessed), you're probably right then.