Client ghosts stop receiving updates when more than one client is connected

[vivid depot]

Hi, I'm using Netcode for Entities to build a moba game. With only one client connected, everything works perfectly (mobs, minions, player controller, ... all behave correctly). However, when i test with two clients connected at the same time, both clients stop receiving ghost updates from the server (no more replication happens). Once either client disconnects, somehow the remaining client starts receiving ghost updates again as expected.

Some observations:

• When there's only one client connected, everything works perfectly.
• Not all clients always stop receiving updates. Sometimes, one client continues to work correctly while others don't.
• Clients still send their input to the server => everything still working correctly on server side.

How can I solve this problem?

[vivid depot]

After some time working around the issue, I found out the root cause was that my IInputComponentData contained too many fields. I estimated that with 3 clients, the error occurs when the size of the InputData reaches around 250 bytes.

– Is this accurate, or am I misunderstanding something?
– If this is true, is it some kind of hidden rule applied to InputComponentData? Is there a way for me to increase this limit beyond 250 bytes?

[hybrid seal]

The limit for iCommandData is 1024 bytes.
https://docs.unity3d.com/Packages/com.unity.netcode@1.6/manual/command-stream.html#icommanddata-serialization-and-payload-limit

Only the local player should be sending input data. Make sure your input system is only running on entities with GhostOwnerIsLocal

[vivid depot]

I think I’ve learned a lesson from not paying attention to that "limit" part of the documentation.
Anyway, the lack of any kind of warning made it approximately 3.14 times harder to find the fix.
In the end, I broke through the limit by modifying NetcodeConfig => GhostSendSystemData => DefaultSnapshotPacketSize.
Is this the correct way to do it?

[hybrid seal]

That would increase the snapshot size, yea. But I would figure out why your snapshots are so large in the first place

[vivid depot]

Yeah, perhaps because I'm using LAN, I haven't been paying much attention to bandwidth.

one champ in my game actually exceeds 1 MTU

[hybrid seal]

That really shouldn't be happening. but it would just break up the message into fragments

[vivid depot]

Hello, sorry to bother you, but I've realized that the payload limit is only one of two causes for my issue. The second cause comes from exactly two lines of code in this script, which is called inside a system in the GhostInputSystemGroup to update the player's input.

• I've tested this thoroughly, and these two lines are definitely responsible for the issue.
• The only unusual thing about these lines is that I use custom types with the suffix _Q3, which means the float values are stored as integers for consistency. The Quantizate3 function is just an extension method to convert regular float types into these _Q3 types.

I can't understand how these lines of code could cause all ghosts to stop updating (when not hitting the payload limit of input, this will happens with around a 50% chance). I've checked carefully, and these operations do not involve any NaN values or number overflows.

[hybrid seal]

Are these custom types getting sent as iCommandData?
You could add [Ghostfield(Quantize)] to that input struct instead of custom types

You might also need some kind of custom serialization
https://docs.unity3d.com/Packages/com.unity.netcode@1.6/manual/ghostfield-synchronize.html#adding-serialization-support-for-custom-types

[vivid depot]

I know about GhostField(Quantize), but what I want is for my data to be quantized even on the sender side ( the one sending the input). Otherwise, the value will only be quantized for those who receive it over the network.

As you can see, it only contains three int fields. I thought it would be serialized over the network automatically. I've used many other structs that are even more complex than this, and they still worked fine in the network.

Or am I required to write a custom serialization for the types I want to use inside IInputComponentData?

[hybrid seal]

That might be the case
https://docs.unity3d.com/Packages/com.unity.netcode@1.6/manual/command-stream.html#manual-serialization

[vivid depot]

I'll give it a try. But I still don't fully understand — is writing a custom serialization template strictly required for syncing any new struct over the network (even something as simple as struct Alice { int age; })? Or is it just in my specific case that I need to write one?

[hybrid seal]

If its just a regular component data, no. input data seems to have a custom serializer. dunno if that's causing your issue or not though

[vivid depot]

I finally figured it out — the real reason was still the payload limit. It seems that when I didn’t change the values of those variables, Netcode reduced the snapshot size, so I didn’t encounter the error. Now my snapshot package size is 4200 😅. Anyway, thanks for your suggestions!

Tested with 5 clients over 10+ runs, and it really was just a package size issue. Honestly, I’m quite surprised I haven’t seen anyone posting about this on the forum, it’s quite hard to figure out the root cause (at least for me).

[hybrid seal]

Interesting. That snapshot size is huge though

[vivid depot]

2800 is not enough so I just add one more MTU XD

😆

[hybrid seal]

You gotta do what you gotta do, but your bandwidth costs are going to be insane