Duplicate Animation Events Fix

From Valve Developer Community
Jump to: navigation, search
Русский

Introduction

This is neither a prediction issue NOR a duplicated animation issue. It has to do with the introduction of the new PlayerAnimState code in the 15 June 2009 Orange Box SDK release.

The introduction of the PlayerAnimState brings great changes to controlling the animations on the player. The problem is it was thrown into an already messy animation code that involves literally hundreds of calls to functions in various levels of virtualization...

Regardless, at the end of the CHL2MPPlayerAnimState::DoAnimationEvent(...) function there is a little present from Valve. That is to do the View Model animation that corresponds to the third person anim! However, the problem lies in the way Valve detects network variable changes, those pesky "Parity" variables you might see around, specifically m_nResetEventsParity.

Let's backtrack a little, all weapons call their own viewmodel animations with a function called SendWeaponAnim(...) which does exactly that and also increments the m_nResetEventsParity.

Now the animation doesn't play twice because most weapon calls are in the same frame and it doesn't send the m_nNewSequenceParity since the sequence doesn't change. However, m_nResetEventsParity does get changed and it royally messes everything up. Since the PlayerAnimState stuff is only invoked client side it changes the event parity (sometimes) before the server update changes it, which is why this is an intermittent problem.

This code is actually used to call the animation events on the predicted viewmodels of OTHER players (so muzzle flashes and the like play properly in third person view). The problem is valve didn't filter it out for the local player which causes the doubling of animation events.

Requirements

  • Using the latest OB SDK code

Solution

Simply add a filter for the local player in the following code hl2mp_playeranimstate.cpp:

In function CHL2MPPlayerAnimState::DoAnimationEvent(...)

#ifdef CLIENT_DLL
	// Make the weapon play the animation as well
	if ( iGestureActivity != ACT_INVALID && GetBasePlayer() != C_BasePlayer::GetLocalPlayer() )  // <-- CHANGE HERE
	{
		CBaseCombatWeapon *pWeapon = GetHL2MPPlayer()->GetActiveWeapon();
		if ( pWeapon )
		{
			pWeapon->EnsureCorrectRenderingModel();
			pWeapon->SendWeaponAnim( iGestureActivity );
			// Force animation events!
			pWeapon->ResetEventsParity();		// reset event parity so the animation events will occur on the weapon. 
			pWeapon->DoAnimationEvents( pWeapon->GetModelPtr() );
		}
	}
#endif

Notes and Future Work

Future version of the SDK might fix this problem the other way, and that is to rely on this player animation code to setup the viewmodel animations instead of the weapon handling it's own animations in the specific parts of the code (PrimaryAttack, Draw, Holster, etc.)

This change is already present in the code generated using the "Start a Multiplayer mod from a template" option in the Create a Mod Wizard.