Ronald wrote:
> Nothing is being clobbered..
>The code is never compiled ;)
>
>#if 0
>Nothing is compiled in here.....
>#endif
I realize that is not getting compiled, that is what worries me, because
what is getting compiled is;
#if 0
//..
#else
m_iClip += 10;
#endif
Which is adding 10 to m_iClip for a reload. This is not correct, I just
want to know if it is a hack and m_iClip gets restored to it's correct
value later in the sequence.
Rob Prouse
At 07:39 PM 14/11/2001 -0500, you wrote:
>I've been having problems with the value of m_iClip being incorrect on the
>client side since the port to 2.2. I noticed the following code in the
>client CBasePlayerWeapon that looks like a problem. Is this the case or
>is it compensated for elsewhere? If it is dealt with elsewhere, then where?
>
>void CBasePlayerWeapon::ItemPostFrame( void )
>{
> if ((m_fInReload) && (m_pPlayer->m_flNextAttack <= 0.0))
> {
>#if 0 // FIXME, need ammo on client to make this work right
> // complete the reload.
> int j = min( iMaxClip() - m_iClip,
> m_pPlayer->m_rgAmmo[m_iPrimaryAmmoType]);
>
> // Add them to the clip
> m_iClip += j;
> m_pPlayer->m_rgAmmo[m_iPrimaryAmmoType] -= j;
>#else
> m_iClip += 10;
>#endif
> m_fInReload = FALSE;
> }
> // ...
>}
>
>It looks to me that the clip is passed to the client in
>HUD_WeaponsPostThink(), with pCurrent->m_iClip = pfrom->m_iClip. Why is
>the above code clobbering the correct value of m_iClip with an arbitrary
>amount? Is m_iClip just increased temporarily so we can get on with
>things until it is set to the correct value the next time the server
>updates the client? Am I just confused by the sequence and a hack to get
>things working?
>
>Rob 'Commando' Prouse
>Tour of Duty Mod
>http://www.tourofdutymod.com
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
