You might want to write some debug messages for the console with time stamps so you can see when the client and server are getting velocities assigned, but directly setting the client side velocity is a really bad idea. I agree with Jorge that you should be adding your velocity changes directly to the shared game movement code. You really need to make sure, and this is really important for prediction, that the client and server velocity changes are being made in sync with eachother. When the server update hits the client and the client is outside of the movement range for that frame, it will snap the client back into server sync no matter what.
On Sun, Jan 18, 2009 at 9:20 AM, Michael Chang <[email protected]>wrote: > Hi Jorge > Thanks for the tip on net_fakelag. That's disconcerting I've been testing > with "600 ping" all this time... >_< > > ~M > > > > > > > net_fakelag 200 is 400 ping, I can't expect any game to be playable under > > those circumstances. Even ordinary walking gets laggy in those > > circumstances. I never go above 100. > > > > Either way I don't know the answer to your problem. I would suggest > trying > > to avoid using SetAbsVelocity() and using shared game movement code and > > fullbody animations instead, if you can. > > > > -- > > Jorge "Vino" Rodriguez > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ~Ryan _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
