Skip to content

fix: networkmanager destroy on app quit #1011

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

Merged
merged 12 commits into from
Aug 19, 2021

Conversation

LukeStampfli
Copy link
Contributor

A small fix which helps us to shutdown MLAPI correctly. The problem here was that when we unload a scene or exit playmode 'OnDestroy' gets called in an order which we cannot control. We do want the NetworkManager to shutdown first though before running OnDestroy on NetworkObjects so that we can despawn them correctly.

@Cosmin-B
Copy link
Contributor

Cosmin-B commented Aug 3, 2021

I remember this issue popping out in our samples. It's great that these changes address that.

Copy link
Contributor

@Cosmin-B Cosmin-B left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @LukeStampfli, I have a weird question... I am not sure whether people are supposed to subclass the NetworkManager, but if they do, and they want to override any of those methods, especially Awake, are they able to with this private access modifier + not marking them virtual?

I guess I am more curious about how this code is intended to be used.

Comment on lines 862 to 868
private void OnSceneUnloaded(Scene scene)
{
if (scene == gameObject.scene)
{
OnDestroy();
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so, we're saying if the scene of NetworkManager's scene is being unloaded (therefore it'll also be unloaded as a part of it), we'd manually call OnDestroy() method. wouldn't it be called anyway as a part of scene unloading process? is this block needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is needed because we want OnDestroy on the NetworkManager to be called before OnDestroy gets called on the NetworkObjects in the scene. And this seems to be the only way we can achieve that. (ScriptExecutionOrder does not apply to OnDestroy)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, now I get it. well, sounds like a band-aid to me :/ but let's get that band-aid until we have a better solution.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't fix the issues with NetworkObjects being destroyed on the client side (when pooled) or if you are transitioning between single loading mode scenes when the NetworkManager is within the DontDestroyOnLoad scene because that gets unloaded last (after all other scenes are unloaded).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that's correct, we are not fixing those issues here. This only solves application quit and unloading a non DontDestroyOnLoad NetworkManager from a scene.

Copy link
Contributor

@0xFA11 0xFA11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@0xFA11
Copy link
Contributor

0xFA11 commented Aug 13, 2021

should we get this in? @LukeStampfli

@0xFA11 0xFA11 changed the title fix: networkmanager destroy fix: networkmanager destroy on app quit Aug 19, 2021
@0xFA11 0xFA11 enabled auto-merge (squash) August 19, 2021 15:37
@0xFA11 0xFA11 disabled auto-merge August 19, 2021 15:59
Copy link
Collaborator

@NoelStephensUnity NoelStephensUnity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it should be just fine.

@LukeStampfli LukeStampfli merged commit 0d95605 into develop Aug 19, 2021
@LukeStampfli LukeStampfli deleted the fix/networkmanager-destroy branch August 19, 2021 21:36
SamuelBellomo added a commit that referenced this pull request Aug 23, 2021
…nsform

* develop: (21 commits)
  test: adding more details to multiprocess readme (#1050)
  refactor!: convert NetworkTransform.NetworkState to `struct` (#1061)
  fix: networkmanager destroy on app quit (#1011)
  feat: snapshot, using unreliable packets, now that the underlying foundation supports it. Only merge after #1062 (#1064)
  feat: snapshot. Fully integrated despawn, mtt-1092, mtt-1056 (#1062)
  fix: eliminate bad use-after-free(destroy) pattern (#1068)
  chore: cleanup meta files for empty dirs (#1067)
  chore: minor MLAPI to Netcode rename (#1065)
  feat: report network behaviour name to the profiler (#1058)
  fix: player movement (#1063)
  test: Add unit tests for NetworkTime properties (#1053)
  chore: remove authority & netvar perms from NetworkTransform (#1059)
  feat: networktransform pos/rot/sca thresholds on state sync (#1055)
  feat: expose network behaviour type name internally (#1057)
  chore: remove all the old profiling code (#1048)
  fix: if-guard `NetworkManager.__rpc_name_table` access (#1056)
  fix: Disabling fixedupdate portion of SpawnRpcDespawn test because it's failing for known reasons that will be fixed in the IMessage refactor. (#1049)
  feat: Implement metrics for the new network profiler (#960)
  chore!: change package name & asmdefs (#1026)
  feat: per axis networktransform state sync (+bitwise state comp) (#1042)
  ...

# Conflicts:
#	com.unity.netcode.gameobjects/Prototyping/NetworkTransform.cs
mollstam pushed a commit to Keepsake-Games/com.unity.netcode.gameobjects that referenced this pull request Feb 13, 2023
* fix: Ensure that networkmanager is shutdown before GameObjects are being destroyed

Co-authored-by: M. Fatih MAR <mfatihmar@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants