fix: NetworkSceneManager does not synchronize despawned in-scene placed NetworkObjects [MTT-2924] (backport #1898)#1968
Closed
NoelStephensUnity wants to merge 56 commits intorelease/1.0.0from
Conversation
This update allows for clients to load scenes and synchronize in-scene placed NetworkObjects during integration testing.
Now that clients are loading scenes, needed to make some minor adjustments.
Realized I don't need to simulate client loading delay unless the client is blocked from loading. Also had to adjust whether the metrics tests waited for the client or not when loading.
GetSceneRelativeInSceneNetworkObject needed to get the sceneHandle before checking for it existing in the ScenePlacedObjects.
AddDespawnedInSceneNetworkObjects needed to only return despawned NetworkObjects belonging to the NetworkManager.
This fixes some of the last edge case scenarios such as: - Not loading scenes for clients when a non-NetcodeIntegrationTest based integration test is running since this does require some additional management and cleanup. - Assuring that in-scene NetworkObjects have the right NetworkManager assigned when loaded - Added a check to assure that it didn't time out while waiting for all clients to connect - Increased the NetcodeIntegrationTestHelpers default timeout to 2s vs 1s (clients loading scenes can slow down when things happen) - NetcodeIntegrationTests now unload all scenes loaded (but the test runner scene) during teardown and onetimeteardown.
Just adding timeout checks in both NetworkVariableTests and TimeMultiInstanceTest
Updating some of the assets used for integration testing now that clients are loading scenes too.
This is the integration test for this PR. It tests late joining client synchronization with despawned NetworkObjects and tests that in-scene placed NetworkObjects do not need to be registered with the NetworkManager to be spawned.
updating comments and minor final tweaks.
reducing the number of clients from 9 to 4 in some of the NetworkSceneManager related tests as I think it impacted performance enough to cause clients to take longer than the default timeout of 2 seconds.
Removing m_CanCheckLoadUnloadEvents as that was a sanity check while I was testing clients loading scenes. This could possibly fix an edge case scenario issue where a message might get ignored.
Removed the crazy code in ObjectNameIdentifier for adding tag information and simplified it by storing the original name and using that each time it needs to regenerate the tag information. Moved where the NetworkManager name and tag information is applied to get the right client id. Added additional debug information.
Went back through some of the changed files and removed some code no longer needed, extended some of the verbose debug info for any future debugging purposes, and updated some of the comments.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a backport of PR-1898
This resolves the issue where an in-scene placed NetworkObject could be despawned prior to a client joining and the client-side in-scene placed NetworkObject component's would not receive a despawn notification when synchronizing.
This also greatly reduces user pain by not requiring users to register in-scene placed NetworkObjets with the NetworkManager using prefab hash overrides. Instead, it just uses the table of in-scene NetworkObjects that were already being tracked by the NetworkSceneManager.
MTT-2924
Changelog
NetworkSceneManagerdoes not synchronize despawned in-scene placed NetworkObjects.NetworkManagerin order to respawn them. In-scene placed NetworkObjects are now automatically tracked during runtime and no longer need to be registered as a NetworkPrefab.Testing and Documentation
NetcodeIntegrationTest Updates:
The image above is an integration test that has two (2) clients and (1) host where the host loaded a scene that has in-scene placed NetworkObjects. If the in-scene NetworkObject has the TestHelper ObjectNameIdentifier component, then like in the above image you will be able to visually distinguish between each relative instance.