Support different versions of the same scene, and/or allow setting the id of scene objects so they can sync across different scenes

[brinca]

The use case is that we have a scene for the client with all the bells and whistles (terrain, props, etc), and a stripped down version of the same scene (basically just the navmesh and gameplay elements) for the server.

We're able to load both scenes by tricking Fishnet with a custom scene processor that fakes their loading, but any network objects already present in the client scene are not able to sync with their server scene counterparts, probably because they've been serialized with different ids, given that they're effectively two different scenes.

It does work if spawning new objects, but any scene network objects will become deactivated on the client, although they do work as expected on the server.

The client will also constantly log the warning Spawned NetworkObject was expected to exist but does not for Id 0. This may occur if you sent a NetworkObject reference which does not exist, be it destroyed or if the client does not have visibility, given that its counterpart on the client has a different id, and is therefore invisible to the server.

This could be easily solved if the network object would be allowed to be set to match the server scene counterpart, but maybe a more elegant solution would be to turn this into a proper feature, where you can pass on two scenes for the SceneManager, one for the client and one for the server (kind of like the DualPrefab feature works, only for scenes), with all corresponding scene objects magically assigned the same id (perhaps validation could be done through the transform?).

Having a stripped down version of the scene on the server has incredible benefits, including faster and way smaller builds, way less memory allocated, faster loading times, less computational requirements for the instance type (i.e. cheaper cost), etc.

[brinca]

Btw a related feature that could also be handy is a script/tool/component to automatically strip down an existing scene to create the server version of it.

You could set some parameters (e.g. which objects to keep/which to strip, whether to extract the navmesh, define path for the exported scene, etc), click a button and voilá! the server scene would be created.

It would be even cooler if this script could optionally be hooked up to the build (perhaps using IPreprocessBuildWithReport?), so that it runs every time the server is built.

[FirstGearGames]

SceneIds generated based on scene path and a random Id. It's not particularly possible to reliably generate sceneIds as the scenes are loaded. Generation on load can be done, but there's no way for us to control if our code runs before user code which may manipulate the scene, breaking the Ids.

[brinca]

I get that, and I understand this is an edge case scenario that would probably not be used often enough to warrant deep modifications, but still, having a way to set the object id manually would go a long way, as we would then be able to sync the objects to the correct id, thereby linking them at runtime.

That being said, I'm also well aware that exposing the object id has the potential to become a can of worms, especially by less experienced programmers... ;)

The way we're working around this issue is to have a non-networked version of the scene object both in the client and in the server scenes, which will then spawn the actual networked object in the server scene if in multiplayer mode (Tugboat), or in the client scene if in offline (Yak) mode.

Not very elegant, but does the trick.

[brinca]

Here's an idea for scene object id generation:

1. When the NetworkObject component is attached to a game object, it generates a unique internal id (different than its network id), and serializes it to the object
2. If, at the time of creation, there is already an object with the same internal id (e.g. when duplicating the object), then a new id is generated and serialized
3. At runtime, the client will go through all the network objects, matching their internal id's and linking them to the server counterpart (the serialized id should remain the same as you copy it across scenes)

This id could be exposed in the inspector (and API) so programmers can customize it to something meaningful to them (e.g. Village20/MonsterSpawner130), or regenerate a new one.

To keep things simple, this could be opt-in, through a checkbox option, where if you don't check it, then the regular system will be used for that object.

This is of course untested, and I can already see a few potential issues with this approach (including complicating the workflow a bit), but what do you think?

[FirstGearGames]

I will need to check further but I believe this can be done. I'll make this as accepted until I find out more...

[FirstGearGames]

Added to road map.