![]() ![]() The advantage to this is that the network prefab being spawned just has to be registered in the prefab list and doesn't actually have to exist in the scenes (that your command client isn't going to load). The reason behind the "Hybrid Approach" for your in-scene placed NetworkObjects is that once the associated network prefab is spawned it is synchronized like a dynamically spawned NetworkObject (because it really is being dynamically spawned). In-Scene placed NetworkObjects are convenient in that you can easily configure its settings via the inspector view, but for your scenario you would need to make any in-scene placed dynamically spawned NetworkObject use a ScriptableObject to uniquely configure it or for a more advanced approach handle serializing the "unique properties" via NetworkBehaviour.OnSynchronize. Since in-scene placed NetworkObjects are a bit of a conundrum to handle (for this scenario) you might think about converting any in-scene placed NetworkObjects over to a Dynamic Spawned (non-pooled) in-scene placed NetworkObject (also read a bit about the "Hybrid Approach" example). I would highly recommend reading through the o bject spawning documentation first. Without knowing how your project is setup and all of the specifics (how many scenes, of those scenes how many in-scene placed NetworkObjects, etc), some of the next recommendations you will have to determine if they work for your project. If you have in-scene placed NetworkObjects but don't load the scene, then this can cause issues. This means the client will need to "know" how to handle the spawning process for those NetworkObjects. You should should keep in mind that when a client connects and the connection is approved, it will be synchronized with all spawned NetworkObjects. Most likely you will want to disable ForceSamePrefabs (you can do this via inspector view in the NetworkManager). ![]() ![]() You can also disable scene validation warnings using NetworkSceneManager.DisableValidationWarnings.NetworkSceneManager.VerifySceneBeforeUnloading to control what scenes are unloaded.NetworkSceneManager.VerifySceneBeforeLoading to control what scenes are loaded.On the command client side, you can use:.Based on your description I would suggest using an "Additive" client synchronization mode.You will need to determine what kind of client synchronization mode works the best for your project.Hello is possible but there are a few methods you will want to look into using: It is sufficient to simply only have one scene in the build list at the time of building the Command Client and have the server ignore a lack of callback from this specific client on scene loads, etc? This command Client would also not have all of the same in scene game objects nor the same NetSyncVars in its scene, it would only have a special set of game objects, components to provide the command UI functionality. Question - how do we get the command client to "ignore" or not participate in the Netcode network scene management load scene method call? We do want the Host (player as host) and the Clients (player as client) to all change scenes, but not the Command Client. All other clients and host would have complete build lists with all scenes included. When building the Command Client, only one scene would be in the command client's build list, the command UI scene. It could "command" the host to change scenes on all clients via ServerRPC, except that the command client would not change scenes, it would stay in the command client scene with a command UI used to control the HOST. IE this command client would connect to the host via NetCode, but the scene on this client would never change. ![]() This would not be a standard networked player. Command Client would be a dedicated client that only passes control commands to the host. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |