Better client performance: prediction

Has anybody brought up the idea of Client Prediction lately? This would virtually eliminate most forms of lag (but not low client FPS).

I have noticed that there's a small amount of CSP going on, but it needs to be expanded to include attachments and seated objects.

If the client had a copy of the physics engine that handled anything the avatar was sitting on (perhaps via the "take controls" function) and anything the avatar was wearing, it would really improve the performance of any kind of vehicle. Combine that with selective pre-caching of textures and geometry, and you'd get a game where it's actually fun to drive and fly again.

does nobody like the idea of less lag?

I'm not really sure I understand what you're suggesting, but I do know this:

I've been fighting LL about lag for more than a year. Instead of improving, lag has gotten worse. And instead of reducing the things that cause lag, LL has brought in items such as floppy prims and lighting effects.

That says to me that despite their claims, LL as a company doesn't give a rat's hiney about lag or client experience. If they did care, they would not be adding things to the engine that are guaranteed to make a bad situation even worse.

That explains it.


First of all, it's important to understand that lag is NOT low FPS. That's just poor performance. LAG is the round trip delay between when you hit a button and something actually happens. Lag doesn't make your screen run at 10fps, but it does make it hard to drive a car or fly a plane.

CSP would fight that by making YOUR computer handle the physics and movement for your avatar and vehicles you're driving, rather than the server handling the physics. That's all.

Currently, when you are in a car, and you press the "right" button, that button press has to go all the way to the server, be integrated by the physics model, and then the changes to the world are sent back to you. That process takes anywhere from a quarter to half a second. By processing all that on your computer, the process would take less time than it takes your screen to re-draw.

In other words: no lag. Slow FPS? Probably, but that's not the same thing as lag.

There seems to already be some prediction, however with all the variables in SL I doubt more would really help. Too much prediction and it will feel like you have less control, not more.

I'm not certain how this helps? Wouldn't you just go careening off and the server have to reset your position anyway? Or do you mean having the server tell you how you're moving opposed to where you are? e.g instead of saying "You are now at 23,47,89" it would say "You are moving North at 10m/s" and only tells you something new if the forces involved change, or it things you're out of sync?

First off, the client wouldn't predict other people's movement, only your own. And the client informs the server of where you are, not the other way around. So there's no flying off the edge of the world of musy response, because your movement (and that of anything that's using your controls) is happening inside your pc.

In the current model, the server tells your client where you are. In my model, the client tells the server where the avatar is. The client would have to download the script in each attached object and anything you're sitting in for this to work. So in a way, your client is running a mini-version of SL. There's no getting out of sync, because the client is in control of your avatar's movements.

There IS a small possibility of abuse, since people could theoretically hack the protocol to go places they shouldn't (like through walls), but you can already go through walls with non-physical movers, so that's a moot point.

someone else mentioned roads and rails on another thread. If you designated certain prims as "road prims", then you could pre-fetch the data and cars could move pretty quickly before running out of prims (it's currently easy to move faster than the world can keep up with).

As far as I can tell SL alreddy tells the client how fast an object is moving and then updates it's position to keep it in sync. The "Rubber band" problem is a good example of why I think that.

Processing all the physics localy would be a problem since scipts can push things and then there are all the other items that can collide. The other problem is that a lot of times you are using a script to control how you fly.

As a test, Start flying fast and low and then unplug the Ethernet connecton and see how long you keep moving.

Moving through a wall isn't abuse. The protocol as it stands does not prevent you from moving anywhere in the world except for land you are banned from, or virtual space that doesn't exist (ie where there is no simulator running). Downloading other peoples scripts however _IS_ abuse and that's why you'll never see this happen.

Bumping is an issue, (I think of "pushing" as using the Push function, which actually has no physical interaction with the object being pushed. This wouldn't need to be predicted) but it's not insurmountable. Obviously, bumping in to static objects is a non-issue, so we're really just talking about objects that are also moving or have physics enabled.

The thing is, we already have to deal with lag when it comes to bumping, so it doesn't really matter whether it's the local workstation or the server that's figuring out the end results of the bump. It would take a slightly more creative algorithm to handle two user-handled objects bumping, but it's not an insurmountable problem.

As to downloading scripts: we're not talking about downloading scripts in any human readable form. I'm talking about giving the client access to the binary code of the script long enough to execute it. Yes, it's theoretically possible to pirate a script during that process, but that's a pretty complicated process that would take as much effort as simply reproducing the script from scratch. In this context I certainly wouldn't call that "abuse".

To be honest, I'm surprised that all the responses I've gotten have been negative. With all the complaining about vehicles being horribly slow, why don't people want an idea like this to succeed? Client side execution and prediction is the only way that vehicles will work in SL with any kind of decent performance. Another thread talks about cars and buggies in There, and about how much better they work. That's because the vehicle code runs in the client, and not on the server. It's the same way with every FPS out there: the client keeps its own house in order. That's the way it should be.

So how about some constructive ideas on how this could succeed?

Decompiling LSL is fairly trivial compared to most of the decompilers out there, but you don't need to get it in to a readable form for it to be useful. A client could grab binary scripts coming down the pipeline, and reupload them as his or her own asset. This would make objects in-world 100% reproducible by automation, from the prims to the textures to the sounds/animations/scripts. It would destroy the foundation of that speech Philip gave where he said the objects that will survive piracy are ones with unique scripts.

I think everyone here does want the client to run more efficiently, but with all respect I don't think this is the correct approach. Also, a large basis of the users would rather see LL work on fixing the new and outstanding bugs in the client before embarking on yet another crazy feature.

I don't really see CSP as a "crazy feature". Again, this is an integral part of every network-based game out there, including all of the FPS's.

I'm really confused by the fact that the same people who complain about their vehicles not working don't seem to care about client-side physics.