NetworkPrediction: interpolation service ensures on a normal packet gap it already handles correctly

Development Platform & Builds
, ,
1

The condition being asserted is a normal network event, and the code immediately below the assert already handles it correctly, so the ensure is a false alarm.

Twenty lines further down, bLastWrittenFrameValid explicitly detects that the previous frame has fallen outside the buffer, sets GapFromFrame = LocalFrame , and fills the ring with the latest state. No corrupt state results; we observed no visual artefacts. The only cost is the ensure itself firing during an already-hitchy join.

[Attachment Removed]

2

Steps to Reproduce
On a client, any pause in the incoming packet stream longer than ~1 second causes an ensure in the fixed-tick interpolation service.

Client joining a long-running dedicated server (seen with ~60 min uptime), heavy level streaming during join, at least one sim with simulated-proxy LOD ENetworkLOD::Interpolated . Intermittent since it needs an inbound stall >~1.07s (64 frames @ 60Hz).

[Attachment Removed]

3

Some corrections here.

  1. The packet gap is not actually handled. The gap actually stays consistent forever and there is no catch-up that brings the mover back in sync again.
  2. Once the buffer has overflown, the buffer is caught in a bad state which causes mis-ordered frames within that interpolation buffer to be read back out in incorrect order causing back and forth jitter.
    [Attachment Removed]
4

Hi,

This is a known issue with Network Prediction: https://issues.unrealengine.com/issue/UE\-247380

The issue was originally reported when the engine is running in the background, but the root cause is the same, where the incoming packet stream is delayed for around a minute. I’ve included the info you’ve provided here on our internal tracker for the issue.

I can’t provide an estimate as to when the issue will be fixed, but in the meanwhile, you can try mitigating the problem by increasing the buffer size in TInstanceFrameState (I believe the user who previously reported the issue increased this to 128).

Thanks,

Alex

[Attachment Removed]