Predicted Vehicle Movement

We’ve been dying for this to be in Garry’s Mod for years, would it become a reality in S&Box?

2 Likes

It confuses me that things like stadia can take your input, send it to a server, process it, render a frame, send it back… within 20ms with no lag… but for some reason people think that they need predicted vehicle movement.

I mean, never say never - but I don’t see much of a point. It seems more important to make the vehicles feel good - then you won’t notice that they’re server auth.

7 Likes

how can driving a car feel good if it takes almost 1/3 second for the steering to respond? big servers cant run at a high tickrate and no network buffer, ping is also always an issue

1 Like

Let’s just remember that stadia’s run on a big tech company’s servers. Unlike gmod(2) servers. Which are mostly run by scammers with taiwanese proxies and kids out of their basements on their mum’s old laptop.
/s?

1 Like

If the server is struggling like this, it seems like it’d be better to make the vehicles client authoritive?

3 Likes

thats where prediction should take place. afaik no one achieved something like this yet in gmod/s1

1 Like

Or we can open the possibility for the server owner to decide what model they want to use. Unless it’s too much a hassle to code.

Edit: Let’s remember that all garry’s doing is providing tools for modders to make the most out of the engine. He must do whatever provides the most/best possiblities for development (and is future proof)

1 Like

Probably because the vehicles are physics based, and you can’t predict that because it’s not deterministic.

3 Likes

in case of custom vehicles wouldnt it be the problem of the vehicle creator how they work anyways?

1 Like

Any kind of improvement from this would be nice

2 Likes

Yes, it needs to be responsive, it would make such a great difference.

1 Like

personally no vehicle ever felt good with 25+ ms lag

only way to have non-shit predicted vehicles is: vehicles are physics based and physics are deterministic or vehicles are not physics based but run their own input to state stepping, the latter of which modders can easily do if given the tools (which im sure are already exposed in the API), so we’re okay in that regard. Garry can make this even easier by giving players predicted modules that can activate/deactivate when entering vehicles and all modders will need to do is fill in the state stepping function - where the meat of the simulation is

1 Like

I mean, never say never. It’s totally possible to make the player model a car and do predicted vehicle movement right now… but I’m guessing you’d want to control another entity. I can look at it at some point - because that’d kick ass… there’s just a lot of moving parts.

15 Likes

Yeah, predicted vehicles would be a god send - At the Garry’s Mod server that I am working with, we’re peaking ~90-100 players, past a certain point (way before 80 players), the steering takes almost a full second to actually take effect.

It confuses me that things like stadia can take your input, send it to a server, process it, render a frame, send it back… within 20ms with no lag… but for some reason people think that they need predicted vehicle movement.

I don’t want to seem rude, but it seems like you haven’t experienced what Garry’s Mod is like on those servers nowadays, perhaps visiting a full roleplay server or two would let you gain perspective on things, idk.
Sure, we have to run ridiculously low tick rate and that affects things, but that’s the only way we can sustain those player counts at the moment.

6 Likes

Making it convenient for developers to properly implement and manage if/how entities are predicted while having them respect player interaction/hierarchy would be great. New engine means a bigger and fancier toybox which means potentially way more lag. Open-ish world RP comes to mind.

Control over prediction is important because IMO vehicles in particular don’t need to be nearly as snappy/accurate as a regular player movement since you’re not shooting at anything. Instead of snapping backwards and jerking around it should be acceptable to at least lightly interpolate.

Of course, for some modes you might expect players to shoot from a moving car and so it would be good to control those bounds of approximation and smoothing.

Another example is that I’ve been playing Caves of Qud recently, and if I were inspired to allow you to “Dominate” any living creature(so that you become it while you lose control of your body but it’s still there) then without a convenient prediction implementation I’d have to do some considerably hacky shit that most devs wouldn’t ever want to.

Other examples:

  1. Picking things up in multiplayer VR.
  2. Picking simple props up with the Physgun.
  3. Rocket launcher with laser guided missiles.

TL;DR:
Please let clients be mostly solipsistic over anything important so that our monkey brains feel in control, or we will all be sad and feel the lag projecting from big daddy’s dimension.

3 Likes

Every game with a physics engine has problems with vehicles, especially planes, being in the wrong place or jerking on landing/collision. Everyone seems to be ok with it…

One way to do it is by sending keys to the server and run duplicate physics on both the client & server, then update the object locations every 3 seconds from the server. If you have a bad ping you will micro-teleport every 3 seconds but you can trust where you are. People with bad ping know what they signed up for…

3 Likes

how tf do you even feel 25ms difference? Like, there’s 1000ms in a second. That’s 0.025 of a second, I honestly don’t believe anyone can feel that. I use a stadia-like thing but better, called Shadow. Even with 30 to 40 ms input lag, I don’t feel a difference on anything than running it on my local PC. A bit off topic, but yeah

1 Like

Because it doesn’t just depend on the ping.

3 Likes

The input lag argument is a very complex one, but I’ll say at least that some people are very sensitive to even a difference of 25ms when things are constantly being updated.

60hz = 1/60 = 16.6ms
144hz = 1/144 = 6.9ms

Despite being a difference of roughly 10ms, the upgrade from a 60hz monitor to a 144hz can make an amazing difference with first person shooters at least. If you can’t tell the difference there is nothing wrong with that, but at least know that there are many of those who can, myself included.

Without prediction you have to wait for your client’s next cmd tick, wait for that cmd to be sent to the server, wait for the server’s next cmd tick, and then wait for the server to send the results back to you. So even with “good” ping anything unpredicted can feel really sloggy and just plain awful.

With prediction your client only needs to wait for the next cmd tick(or frame) to give you an exponentially faster response, and then listen for any corrections from the server in case there’s a conflict in the results.

Also, as @CupCakeR says, the server may not be sending/receiving updates faster than their framerate. This would cause entities to jerk around at a low framerate on your screen, unless you interpolate. This means that instead of stuttering from A to B, the client creates new points between A and B so the movement is smooth and matches your framerate.

An example of interpolation most people may be more familiar with is how old 24/30fps films can be digitally remastered to play at 60fps or more. For games this is extremely important for things to “feel right”, especially since your game is probably running at a much higher rate and the difference is made that much more obvious.

2 Likes

Stuff like that compounds, 33ms draw time + 25ms of lag + everything else and general instability can cause you to feel pretty bad in some instances.

1 Like