I think it has to do with the movement type of the entity you're trying to interpolate.
The interpolation code for the players works very well because every client has a lot of information regarding another player regarding the player's position, speed and button presses. Plus, the way the player moves is fairly simple compared to that of a vphysics object (which takes into account a lot of factors to compute the next position). In order to properly interpolate a server side vphysics object, you need to know the vphysics object's position,speed, friction, angular velocity, etc... Matt Hoffman wrote: > I know little about networking and interpolation, but why can't the vehicles > be set up like a client? Clients only appear jerky in high ping (150+) > situations. -- Theoretically you could stop interpolating the player entity > in the vehicle (movement wise) and do the vehicle instead. > > I think. :p > > On Sat, Jan 23, 2010 at 5:44 PM, Minh <[email protected]> wrote: > > >> Yea, that's definitely an issue.. but if the server did some checks on >> his end, the server can see if the updates were "valid" or not and >> basically just ignore the invalid updates or do something accordingly. >> Like if the client sent an update that he was at position X, and then >> half a second later, he is at position Y (which is like halfway across >> the map), that could raise a red flag. >> >> Client side physics objects are interpolated.. other players are >> interpolated.. >> are you sure server side physics objects are interpolated? God, I gotta >> go install hl2dm and play with the gravity gun... >> >> Saul Rennison wrote: >> >>> All objects are interpolated I think... the problem is the client >>> could send bogus origins and result in hacking. Never trust the >>> client! >>> >>> On Sunday, January 24, 2010, Minh <[email protected]> wrote: >>> >>> >>>> We actually managed to do a vehicle implementation that made the >>>> controls strictly client authorative. Basically, the driver of the >>>> vehicle gets his own vphysics object created and he controls it on his >>>> client machine, and passes the origin and angles to the server. >>>> The server then passes that info to the rest of the clients. >>>> >>>> The result is perfectly lag free controls for the driver. The only >>>> hitch is, since the client is the one actually moving the vehicle, >>>> vehicle collisions become a problem. In our first implementation, when a >>>> vehicle ran into another vehicle, it would stop dead in its tracks. >>>> There was no collision forces being imparted on either vehicle. We >>>> managed to come up with a hacky method to fix this but it didn't result >>>> in the most realistic collisions. >>>> >>>> Another problem we encountered was that there was no interpolation >>>> going on for the other players, so when they saw the vehicle moving, it >>>> wasn't smooth. I'm not sure if this is a problem inherent in the Source >>>> SDK though. >>>> When you take a server side physics object, and throw it, do all the >>>> clients see it move in a smooth fashion? The object's position is >>>> getting sent to each client at about 10 updates/sec (in a best case >>>> scenario). There is no interpolation going on between each update, so >>>> the object would exhibit a slight jerkiness. Maybe we broke something in >>>> our code but I think this is something the SDK didn't do properly >>>> (interpolate server-side vphysics objects). >>>> I think I need to go play HL2DM and throw a toilet around... >>>> >>>> >>>> Matt Hoffman wrote: >>>> >>>> >>>>> I take it that it would be a lot of work and take a skilled programmer >>>>> >> to >> >>>>> re-write prediction for the vehicles to put more of it client-side? >>>>> >>>>> On Sat, Jan 23, 2010 at 2:33 PM, Christopher Harris >>>>> <[email protected]>wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Here is a page which has needed fixes: >>>>>> http://developer.valvesoftware.com/wiki/Multiplayer_Vehicle_Fixes >>>>>> >>>>>> It fixes vehicle view jitter, but there is no true prediction because >>>>>> >> the >> >>>>>> vehicle movement logic only occurs on the server. So in a high latency >>>>>> situation players will experience the vehicle taking some time to >>>>>> >> respond >> >>>>>> to >>>>>> input. >>>>>> >>>>>> Chris >>>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] >>>>>> [mailto:[email protected]] On Behalf Of Chief >>>>>> >> Whosm >> >>>>>> Sent: Saturday, January 23, 2010 5:04 PM >>>>>> To: [email protected] >>>>>> Subject: [hlcoders] Vehicle View Judder >>>>>> >>>>>> Hi, >>>>>> Whenever you use vehicles in hl2mp, the view in them is all out of >>>>>> synch, "ghosting/juddering" are the best terms I can think of. >>>>>> Now I originally wasn't going to ask this because in ShadowSource >>>>>> >> it >> >>>>>> wasn't *too* bad, it jumped around but it was *just* bearable. However >>>>>> todays test game had vehicles in, and while we have changed no code >>>>>> >> related >> >>>>>> to either views, cameras or vehicles - the view judder was awful. It >>>>>> >> was >> >>>>>> like the advisor barn scene where your screen is shaken everywhere, >>>>>> >> and it >> >>>>>> really was terrible to look at (and very hard to drive as you couldnt >>>>>> >> judge >> >>>>>> very easily which direction was forward). >>>>>> So I'm wondering if anyone knows how to sort this so the camera is >>>>>> properly locked and doesn't bounce around so much in vehicles. >>>>>> >>>>>> Thanks, >>>>>> Chief. >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>>> >>> >> _______________________________________________ >> 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 > > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
