Client side llVehicle prediction
tracked
Extrude Ragu
If you push the forward key in an llVehicle, the signal gets sent to simulator, script does something, result of input comes back.
What I'm trying to say is vehicles in SL have latency that other multiplayer games don't.
If the client can be told basics about the llVehicle it could be making a good guess about what the vehicle should be doing before it gets a definitive answer from the simulator, thus making vehicles appear much snappier as the result of input would be instant client-side
Or perhaps even make it possible for a client side script to be authorative on an objects position and run the physics simulation client side, just sending results to simulator for other residents to see?
(I'm currently just throwing random ideas out there to see what sticks, sorry if my posts seem excessive)
Log In
Atomic Infinity
It's an interesting thing to review - helping the viewed 'accuracy' of the travel would improve some stuff.
But it would need some careful thought - in our racing community we might have 8 or more riders racing in close proximity to each other (within 10 metres), so any changes to what the server sees would also have to be passed very smartly to everyone else as we all need to see the same thing, at (hopefully) the same time.
SL Feedback
Hello, and thank you for your detailed feature request regarding client-side llVehicle prediction. This idea has been brought up in the past, and we recognize its potential to improve the responsiveness of vehicle controls in Second Life. We will set this issue to tracked. While we cannot provide an estimate on when it might be implemented, please keep an eye on future updates. Your input is valuable, and we appreciate your continued commitment to enhancing Second Life.
SL Feedback
tracked
Bleuhazenfurfle Resident
Oh, this is related to one of the things I mentioned in the other post(s): A client-side script can intercept vehicle controls (most likely at a much more reliable frame rate), do some likely real-time processing (where LSL is at best every couple frames even on fairly quiet regions), and pass that on to the LSL side pre-processed so it can just get to doing what it needs to do.
The client-side script being able to update the vehicle directly by itself is problematic, since the viewer would need to have a physics engine, have it take over from the sim, and will lag behind environment object updates (particularly relevant for collisions with other moving objects, like other vehicles) — but it
would
be the next step to much nicer vehicles. Pretty sure in many games, they run the physics on both ends, with the server able to "roll back", and generally override the viewer where necessary — which probably isn't really applicable to such a general purpose engine as SL.Extrude Ragu
A cars steering wheel would benefit from being client side is another example on the vehicle topic. Steering is always going to look snappier if it's done instantly client side. Imagine playing with your gamepad and how the wheel would react done via a traditional lsl script vs something client side.