MirrorNetworking
feat(NetworkIdentity): Reuse Network IDs
Keep netId's small for CompressVarUInt.
- Uses a Queue (FIFO) with delay time in seconds
- Configurable in Network Manager (Enabled & Delay)
- Queue shown in NI Info Panel
Justification
Imagine the server changes scenes from one with many networked objects to another with many networked objects, or loads and unloads additives somewhat frequently that have a lot of net objects...you want that delay low enough that the id's get reused promptly without risk of reference collision race condition, and we can't just reset to zero on server scene change because DDOL is a thing.
Second example is swarms of mobs that get spawned and destroyed in large-ish numbers, over and over. Their netId's would get reused in every wave.
The other obvious example is networked projectiles, which we all know isn't a good idea, but if a user does that, they're short lived and their id's should recycle quickly.
Pooling doesn't effect any of the above, because unspawn / spawn still gets a new netId assigned.
Ideally most of the time there will be less than 241 networked objects alive at a time, reducing the uint netId to 1 byte on the wire instead of 4. Even if it's over 240 and less than 67824, which really would be the 99.99% case in the real world, that still gets it down to 2 bytes instead of 4 and the more network updates they have the more benefit you get from reusing ids.
I realized talking to someone on Discord this PR may have an effect on the guarantee that OnStartClient be called on the client during initial spawn in the order in which objects where spawned on the server: https://github.com/MirrorNetworking/Mirror/blob/8dc4b616c4e8428b74623687a222bcc249d77ecc/Assets/Mirror/Core/NetworkClient.cs#L1314. I don't know how important that is I just thought I'd mention it.
on the guarantee that OnStartClient be called on the client during initial spawn in the order in which objects where spawned on the server
Wouldn't make any difference than current state of affairs today...scene objects would still be the lowest ID's because they get theirs first before spawned objects and players. Obviously if a scene object got unspawned or destroyed, the ID would be recycled with this PR, and given to the next spawned thing, and if the scene object were respawned it would get a much higher ID in either case, separating it from the initial block of ID's of the remaining scene objects.
Also, if player objects are carried through a scene change in DDOL, the scene objects in the new scene would all have ID's higher than that of the player object in current Mirror and would be more likely to get lower ID's if recycled.
Bottom line is that while that OrderBy attempts to spawn players after scene objects so attempts to get references to them from the player object succeed, that is breakable by circumstances described above, with or without this PR.