Skip to content

Invalid Destroy Error in DA When Changing Scenes #3144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
KadaXuanwu opened this issue Nov 28, 2024 · 3 comments
Open

Invalid Destroy Error in DA When Changing Scenes #3144

KadaXuanwu opened this issue Nov 28, 2024 · 3 comments
Assignees
Labels
priority:high This issue has high priority and we are focusing to resolve it stat:awaiting-response Awaiting response from author. This label should be added manually. stat:imported Status - Issue is tracked internally at Unity type:bug Bug Report

Comments

@KadaXuanwu
Copy link

Description

In Distributed Authority (DA) topology, when I spawn objects using NetworkObject.Spawn(destroyWithScene: true), then change scene as SessionOwner using NetworkManager.SceneManager.LoadScene("Lobby", LoadSceneMode.Single), the network objects owned by the clients are correctly destroyed, but the SessionOwner receives an error:
Destroy a spawned NetworkObject on a non-owner client is not valid during a distributed authority session.

Additionally, unchecking Scene Migration Synchronization on the NetworkObject was required, even though in my opinion it should be irrelevant when destroyWithScene: true is set.

Reproduce Steps

  1. Set up a multiplayer game using Netcode for GameObjects (NGO) with Distributed Authority topology.
  2. In a game scene, let clients spawn their own network objects with destroyWithScene: true.
  3. Have the session owner call NetworkManager.SceneManager.LoadScene("Lobby", LoadSceneMode.Single).
  4. Observe the session owner's console output.

Actual Outcome

  • Network objects are destroyed as expected.
  • The session owner receives an error

Expected Outcome

  • Network objects should be destroyed without errors since destroyWithScene: true was explicitly set.
  • in my opinion, Scene Migration Synchronization should not require manual disabling in this context.

Screenshots

NetworkObject on an object owned by a client:
Image

Environment

Additional Context

As far as I know, the player object has to be destroyed by each client manually, where as other spawned network objects should be destroyed automatically on scene change if destroyWithScene: true. Please correct me if I'm wrong.

@KadaXuanwu KadaXuanwu added stat:awaiting-triage Status - Awaiting triage from the Netcode team. type:bug Bug Report labels Nov 28, 2024
@NoelStephensUnity NoelStephensUnity self-assigned this Dec 2, 2024
@NoelStephensUnity NoelStephensUnity added priority:high This issue has high priority and we are focusing to resolve it stat:Investigating Issue is currently being investigated and removed stat:awaiting-triage Status - Awaiting triage from the Netcode team. labels Dec 2, 2024
@NoelStephensUnity
Copy link
Collaborator

@KadaXuanwu
You make some very good points and I finally have some time later this week to setup a replication project to run through some of the issues you are describing.

Regarding the Scene Migration Synchronization, we are doing a quality pass and I am looking at the possibility of expanding the Netcode for GameObjects Project Settings to include some additional global default settings for things like NetworkObject and such where you would be able to define what default values you want when creating new component instances.

@KadaXuanwu
Copy link
Author

Thanks!

Yes, I could see this feature save some time if you have to manually add a lot of NetworkObjects.

@michalChrobot michalChrobot added Investigating stat:awaiting-response Awaiting response from author. This label should be added manually. and removed stat:awaiting-response Awaiting response from author. This label should be added manually. Investigating labels Jan 16, 2025
@michalChrobot michalChrobot added the stat:reply-needed Awaiting reply from Unity account label Apr 1, 2025
@michalChrobot michalChrobot removed the stat:reply-needed Awaiting reply from Unity account label Apr 10, 2025
@NoelStephensUnity
Copy link
Collaborator

NoelStephensUnity commented Jun 13, 2025

Following up on this issue.

Additionally, unchecking Scene Migration Synchronization on the NetworkObject was required, even though in my opinion it should be irrelevant when destroyWithScene: true is set.

While scene migration synchronization seems like it would be associated with the NetworkObject.DestroyWithScene property, there are distinct differences:

  • Scene Migration Synchronization:
    • When enabled, any migration of a NetworkObject from one scene to another is synchronized between all instances.
  • Destroy With Scene:
    • When enabled, if the scene that a NetworkObject resides in is unloaded then the NetworkObject will be destroyed.
      • If the NetworkObject is migrated out of the scene prior to unloading it, then it will not be destroyed since it no longer resides in the scene being unloaded.

So, you can have both properties enabled or disabled and they should not impact each other.

As an example:

  • NetworkObject-A resides in the currently active scene "FirstScene".
    • NetworkObject-A has both SceneMigrationSynchonization and DestroyWithScene enabled
      • For this example, we will just assume the session owner owns/is the authority of NetworkObject-A.
  • The session owner additively loads another scene ("SecondScene").
  • Upon the "SecondScene" being loaded and all connected clients reporting having loaded the scene, the session owner migrates NetworkObject-A to the SecondScene.
    • All clients would receive a scene migration notification and would migrate NetworkObject-A into their locally loaded "SecondScene".
  • A few minutes later, the session owner unloads the "SecondScene".
    • During the unloading of the "SecondScene", NetworkObject-A is despawned and destroyed.

Regarding the error message, looking into this issue as it should just despawn without an error message using the replication steps you outlined originally.

@github-actions github-actions bot added the stat:awaiting-response Awaiting response from author. This label should be added manually. label Jun 13, 2025
@NoelStephensUnity NoelStephensUnity added stat:import Status - Issue is going to be saved internally and removed stat:Investigating Issue is currently being investigated labels Jun 13, 2025
@michalChrobot michalChrobot added stat:imported Status - Issue is tracked internally at Unity and removed stat:import Status - Issue is going to be saved internally labels Jun 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority:high This issue has high priority and we are focusing to resolve it stat:awaiting-response Awaiting response from author. This label should be added manually. stat:imported Status - Issue is tracked internally at Unity type:bug Bug Report
Projects
None yet
Development

No branches or pull requests

3 participants