Summary
NetworkPrediction’s fixed-tick path schedules ticks using a fractional real-time interval, but converts the simulation step to int32 milliseconds before passing it to simulations. At 64/128 Hz, the scheduling interval and the simulated duration therefore differ. Mover’s NetworkPrediction liaison passes that truncated StepMS through to MoverTimeStep.StepMs.
This source-level finding is present in the unmodified ue6-main and 5.8 sources inspected on 14 October 2026 (exact commits and source links below). It is not a claim of a newly introduced regression, a completed runtime reproduction, or a problem in Mover’s separate Chaos/Network Physics backend.
What Type of Bug are you experiencing?
Networking
Steps to Reproduce
Suggested runtime reproduction (not executed for this report):
- Use an unmodified engine at one of the pinned commits below and enable a fixed-ticking NetworkPrediction model, such as Mover using its NetworkPrediction liaison.
- Set NetworkPrediction FixedTickFrameRate to 64. Ensure the engine fixed-frame-rate override is not substituting another rate, and use no world/input time dilation.
- Inspect the assignments in NetworkPredictionWorldManager.cpp (OnWorldPreTick_Internal on ue6-main) immediately after FixedStepRealTimeMS and FixedStepMS are assigned. Compare those values with FNetSimTimeStep.StepMS received by SimulationTick.
- Compare the simulation-time increase over 64 simulation steps with the 64 real-time scheduling intervals.
- Repeat at 128 Hz for 128 steps. Use 125 Hz (8 ms) as an integer-millisecond control.
The source-only reproduction is the assignment of (1.f / rate) * 1000.f to FixedStepRealTimeMS followed by conversion to int32 for FixedStepMS, then GetNextTimeStep/GetTotalSimTimeMS in NetworkPredictionTickState.h. No project-specific patch is needed to inspect this path.
Expected Result
If a configured rate of 64 or 128 Hz is supported, simulation time should preserve the corresponding 15.625 ms or 7.8125 ms step and agree with the scheduling clock when no dilation is active. Alternatively, if whole-millisecond simulation steps are an intentional restriction, unsupported rates should be explicitly validated/documented rather than silently changing the simulation-time scale.
Is there an existing issue or planned change for fractional simulation-step precision in this backend?
Observed Result
Source-derived values, not a recorded runtime timing capture:
| Configured rate | Real-time scheduling interval | Simulation StepMS | Simulation time after one nominal second of scheduled steps |
|---|---|---|---|
| 64 Hz | 15.625 ms | 15 ms | 960 ms after 64 steps (4% short) |
| 128 Hz | 7.8125 ms | 7 ms | 896 ms after 128 steps (10.4% short) |
| 62.5 Hz | 16 ms | 16 ms | No fractional-step truncation |
| 125 Hz | 8 ms | 8 ms | 1000 ms after 125 steps |
62.5 Hz is an arithmetic comparison when that rate is supplied; the stock NetworkPrediction project rate setting itself is integer-valued. The issue is not that the scheduler automatically changes 128 Hz into 125 Hz: it can schedule 128 ticks while each simulation advances by only 7 ms.
FNetSimTimeStep.StepMS and FFixedTickState.FixedStepMS are int32, GetTotalSimTimeMS multiplies the frame count by FixedStepMS, and Mover copies that StepMS into its own timestep. The header already acknowledges that simulation time can run slower than real time; this report asks about the resulting precision limitation at these rates.
Affects Versions
5.8
Platform(s)
Windows
Additional Notes
Inspected source commits:
- ue6-main: 80499a900f1b9b30f66d3ba1248d1bca1fe4bb42
- 5.8: 4dced763583b8fa05d214b133c2c21b73da300d4
The form does not offer UE6, so 5.8 is selected because the same source path was also verified there. Windows is the local inspection environment; no cross-platform runtime result is claimed.
Source references (Epic GitHub access required):
- UE6 rate-to-step conversion, lines 248-249
- 5.8 rate-to-step conversion, lines 95-96
- Simulation timestep and total-time definitions
- Mover NetworkPrediction timestep forwarding, lines 204-205
No crash, logs, gameplay capture or new runtime test is claimed. This report concerns NetworkPrediction simulation-time precision, not Iris replication frequency or NetServerMaxTickRate. OpenAI Codex assisted with source inspection and preparation of this report.