Weapon startup animation

Okay, so I looked into it for you. And it actually turned out to be quite simple. The weapon's ready animation starts with the windup animation (not calling A_WeaponReady, therefore not allowing to use the weapon yet) and follows with the normal weapon holding animation (calling A_WeaponReady, therefore allowing to use the weapon if you press fire button). At the end of the animation, there is a jump to where the normal weapon holding animation starts, as opposed to the usual jump to the very beginning of the ready animation - this causes the windup animation to be skipped in the main weapon holding loop. Similarly, (almost) all jumps from other states into the ready animation are offset to go straight to the normal weapon holding part of the ready animation, skipping the windup part too.

I was once trying to do a similar thing in vanilla DEHACKED and I learned that not calling A_WeaponReady right at the start of the weapon's ready animation caused problems. Apparently it doesn't cause problems in ZDoom.

The simplest way of doing this is to use the weapon's Ready state label ( which A_Raise jumps to when the weapon is finished raising ) to mark the state sequence used for the start up animation, then have another state label entirely for the weapon's actual idle sequence. Keep in mind that this method means that you'll need to make your Fire states and such Goto to that state label instead of Ready, but that's a fairly simple thing.

As a small detail to keep in mind, if the start up animation involves the weapon's appearance changing ( like, say, an energy weapon lighting up after being raised ) and there's no "deactivation" animation at the start of the Deselect state, then it's possible that only doing that method will cause an incongruity if the player switches to another weapon in the middle of raising the weapon with the start up animation. To avoid this, you can use a dummy inventory item or, if you're using ZScript, a player variable that keeps track if the start up animation has played, and jump to an alternative Deselect state sequence at the start of the normal one if it's present. Then you remove or wipe it at the start of every other weapon's Select state sequence.

I didn't look at any of the BD chainsaw code, but I'm sure that there's no basic syntax for this and that it's a complicated effect implemented by combining multiple features that weren't originally meant to achieve this. If you want to implement a similar effect, the best way is probably to "get inspired" directly by the code of an existing mod that already implemented it.

Any kind of syntax would do. As long as I can achieve it, or at least understand how I could achieve it. If anyone has any experimental ideas on how to achieve this effect, post them here too.

I really don't want to download Brutal Doom again just to have a look at the code. Not to mention that I hear the code is messy.

So something similar to this:

// I just wrote this up right now as an example. 
//May or may not work.
ACTOR NGun : Pistol REPLACES Pistol
States
{
Spawn:
   ARM1 A -1
   Stop
Select:
   PISG A 1 A_Raise
   Loop
Deselect:
   PISG A 1 A_Lower
   Loop
// the windup. Hopefully.
Ready:
   PISG ABC 2 
   Goto Final // goes to real Ready state
// the actual ready state
Final:
   PISG A 1 A_WeaponReady
   Loop
Fire:
   PISF AB 2 A_FirePistol
   PIS A 1 A_CheckReload
   PISG A 1 A_ReFire
   Goto Final // goes to real Ready state. Hopefully.

should do? I'll have to check it out later.

The code looks OK, aside from the missing letter in the sprite name on the line with A_CheckReload, and that a couple of lines are redundant: "Goto Final" doesn't need to be called after the Ready animation since the Final animation immediately follows the Ready animation, and A_CheckReload is unnecessary in the Fire animation since it's immediately followed by A_ReFire which checks ammo itself.

16 minutes ago, scifista42 said:

a couple of lines are redundant: "Goto Final" doesn't need to be called after the Ready animation since the Final animation immediately follows the Ready animation

Even though intentional fall-through works, I think it's a good practice to always tell the state where to go next even if you want it to just continue into the state below. I prefer to do this anyway, it makes more sense to me that way and is also less error prone since if you re-arrange states like I do (I'm OCD about having Spawn first, then Select, Deselect, Ready, Fire, Flash, etc. in that order) you won't end up with messed up code.

I prefer the Goto as a safety measure. Like I said, that code was an example.

Although I didn't know A_Refire also checks for ammo. The wiki didn't say anything about that. Thanks for the heads up.

I can see why it's not mentioned on the wiki - it's not immediately obvious from A_ReFire's source code. A_ReFire basically just checks if the player is holding the fire button, and if so, calls an internal function P_FireWeapon, which is supposed to reset the fire animation. However, an ammo check happens inside P_FireWeapon, and upon detecting that the player doesn't have enough ammo, it aborts the function before it does anything. If you look at the DECORATE codes of (not only) Doom's weapons, you can see that they call only A_ReFire (and not A_CheckReload) at the end of their fire animations as a standard practice.

Thanks, it worked! Now to implement it to the other weapons :D