NetCode for Entities Feedback

[NikiWalker]

Great feedback Jawsarn. I’ll speak to as much as I can today:

@Jawsarn

In my opinion it would be better if partial ticks would be opt in. Addition to this it would be great to add better support for interpolated prediction ticks by default, similar to SmoothRigidBodiesGraphicalMotion.

Yeah good points - we are actively looking into interpolation as a replacement/alternative for partial ticks, as part of broader Unified Netcode efforts.

@Jawsarn

Current Prediction Smoothing functionality is not great. Two years ago this was brought up in a forum post and CMarastoni said that you knew about this and had plans to change it, but no ETA.

Fair criticism: We see customers roll their own smoothing quite often, which speaks to the need to resolve this. Those plans last year fell through unfortunately - all I can say today is that it remains in our backlog.

@Jawsarn

Having a low tick rate and predicting other players from input really shows how bad this is.

Yeah: We typically recommend not predicting other players for this reason (if your game can get away with it), but obviously that’s not always feasible (e.g. vehicles). Our Lag Compensation assumes you’re shooting at an interpolated ghost, too. Remote prediction makes that story harder.

@Jawsarn

Partial snapshots cause some predicted entities to have newer state and not be simulated in the prediciton loop. This is can be a big source for mispredictions.

EDIT2: Apologies, I misread this. This is a known limitation, though technically “not a bug” as it’s by design. We’re thinking it may be better to default to “always rollback all ghosts” for simplicity sake.

@Jawsarn

One issue that we’ve encountered is that sometimes you want a entity to be simulated mostly by server, but have a few things predicted by the player e.g. enemy state driven by server but health & combat effects are directly predicted by client. Moving the entity to predicted when hit will cause jitter as movement is no longer interplated.

Yeah, this is another big pain point we see, but requires a fairly big undertaking to improve. The common workaround here is to have a system running after the GhostUpdateSystem, which clobbers the received interpolated state, using a “manually predicted” state tracked yourself. Unfortunately, you then have to track said predicted state yourself, and this approach only really works if the data transformation is trivial (e.g. briefly detaching positions & health values etc).

It does seem like something we can provide an API for though, agreed.

@Jawsarn

Another similar issue was how to deal with predicting static marked entities. Even if moving these to predicted, they won’t get reconciled unless actually changed on server. This could be solved simlarly as above with some RTT reconcile.

Nice catch, definitely a bug - would you mind filing a second bug repro for this?

@Jawsarn

Overhead of scheduling jobs in the prediction loop is heavy at least in 1.4.

We’re investigating how best to mitigate this ATM… It’s non-trivial: While “writing an ISystem and putting it into a SystemGroup” works from the POV of ease-of-use & flexibility, it does make it impossible to schedule multiple systems worth of work once, unless manually unrolled (but even then, there’s Netcode, Physics & Transforms jobs sprinkled in there).

It may just look like a Netcode config toggle to force the entire PredictedSimulationSystemGroup to Run();, paying the cost of the sync point once. Unfortunately, we don’t have the semantics to force non-netcode-owned jobs within that group to be scheduled via Run();, so even this feels incomplete.

If you’re okay making package modifications, that’s what I’d recommend in the short term.

@Jawsarn

NetworkTime causes sync point is a easy trap if dependent on in systems, should be warning or reworked.

This is a (very common) misconception: SystemAPI.GetSingleton<NetworkTime>() (& RW & similar) - which unroll to EntityQuery.GetSingleton<T>() etc - do not trigger completions on dependencies, see: Singleton components | Entities | 1.4.3

EDIT:

@Jawsarn

IInputComponentData is still syncs the whole buffer and not just the data in the IInputComponentData data struct. This require us to use the old way to not waste bandwith.

Yeah, this should get looked at too. IInputComponentData was our attempt at simplifying, but it caused a few new problems. Apologies; can you file a 3rd repo for this?