Fresh writes each container’s batch count as an unsigned 8-bit value in both the full-state and incremental multiplayer events. The reader uses that count to decide how many batches to consume from the stream.
The writer does not currently enforce a maximum, however, and continues serializing every entry in the batch array. If a container ever accumulates more than 255 batches, the encoded count may no longer agree with the number of entries written. Depending on how the game handles an out-of-range value, this could cause synchronization to fail or leave the rest of the event misaligned.
The affected paths are:
RmFreshSyncEvent.lua for the full state sent to joining clients;RmFreshUpdateEvent.lua for container registration and incremental updates.
RmBatch.mergeSimilarBatches reduces the chance of reaching this boundary, but it does not provide a hard maximum.
I have not reproduced this during normal gameplay, so this should be treated as a boundary condition that needs testing rather than a confirmed multiplayer bug. A useful first step would be to round-trip events containing 255 and 256 batches.
Would it make sense to define an explicit limit here? Possible approaches include consolidating batches before synchronization, using a wider count in a versioned event format, or rejecting an oversized payload without writing a partial event. The important part would be ensuring that the writer and reader always agree on the number of serialized batches.
Fresh writes each container’s batch count as an unsigned 8-bit value in both the full-state and incremental multiplayer events. The reader uses that count to decide how many batches to consume from the stream.
The writer does not currently enforce a maximum, however, and continues serializing every entry in the batch array. If a container ever accumulates more than 255 batches, the encoded count may no longer agree with the number of entries written. Depending on how the game handles an out-of-range value, this could cause synchronization to fail or leave the rest of the event misaligned.
The affected paths are:
RmFreshSyncEvent.luafor the full state sent to joining clients;RmFreshUpdateEvent.luafor container registration and incremental updates.RmBatch.mergeSimilarBatchesreduces the chance of reaching this boundary, but it does not provide a hard maximum.I have not reproduced this during normal gameplay, so this should be treated as a boundary condition that needs testing rather than a confirmed multiplayer bug. A useful first step would be to round-trip events containing 255 and 256 batches.
Would it make sense to define an explicit limit here? Possible approaches include consolidating batches before synchronization, using a wider count in a versioned event format, or rejecting an oversized payload without writing a partial event. The important part would be ensuring that the writer and reader always agree on the number of serialized batches.