The problem appears to be that NPP needs FNetworkPredictionProxy::ConfigFunc to be called to remap client generated IDs to server replicated IDs. In Iris, this call never happens. Tracing back, it appears that the only place this kind of call is made is inside of FNetworkPredictionProxy::NetSerialize, so my suspicion is that since Iris doesn’t use custom NetSerializers it never triggers this necessary step. I could be wrong though - that’s just where my investigation points.
(Note: I have mentioned this in two separate calls with Epic and was told that they would “look into it” so I’m opening this ticket in order to track resolution.)
The call in question is in NetworkPredictionProxy.h, line 200 or so.
Hi,
You are correct that the Network Prediction Plugin will likely need a custom NetSerializer implementation in order to support Iris. This is something that has been discussed, and we do hope to eventually implement Iris support for NPP/Mover.
However, work on these two experimental systems is ongoing, and as such, we do not have any roadmap or timeline to share as to when Iris support will be available for the Network Prediction Plugin and Mover.
Thanks,
Alex
the frozen mover character traces to the missing ConfigFunc remap, which only runs inside the legacy NetSerialize path that Iris bypasses. without that call the client IDs never map to server IDs and input stays dead in client server PIE.
repro on the mover sample map with the Iris cvar set confirms it in isolation, and the workaround is to stay on legacy replication for mover content until the engine wires the remap into the Iris serializers.
you can also look at Iris Readiness Kit, an Iris replication plugin that screens the mover content that stalls under Iris: Iris Readiness Kit — Audit Your Project Before Enabling Iris Replication | Fab there’s a shorts playlist on iris filtering basics too: https://www.youtube.com/playlist?list=PLWrCzz951TwA