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: [email protected] 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: [email protected] > 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 > > -- 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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
