Two possible solutions:
1. The client should be correctly predicting these values, so that when
the update from the server arrives it's more-or-less the same value.
Skips/jerks will only happen when the client mis-predicts. Unfortunately
the prediction code can be a bit tricky to get your head around...
2. There's a function "UseClientSideAnimation". If you call this on the
server copy of your entity, and include these lines in the server
netclass table
SendPropExclude( "DT_ServerAnimationData" , "m_flCycle" ),
SendPropExclude( "DT_AnimTimeMustBeFirst" , "m_flAnimTime" ),
Then the cycle & anim time won't be transmitted across the network.
You'll have to manually set the variables on the client instead using
SetCycle, SetSequence and so forth, e.g.
SetSequence( LookupSequence("anim_idle") );
SetCycle( GetCycle() + 0.1f );
Hope that helps. Good luck !
Alex
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
NuclearFriend
Sent: 09 May 2006 05:44
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Viewmodel skipping animation saga - continued
--
[ Picked text/plain from multipart/alternative ]
On 1/16/06, Matthew Lewis <[EMAIL PROTECTED]> wrote:
>
> This is a very old problem -- One to which no solution has yet been
> found. The problem is with the viewmodel skipping and jerking in its
> animation playback. I traced the problem to the server and client
> fighting over m_flCycle, m_nSequence, m_flAnimTime, m_flPlaybackRate
> networked variables. In particular, the client sets these variables
and
> then a short time later (lag time) the server also sets these
variables
> since they are networked. The result is an animation skip/jerk.
>
> The obvious fix is to block the server from changing the value of
these
> variables and let the client do the viewmodel animation independantly
> from the server. However, this is proving exceedingly difficult to do.
I
> changed the viewmodel class's send table as follows:
>
> IMPLEMENT_SERVERCLASS_ST_NOBASE(CBaseViewModel, DT_BaseViewModel)
> SendPropModelIndex(SENDINFO(m_nModelIndex)),
> SendPropInt (SENDINFO(m_nBody), 8),
> SendPropInt (SENDINFO(m_nSkin), 10),
> // SendPropInt (SENDINFO(m_nSequence), 8, SPROP_UNSIGNED),
> SendPropInt (SENDINFO(m_nViewModelIndex), VIEWMODEL_INDEX_BITS,
> SPROP_UNSIGNED),
> // SendPropFloat (SENDINFO(m_flPlaybackRate), 8, SPROP_ROUNDUP, -4.0,
> 12.0f),
> SendPropInt (SENDINFO(m_fEffects), 10, SPROP_UNSIGNED),
> // SendPropInt (SENDINFO(m_nAnimationParity), 3, SPROP_UNSIGNED ),
> SendPropEHandle (SENDINFO(m_hWeapon)),
> SendPropEHandle (SENDINFO(m_hOwner)),
>
> // SendPropInt( SENDINFO( m_nNewSequenceParity ), EF_PARITY_BITS,
> SPROP_UNSIGNED ),
> SendPropInt( SENDINFO( m_nResetEventsParity ), EF_PARITY_BITS,
> SPROP_UNSIGNED ),
> SendPropInt( SENDINFO( m_nMuzzleFlashParity ), EF_MUZZLEFLASH_BITS,
> SPROP_UNSIGNED ),
> END_SEND_TABLE()
>
> As I understand the SDK docs, the ST_NOBASE should prevent the base
> class variables (namely m_flCycle, m_flSequence, etc. from
> CBaseAnimating) from being sent to the client. However, what I'm
finding
> is that they are still get transmitted. I also tried
|SendPropExclude(...)
> on the variables, but they are still getting sent to the viewmodel.
The
> only way I found to stop the server from screwing with the viewmodel
was
> to go into the CBaseAnimating class and strip m_flCycle, m_nSequence,
> etc. completely from the network variables list and remove the
> prediction completely. Arrgh.
>
> There has to be something that I'm missing, or something that isn't
> working as advertised. Any Ideas?
> |
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
My mod is also suffering from this problem. I e-mailed Matthew directly
to
ask if he had gotten anywhere with this and his reply basically said he
could not fix this short of starting his mod again from a Half-Life 2 MP
modification (which does not have this problem). Yet he could find no
significant difference between them that could be related to this. The
only
thing he could suggest is something that is triggering different code
within
the engine.
He still suffers from this and so do I. The only solution I can see is
merging my mods code with the HL2DM source and that is a monumental task
from my view that is essentially fixing an error that Valve made with
the
original source release (the "Start your mod from scratch", which is
still
available and I would not recommend be used by anyone now, but which was
the
only option available to me at the time). So is it possible to get any
helpful input here?
--
Programmer for RnL
www.resistanceandliberation.com
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
__________________________________________________________________________________________________________________________________________
Information contained in this e-mail is intended for the use of the addressee
only, and is confidential and may be the subject of Legal Professional
Privilege. Any dissemination, distribution, copying or use of this
communication without prior permission of the addressee is strictly
prohibited.The views of the author may not necessarily constitute the views of
Kuju Entertainment Ltd. Nothing in this email shall bind Kuju Entertainment Ltd
in any contract or obligation.
The contents of an attachment to this e-mail may contain software viruses which
could damage your own computer system. While Kuju Entertainment has taken every
reasonable precaution to minimise this risk, we cannot accept liability for any
damage which you sustain as a result of software viruses. You should carry out
your own virus checks before opening the attachment.
__________________________________________________________________________________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
_________________________________________________________________________________________________________________________________________
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
