Re: [hlcoders] Viewmodel skipping animation saga - continued
-- [ Picked text/plain from multipart/alternative ] I've actually put this on the backburner for now, as I think it may have something to do with the weapons code instead, which was written by someone else and is due to be rewritten. Thanks for all the assistance though, I'll let you know how it comes along. :) On 5/24/06, Yahn Bernier <[EMAIL PROTECTED]> wrote: > > Have you tried putting a memory breakpoing on the address of the > viewmodels m_flCycle variable? > > You need to figure out what piece of code is changing the value, e.g., > is it the networking system, the prediction system, or some other code. > > Yahn > > -- Programmer for Resistance and Liberation www.resistanceandliberation.com -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Viewmodel skipping animation saga - continued
Have you tried putting a memory breakpoing on the address of the
viewmodels m_flCycle variable?
You need to figure out what piece of code is changing the value, e.g.,
is it the networking system, the prediction system, or some other code.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Murphy
Sent: Friday, May 12, 2006 2:23 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Viewmodel skipping animation saga - continued
--
[ Picked text/plain from multipart/alternative ]
Well I tried to remove the network sending on both AnimTime and Cycle
(Matthew said he already tried this but I wanted to see for myself). I
also
modified CBaseViewModel::SendViewModelMatchingSequence to set
m_nSequence
(with SetSequence) and flCycle only on the client (to GetCycle() + 0.1f
)
but otherwise left the function unchanged as m_flAnimTime was already
being
set on the client. I also forced client side animation on for the server
and
client.
This resulted in animations barely beginning to be played before being
stopped and no changes to m_flCycle (using cl_pdump). Could this
possibly be
because m_nSequence is still being sent over to the client via the
network
table? I noticed that the Player stops this from beng sent but I don't
see
the point as it won't modify flCycle or flAnimTime.
Any thoughts?
On 5/12/06, Alex Thomson <[EMAIL PROTECTED]> wrote:
>
> 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_N
RE: [hlcoders] Viewmodel skipping animation saga - continued
Hi Jonathan,
You're right that it's OK for m_nSequence to be transmitted over the
network. It sounds as if the problem is with m_flCycle not being updated
correctly on the client.
SendViewModelMatchingSequence is only called when a new animation needs
to start playing. You'll need a new function (client-side), called every
frame, which increases the cycle for your animating entity every frame.
A "ClientThink" function is a good bet for this.
Note that SetCycle expects an input from 0 to 1, so if you're looping
the animation, it needs to reset m_flCycle to 0.0f once it goes past
1.0f.
HTH
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Murphy
Sent: 12 May 2006 22:23
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Viewmodel skipping animation saga - continued
--
[ Picked text/plain from multipart/alternative ]
Well I tried to remove the network sending on both AnimTime and Cycle
(Matthew said he already tried this but I wanted to see for myself). I
also
modified CBaseViewModel::SendViewModelMatchingSequence to set
m_nSequence
(with SetSequence) and flCycle only on the client (to GetCycle() + 0.1f
)
but otherwise left the function unchanged as m_flAnimTime was already
being
set on the client. I also forced client side animation on for the server
and
client.
This resulted in animations barely beginning to be played before being
stopped and no changes to m_flCycle (using cl_pdump). Could this
possibly be
because m_nSequence is still being sent over to the client via the
network
table? I noticed that the Player stops this from beng sent but I don't
see
the point as it won't modify flCycle or flAnimTime.
Any thoughts?
On 5/12/06, Alex Thomson <[EMAIL PROTECTED]> wrote:
>
> 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
Re: [hlcoders] Viewmodel skipping animation saga - continued
--
[ Picked text/plain from multipart/alternative ]
Well I tried to remove the network sending on both AnimTime and Cycle
(Matthew said he already tried this but I wanted to see for myself). I also
modified CBaseViewModel::SendViewModelMatchingSequence to set m_nSequence
(with SetSequence) and flCycle only on the client (to GetCycle() + 0.1f )
but otherwise left the function unchanged as m_flAnimTime was already being
set on the client. I also forced client side animation on for the server and
client.
This resulted in animations barely beginning to be played before being
stopped and no changes to m_flCycle (using cl_pdump). Could this possibly be
because m_nSequence is still being sent over to the client via the network
table? I noticed that the Player stops this from beng sent but I don't see
the point as it won't modify flCycle or flAnimTime.
Any thoughts?
On 5/12/06, Alex Thomson <[EMAIL PROTECTED]> wrote:
>
> 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 CBaseAnimatin
RE: [hlcoders] Viewmodel skipping animation saga - continued
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 t
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
[hlcoders] Viewmodel skipping animation saga - continued
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
