Limitation is not a word we like to use in Fish-Networking but unfortunately there are a few technical blocks with Unity, or restrictions in place for performance reasons. These limitations are considered reasonably acceptable and may never be resolved.
Networked Scene Objects
When a scene object is networked they may behave differently.
A networked scene object will be disabled when a scene loads, and will not activate until the client or server is started. For clients specifically networked scene objects will only activate when the server is sure the client has loaded the scene; this is done automatically through the Fish-Networking scene manager.
Our SceneManager allows instantiated networked objects to be moved between scenes, but networked scene objects may not. Unity cannot know a scene objects details without the scene being loaded first, so trying to spawn a scene object without the client having the scene loaded would result in errors.
Due to the movement restrictions just mentioned, networked scene objects may not be marked DontDestroyOnLoad, nor can the NetworkObject.IsGlobal feature be used. Both of these would place the scene object in a new scene, causing errors.
When a networked scene object is despawned it is always disabled, rather than destroyed. This is so you may spawn it at a later time. Manually destroying a scene object on the server is possible and would simply result in it never being spawned on clients.
Nested NetworkObjects and NetworkBehaviours
A nested NetworkObject may be removed from it's parent, but it would still despawn when the parent does, even if no longer a child of the parent. This occurs because the parent has a cached reference of it's nested behaviours and objects, and those references cannot be automatically updated without an unacceptable performance cost. However, this is a feature we intend to explore in the future by letting developers manually indicate when a nested object should be considered detached from the parent.
