Re: [hlcoders] Vehicles in HL2
-- [ 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
Re: [hlcoders] Vehicles in HL2
-- [ 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
Re: [hlcoders] Vehicles in HL2
-- [ Picked text/plain from multipart/alternative ] A real driving/racing mod would need to implement vehicle prediction. -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicles in HL2
-- [ 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. On 8/15/06, Aaron Schiff [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] A real driving/racing mod would need to implement vehicle prediction. -- ts2do -- ___ 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
Re: [hlcoders] Vehicles in HL2
-- [ 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
Re: [hlcoders] Vehicles in HL2
Paul Peloski wrote: 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. However, the remote client (the one who's observing the vehicle, not the one who's driving it) could see prediction problems if his latency to the server is high. Slow moving objects will have less prediction errors. Faster moving objects (or objects that make sudden direction changes) will have more prediction issues. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicles in HL2
-- [ Picked text/plain from multipart/alternative ] On 8/15/06, Jeffrey botman Broome [EMAIL PROTECTED] wrote: However, the remote client (the one who's observing the vehicle, not the one who's driving it) could see prediction problems if his latency to the server is high. You're mistaken, the only entities that are predicted are: the local player, his weapons and his viewmodel. If you do cl_predictionlist 1 you will see something to the effect of player viewmodel weapon_crowbar weapon_.. No matter how many other players are on the server, only one 'player' is predicted. Entities that are under the control of the the local players input are predicted, since they're the only things that the local client can be authoritative about. Other players in the game (or their vehicles) don't fit this description, the client would have no idea how to predict the movement of some random guy on the server. Remote players and other entities ARE interpolated and extrapolated, which are simply smoothing out position/animation values in between network data (otherwise, you would only see the player move/animate when you got new data, not every frame). But these entities are not predicted. What you see on the remote client is always a bit BEHIND the server because of the time it takes for the server to transmit the entities locations to you. HL2DM makes up for this with the lag compensation system which moves players back in time to match your shot with what you would have seen when you made the shot. I hope that clears up some confusion? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicles in HL2
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
Re: [hlcoders] Vehicles in HL2
We've got full vehicle prediction here. It just so happens that there's no ground to bump into in space ;-) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Vehicles in HL2
In player.cpp, look in the function GetInVehicle(...). There's a line that says AddEffects( EF_NODRAW ). This makes the player in the vehicle invisible. What I've done in my mod is have a script which states what positions of the vehicle show the passenger. The code checks if the position the player is getting into is visible, and then adds the EF_NODRAW effect if he's hidden. Otherwise, the effect is not added. Stephen Swires wrote: Hi, I barely post here though I've been a subscribed for a few months now. To cut down to the chase, I'm attempting to develop a mod which will solely focus on driving, since the Source engine does boast about its vehicle physics. Though to my dismay the current Source SDK wiki doesn't contain much code or documentation about vehicles except for an explaination of the IVehicle structure. One of my main queries is about other players being able to see you in the car. With the HL2:DM code it seems that the player just disappears and some unseen ghost is driving. Is there a work-around for this because it would be greatly appreciated. Also if someone writes more information on intergrating new vehicles into HL2 on the wiki that would be greatly appreciated too. Hopefully with any help given I should be able to make a great mod with unique gameplay. Thanks in advance, Stephen Swires. ___ 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
