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
