Hello,
We’re working on implementing optimizations to bandwidth to reduce bandwidth and Iris TickClientConnections time and the most bandwidth cost comes from NPP’s sync and aux states. We’ve already switched NPP over to Iris with custom serializers for the PolymorphicArrayStructSerializers of FMoverDataCollection, layered moves and movement modifers, etc. We also implemented a custom serializer for the replication proxies to replicate the Sync, Aux and InputCmds alongside with frame data such as SeverFrames, time dilation, etc.
This all works great and permits us to use delta compression for mover characters and our other NPP system. However, we have a lot of data in those Aux and Sync states and Input Cmds. And not all of this data is relevant to all connections. We have many properties only relevant to autonomous proxies, which simulated proxies don’t need to receive.
Even with delta compression enabled and working, replicating many properties irrelevant to sim proxies is adding overhead. Prior to Iris we were able to easily pass along the serialization target to filter properties based on who we’re serializing to, because everything was always serialized per connection.
Now with Iris we quantize the data once and serialize it to all connections, which makes this more difficult. We started writing a templated targeted replication serializer for structs where you can register properties to the config of said struct to only replicate to sim proxies or autonomous proxies, and this worked okay until we noticed that sometimes the server would determine a connection to be simulated proxy, while on the client, during deserialization, the net role of the owning actor is autonomous proxy. We determine this on the server by whether the autonomous connection id of the object, or root object of the object, is the same as the local connection id. We then serialize a single extra bit per struct as to whether this serialized struct is for sim or auto proxies.
The disconnect on client/server seems to resolve within a few frames and only lasts for a short time. The system works, but it’s suboptimal that there can be a disconnect between the two, and serializing an extra bit per struct also seems suboptimal, especially for smaller structs with delta compression. We’re trying to support this with as little modifications to Iris as possible, but it’s getting difficult.
Before we spend time further modifying Iris to resolve the disconnect and overhead of an additional bit per struct, are there any plans in the making for also supporting lifetime conditions for struct members, not just class members? Or is there something we could utilize in Iris to help us with this goal?
Thank you for your time,
With kind regards,
Céleste Neukirchen