Reloading weapons take 1 extra tick to fire

[nolem]

aka 1 cool trick to instantly be a better jumper!!~

So I'm not 100% sure if this is already known information, but seeing as it was news to Shadow Sheep and a few others I'm guessing it might not be widely known among jumpers.

tl:dr - While reloading, all weapons take 1 extra tick to fire. This means that it's basically always better to turn cl_autoreload off and reload manually. On maps with sufficient regen, where there's no real need to reload at all, it's strictly worse to have cl_autoreload 1

Some more detail: Weapons take 2 ticks of +attack to go from the reload animation to actually firing. Since cl_autoreload 1 immediately makes you reload after you're done the fire animation, that means unless you hold mouse1 or have a tick perfect input (+attack on the exact tick the previous attack anim ended), your weapon will take 1 extra tick to fire vs if you weren't reloading. So for example, a soldier sitting with 4 clip can +attack for exactly 1 tick and fire a rocket, whereas a soldier reloading with 3 clip would have to +attack for 2 ticks to fire. This applies for the sticky launcher and shotgun as well - I haven't tested other weapons but I assume it's the same across the board.

Now I haven't done a deep dive in the codebase, so don't take this as fact, but my working understanding is:

After firing, the weapon animation is X ticks. After X ticks, you go to a sort of "neutral" state. With cl_autoreload 1, if you're in that neutral state and don't have a full clip, reloading will start. So that means with cl_autoreload 1 you get 1 tick of neutral, and if you're holding +attack during that tick, you will fire (or sticky launcher will start charging).

Now once you're in the reloading state, +attack doesn't fire immediately - it brings you back to that neutral state (which will go back to reloading immediately with cl_autoreload 1). So this means you need 1 tick of +attack to go back to neutral, and another tick to start firing from neutral.


Basically, what this means is that it's generally better to have cl_autoreload 0, and if you're on a map where you actually DO need to reload, it's better to have a reload bind vs letting the game handle it.


Here are some quick vids using the tick advance mode in the tas plugin to show off the behavior





Seems like a somewhat big deal to other aspects of the game too, but maybe this isn't really news? idk
[11:02 AM]botmode: it was a thing people talked about in like
[11:02 AM]botmode: 2011
[11:02 AM]botmode: about auto reload = bad

[ILDPRUT]

I came to know about it when pear asked me about why reloading affects walk bounce setups. We quickly came to the conclusion that it was because you wasted 1 tick on canceling the reload. The easiest way to test it yourself is by binding +attack to mwheeldown/up as mousewheel binds only send 1 tick inputs for normal commands (doesn't work for aliases for whatever reason). So if you're reloading and scroll you'll see that you just stop reloading without shooting at all.

The reason it happens is because of these lines in the code: game/shared/baseplayer_shared.cpp#L268-L288

Code: [Select]

    if ( gpGlobals->curtime < m_flNextAttack )
{
if ( GetActiveWeapon() )
{
GetActiveWeapon()->ItemBusyFrame();
}
}
else
{
if ( GetActiveWeapon() && (!IsInAVehicle() || UsingStandardWeaponsInVehicle()) )
{
#if defined( CLIENT_DLL )
// Not predicting this weapon
if ( GetActiveWeapon()->IsPredicted() )
#endif

{
GetActiveWeapon()->ItemPostFrame( );
}
}
}
While the weapon is doing something other than shooting, i.e. reloading, it will run "ItemBusyFrame". It is inside that function that reload canceling happens too. However because of the if/else statement, "ItemPostFrame", the function responsible for shooting, won't be called that tick. So you'll have to wait for the next tick where gpGlobals->curtime >= m_flNextAttack now because of the reload cancel.

I'm currently working on a plugin that aims to fix a bunch of small annoyances in jumping and this is one of them. The fix simply calls ItemPostFrame if gpGlobals->curtime >= m_flNextAttack after ItemBusyFrame has finished executing.

[Comma]

I suppose I discovered the effects of this in a visual way a few years ago with a mouse bind that essentially spam pressed m1 real fast (ie +attack would be held for only 1 tick).
This toggling causes the animations to repeatedly reset (as you'd expect) though not as fast as one might expect - this may just be due to an imperfect bind. From third person and player perspectives I'd say it looks weirder.

My original experience:


From a 3rd party perspective (with excessive editing):