-- [ Picked text/plain from multipart/alternative ] The same way it things work now. Clients extrapolate positions and velocities and stuff based on network updates from the authoritative system for the vehicles, which doesn't necessarily have to be the server, though it typically is for security and efficiency. When extrapolating physics objects you normally extrapolate velocities too, so that in between the network updates the physics system can handle some of the extrapolation based on what it recieves.
On 8/16/06, Robbie Groenewoudt <[EMAIL PROTECTED]> wrote: > > -- > [ Picked text/plain from multipart/alternative ] > How is full client-side vehicles possible with multiple players? How would > you make have the vehicle the same position on all clients? > > Also, about your problem: Can't you just set velocity/impulse to zero when > the network-info is received? (RecvProxy?) > > On 8/16/06, Justin Krenz <[EMAIL PROTECTED]> wrote: > > > > When I first started programming the vehicle code for Empires, I tried > > to implement vehicle prediction. This consisted of me copying the > > physics entity of the vehicle onto the client so that I could predict > > the physics portion of the vehicle on the client side for the predicted > > frame. Everything worked fine if you told the client to ignore updates > > from the server, ie, wholly client-side vehicles. With prediction, once > > the server sent an update and the physics object of the vehicle was > > correctly positioned to match the server copy, there was still energy in > > the physics object left over from the client-side predicted frame. As > > the player drove his vehicle, it would begin to climb up into the air > > as the game was essentially pulling it back to match the server while it > > still had energy that was trying to move it forward from the predicted > > frame. When it couldn't go forward, it went up a small amount and > > created an oscillating effect. I never found out how to completely > > erase the energy of the physics object it gained on the client frame and > > assumed it wasn't possible because there wasn't enough access to the > > internal variables of the physics object. I plan on going back and > > working on it, but I'm going to make it fully client-side instead as I > > believe it's easier to implement anti-cheat functionality rather than > > fix the physics issue. Plus, you get the benefit of saving server cpu > > time, and with prediction, you have to send more network info to > > describe the properties of the physics object to make an accurate > > prediction rather than just the origin and angles of the vehicle model. > > > > Paul Peloski wrote: > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > Err, prediction would definitely work for a driving mod, prediction > > works by > > > allowing the local players input to be considered authoritative by the > > > client side for a little while, until the server acknowledges (or > > denies) > > > the predicted movements by the client. > > > > > > In your example, if the driver stops his client would show the stop > > > immediately (by predicting it). After the server has acknowledged the > > stop > > > is in fact possible by sending the stopped location back to the > client, > > the > > > client will say "okay cool, I already knew that, thanks for > confirming." > > > Meanwhile the client has moved onto something else that the server > will > > > ackowledge later. This allows the client to run around as if hes > > > latency-free and only mucks up when the server denies something the > > client > > > thinks it can do (ie, prediction error.) > > > > > > If you don't predict, the game will feel very unresponsive, since your > > input > > > will have to be acknowledged by the server and sent back before you > see > > it > > > happen. The higher your ping, the worse the response time. It works > fine > > for > > > single player games but not for fast-paced multiplayer. > > > > > > On 8/15/06, Robbie Groenewoudt <[EMAIL PROTECTED]> wrote: > > >> -- > > >> [ Picked text/plain from multipart/alternative ] > > >> I was thinking though. You can't really predict any driver-input so > > when > > >> the > > >> driver has a higher ping ( like 200) and riding hard, prediction > > wouldn't > > >> really make it better. (for example, the driver stops but due ping > the > > >> command gets 200 ms later and the vehicle 'teleports' some units > back. > > >> > > >> > > > -- > > > > > > _______________________________________________ > > > 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
