[DECORATE] Accurate Strife weapons

[Kate]

Not really "code" per sé, but it has to do with modifying a base file, so I'm posting it here.

This decorate modification changes the Strife weapons to act like their vanilla counterparts: The assault rifle always fires in bursts of 9 when the key is held down before pausing (that's why the first three shots are always accurate - the assault rifle holds clips of 3 x 3), and the flamethrower's animation works via bursts of 5 between the A and B frames.

I used the behavior of Strife 1.2 for reference to make the decorate weapons follow suit.

[Graf Zahl]

Sorry, no.

Strife's weapons only work like this due to bugs in the event handling. This was reported long ago and dismissed - as it is now. The ZDoom state representation is the same as in the original and how it is supposed to work.

See here:

http://forum.zdoom.org/viewtopic.php?f= ... sault+gun+

[Kate]

and how it is supposed to work.

I'm sorry but I'm calling you on that. You don't have the original Strife source because it was lost, nor have I seen disassembly from you to solidly prove the behavior wasn't intentional. For what anyone currently knows, it could be intentional behavior that was added at the last minute and left untested, hence why it seems buggy.

Either way it changes the gameplay entirely, even if it is a bug. Wallrunning, anyone?

[Gez]

For what anyone currently knows, it could be intentional behavior that was added at the last minute and left untested, hence why it seems buggy.

Why would they add a feature that changes the behavior when you fire with the mouse rather than with the keyboard? Why? How could it possibly make sense?

Either way it changes the gameplay entirely, even if it is a bug. Wallrunning, anyone?

There are Doom mods out there that require wallrunning to be playable. There are no Strife mods out there that require mouse fire to behave differently from keyboard fire. There's a grand total of three Strife wads on /idgames and none of them require compatibility options to be playable on ZDoom.

[Graf Zahl]

Actually, one requires a small DECORATE patch because Kaiser exploited a hole in Strife's inventory code that's not present in ZDoom. As a result it's not possible to get a decent weapon to defeat the Inquisitor at the end.

Regardless, the weapons behaving like they did in Strife is most certainly not intentional as this is not the result of intentional coding in the weapon handling but caused by improper events being delivered to the engine. It only shows that back in the day the mouse was not really considered a gaming device so it apparently never was tested properly.

And if this was changed, what to tell the keyboarders? That they were wrong to play without this hiccup effect?
Sorry, in this case I choose the behavior that appears to be more sane and logical - and also matches the code.

[Kate]

Why would they add a feature that changes the behavior when you fire with the mouse rather than with the keyboard?

We've already established that one of these behaviors wasn't intentional, what which one was intended was never thoroughly investigated enough. It is just as likely that the testers didn't think to use both the mouse and only the keyboard, so they figured both were working properly and left it at that - and it got released that way.

Consider that the assault rifle is a clip weapon. It takes clips as ammunition. The flamerhthrower also works in this respect, because it literally is the parts from a crusader, and crusaders fire their flamethrowers in short bursts. But now, let's factor in demos and networking. Someone proposes they have weapons burst fire. It would take unnecessary extra code in the weapons to make the weapons work the same and retain that behavior across the network and during demo playback, and they decide the weapons have been finalized, there's no need to change them anymore. So Rogue does something evil and hackish instead: They change the event system to send occasional interrupts to make the weapons work the way they expected to so that they don't need to special case every weapon's code to add extra loops and checks. It works over network because the interrupts are sent over the network, and it gets stored in demos. Nobody has bothered to see if the keyboard was ever changed and it gets forgotten because they assume it uses the same events, even though it really doesn't.

Now here's the kicker. They patch the game several times..And the keyboard/mouse behavior is never fixed. You think they'd have found it for the 1.2 and 1.3 AND 1.31 patches. I tested with 1.3 and 1.31 as well. The behavior is still there.

There are Doom mods out there that require wallrunning to be playable.

Okay, bad example, but I have a better one: I don't see any maps that require the Silent BFG trick to be playable. It's purely preference, and this is also preference. Hmm. Don't you think some sort of compat preference would make sense here?

[Graf Zahl]

Now here's the kicker. They patch the game several times..And the keyboard/mouse behavior is never fixed. You think they'd have found it for the 1.2 and 1.3 AND 1.31 patches. I tested with 1.3 and 1.31 as well. The behavior is still there.

Doesn't matter. The wallrunning bug in Doom also never got fixed. But in this case when trying to deduce the correct behavior there's 2 things to consider:

1. How were the weapons coded?
2. Which was the more prominent input device during the time when Strife was made.

The answers:

1. Clearly the keyboard behavior
2. Again the keyboard.

Seems pretty clear to me what was intended. If you think this is wrong feel free to use your patch. Nobody is forcing you not to. But ZDoom will remain the way it is.

[Kate]

Bump. A very important one at that.

Turns out, while on a decompiling little excavation, Quasar and Kaiser stumbled upon a very unusual piece of code.

This little piece of code, like the little sizzle freezes that occur in Heretic when you're running through burning lava, despite looking like an error, is responsible for making the mouse intentionally interrupt firing every few frames. Take a look at this nice little piece of disassembly as proof:

Code: Select all

  if ( gamekeydown[key_fire] || *(_DWORD *)(off_8627C + 4 * joyb_fire) )
    *(_BYTE *)(v1 + 7) |= 1u;
  if ( *(_DWORD *)(off_86278 + 4 * mouseb_fire) )
  {
    if ( mouse_fire_countdown <= 0 )
      *(_BYTE *)(v1 + 7) |= 1u;
    else
      --mouse_fire_countdown;
  }

So no, I am not hallucinating, and this is not a bug. It's, albeit extremely strange, fully intentional behavior.

[Graf Zahl]

Without seeing that code in context it's of no consequence. I can't deduce any potential reason for this from a small code fragment alone. Fact is, this is only done for the mouse and not the keyboard and back when Strife was released the keyboard was still the main input device for controlling a game so for me its behavior has precedence.

Also, just the presence of some code does not make it intentional behavior. A bug can also be caused by forgetting some leftover code in there that behaves strange..

[Kate]

To see the full context I would talk to Quasar on Doomworld or something. He supplied me with the code segment which caught my interest.

However, if it were applied correctly, I.E. to everything and not just the mouse (maybe that was the screw-up?), It would make sense because it produces a burst-fire effect on the machine gun, giving the sense of a reload (and also improving the accuracy - even the person you buy your first mgun from tells you it's more accurate when burst firing), and the flamethrower's animation, only having the second frame on holding, rather than both, actually looks like it was designed around that sort of hack since when doing that, it produces an actual flickering/stuttering animation on the flame at random. I mean, it looks like a flamethrower, why wouldn't it animate like one?

Thinking about it, it's really kind of weird, and I really doubt that such a thing could have gone unnoticed at all.

[Graf Zahl]

If it were applied 'correctly'? Now we are getting into the second-guessing business again. It was never done unconditionally in Strife so applying it to all input is most definitely not correct.

This is just one major piece of Ugh...

[Quasar]

The code in question is from G_BuildTiccmd, where DOOM translates all key input into recordable/transmittable actions. The variable, which we named mouse_fire_countdown, is set to 5 in M_Responder whenever that function sees a mousebutton down event for the first mouse button.

From the fact that the variable is only asserted through M_Responder, I deduce that this may have been an attempt at a hack to make the mouse work better in the menus, and ended up affecting the gameplay. I would probably consider it a glitch, though since it does affect gameplay, it is, to the people who used/abused it, a critical one. This is now emulated properly in Choco Strife.

[Kate]

An interesting read. Suddenly it all comes together now. Thanks, Quas. Three stars to you.

I would probably consider it a glitch, though since it does affect gameplay, it is, to the people who used/abused it, a critical one.

Indeed. I wound up keeping my patch anyway with some minor adjustments because it just feels more pieced together to me.

The changes are I added a real reload to the assault rifle, and the flamethrower now flickers between the two frames during firing and overheats with a cool-down period if you use it for too long. It's fun to play with the weapons that way.

[Graf Zahl]

From the fact that the variable is only asserted through M_Responder, I deduce that this may have been an attempt at a hack to make the mouse work better in the menus, and ended up affecting the gameplay. I would probably consider it a glitch, though since it does affect gameplay, it is, to the people who used/abused it, a critical one. This is now emulated properly in Choco Strife.

This is precisely what I expected and pretty much on the same level as the Heretic glitch with damaging floors affecting the player's movement.

So the best solution for those who can't live without broken gameplay is to load a DECORATE patch upon zdoom.pk3's definitions. No need to hack this into the engine.

[Blzut3]

So the best solution for those who can't live without broken gameplay is to load a DECORATE patch upon zdoom.pk3's definitions. No need to hack this into the engine.

Although I do agree with you, I was just thinking, what about implementing the mouse behavior as an alt fire?