-- [ 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
