Addressable scene loading #3040
Open
+68,312
−12,457
Conversation
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
fixing typo. Updating the minimal CI editor to use
Forgot to add the .1 to the end of exp.
removing the error exception
Fixing invalid entry
…istributed-authority-no-ngo-damode
Consolidated NetworkRigidbody and NetworkRigidbody2D into single base class that provides more customizable options for users. NetworkObject no longer implements the Update method in order to check for object scene migration. Instead, it is registered in a table that is updated in the late update prior to sending any messages about objects migrating into a new scene. This removes the added processing per NetworkObject for scenarios where the NetworkObject plays a more passive role (i.e. a sinlge NetworkBehaviour with one or more NetworkVariables). Fixed issue with parenting when using Rigidbody motion in NetworkTransform. Fixed issue with NotMeRpcTarget when in distributed authority mode.
Fixing missing whitespace. Missed a few spots in the NetworkTransformOwnership tests.
…hnologies#3365) Correcting the XML API documentation for OnGainedOwnership and OnLostOwnership when using a distributed authority network topology. [MTTB-1086](https://jira.unity3d.com/browse/MTTB-1086) fix: Unity-Technologies#3345 ## Changelog NA ## Testing and Documentation - No tests have been added. - Includes edits to existing public API documentation. <!-- Uncomment and mark items off with a * if this PR deprecates any API: ### Deprecated API - [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter yyyy-mm-dd)` entry. - [ ] An [api updater] was added. - [ ] Deprecation of the API is explained in the CHANGELOG. - [ ] The users can understand why this API was removed and what they should use instead. -->
…s#3366) Forwardport of Unity-Technologies#3358 This PR adds a `NetworkManager.OnPreShutdown` callback that happens before the internal shutdown is done. This is to allow accessing any state that is cleaned up by the `NetworkManager` during shutdown, such as accessing dynamically spawned NetworkObjects. ## Changelog - Added: The event NetworkManager.OnPreShutdown has been added which is called before the NetworkManager cleans up and shuts down. ## Testing and Documentation - A test has been added to ensure this is being called, and called before OnServerStopped. <!-- Uncomment and mark items off with a * if this PR deprecates any API: ### Deprecated API - [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter yyyy-mm-dd)` entry. - [ ] An [api updater] was added. - [ ] Deprecation of the API is explained in the CHANGELOG. - [ ] The users can understand why this API was removed and what they should use instead. --> --------- Co-authored-by: Noel Stephens <noel.stephens@unity3d.com>
… (develop-2.0.0) (Unity-Technologies#3360) Wrench version update to 0.10.45 and recipes regeneration
…ld not be started because no valid OpenCL device could be found" error. (Unity-Technologies#3369) After switching from Intel macOS to Apple Silicon due to the common problem with bit-flipping on Intel macOS the WebGL build job started failing due to "Light baking could not be started because no valid OpenCL device could be found" error. We need to figure out if this can be fixed or how to proceed with it. * PR that switched macOS device --> [NGOv1.X](Unity-Technologies#3326), [NGOv2.X](Unity-Technologies#3329) The issue exists on both NGO branches (*develop* and *develop-2.0.0*) so the solution needs to be applied on both. For now I'm disabling this job and tracking it in MTT-11726
…3368) 1. Adds a test replicating the bug fixed in Unity-Technologies#3361 2. Move the code to sync prefabs for late joining clients into the base `NetcodeIntegrationTest` 3. Fix some pvp exceptions ## Changelog - Added: Test covering the bug fixed in Unity-Technologies#3361 ## Testing and Documentation - Adds Unit test --------- Co-authored-by: Noel Stephens <noel.stephens@unity3d.com>
Backport of Unity-Technologies#3371 This PR updates CODEOWNERS file to mainly account for recent creation of netcode-qa group. The reasoning is: - @michalChrobot and @miniwolf were removed since they are part of @Unity-Technologies/netcode-qa group which was added - @fluong6 was removed since he's not focusing on NGO right now and we can lower the noise for him Co-authored-by: Noel Stephens <noel.stephens@unity3d.com>
…Unity-Technologies#3355) After doing some testing I noticed a few anomalies with the updated `BufferedLinearInterpolator<T>`. As it turns out, there are more than one approaches a user might need depending upon what they are trying to accomplish and each option really performs best when tweaking some properties within the `BufferedLinearInterpolator<T>` that were not completely exposed. ### Various options: - You might want to enable, disable, or adjust the maximum interpolation time of the last smooth lerp phase for each interpolator type. - You might want to manually adjust the tick latency offset (`NetworkTransform.InterpolationBufferTickOffset`) used depending upon context. - When using a client-server topology, you might want this to be set to something like 0 or 1 (depending upon interpolator). - You might want this value to be higher (like say +2-3 depending on latency and interpolation type) on non-authority instances where the authority is some other client and not the host/server. ### This PR renames `Lerp` to `LegacyLerp` and adds a 3rd new `Lerp` interpolator type: #### Lerp (new) Uses a 1 to 2 phase approach that lerps towards the target, lerps towards the next target (if one exists) ahead by 1 frame delta, blends the two results, and (optionally) smooth the final value. - The first phase lerps towards the current tick state update being processed. - The fourth phase (optional) performs a lerp smoothing where the current respective transform value is lerped towards the result of the first phase at a rate of 1.0f minus the max interpolation time. ## Changelog - Added: `Lerp` interpolation type that still uses a lerp approach but uses the new buffer consumption logic. - Added: Property to enable or disable lerp smoothing for position, rotation, and scale interpolators. - Added: `NetworkTransform.InterpolationBufferTickOffset` static property to provide users with a way to increase or decrease the time marker where interpolators will pull state update from the queue. - Fixed: Issue where the time delta that interpolators used would not be properly updated during multiple fixed update invocations within the same player loop frame. - Changed: The original `Lerp` to be renamed to `LegacyLerp`. ## Testing and Documentation - Includes integration test updates. - Includes documentation for public API entry points. - Includes updates to public documentation for `NetworkTransform`. (Will be adding to [PR-1443](Unity-Technologies/com.unity.multiplayer.docs#1443)) <!-- Uncomment and mark items off with a * if this PR deprecates any API: ### Deprecated API - [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter yyyy-mm-dd)` entry. - [ ] An [api updater] was added. - [ ] Deprecation of the API is explained in the CHANGELOG. - [ ] The users can understand why this API was removed and what they should use instead. --> --------- Co-authored-by: Emma <emma.mcmillan@unity3d.com>
…nity-Technologies#3381) This update resolves the issue where the legacy lerp result was not yielding the same result as the original lerp. This update also resolves a secondary issue discovered by the services group where the final interpolation (i.e. last measurement in the queue) was not using a high enough precision value when determining if it reached its final destination point. This update also includes some inlining additions along with a spelling mistake with the IsApproximately method. It also updates the XML API regarding Legacy lerp to let users know that it does not use the tick latency value when calculating the ticksAgo value. ## Changelog NA ## Testing and Documentation - No tests have been added. - Includes edits to existing API XML documentation. <!-- Uncomment and mark items off with a * if this PR deprecates any API: ### Deprecated API - [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter yyyy-mm-dd)` entry. - [ ] An [api updater] was added. - [ ] Deprecation of the API is explained in the CHANGELOG. - [ ] The users can understand why this API was removed and what they should use instead. -->
https://jira.unity3d.com/browse/MTT-10043 https://docs.google.com/document/d/1st5PoxRa7rg5JsLW0pKbVAgaqBP1QdUCx2gFlHXEicg/edit?tab=t.0 Adding a SessionStateToken to the ConnectionApproved message and incrementing the version. This is safe without implementing the feature as the service does not need to make any assumptions about what the client does with this information. ## Changelog - Added: Session State Token into the ConnectionApproved message ## Testing and Documentation - Tested using E2E tests and existing tests ## Related PR Unity-Technologies/mps-common-multiplayer-backend#976
…echnologies#3382) This avoids the error message reported in [MTTB-1143](https://jira.unity3d.com/browse/MTTB-1143). The `UnityTransport.Send` method would happily accept invalid or stale connections, which would lead to the allocation of a `BatchedSendQueue` structure and to an error message when the batched sends are passed on to the driver. In MTTB-1143 we'd get a send on client ID 0, but that's not a valid client ID in `UnityTransport`. My guess is that there's something somewhere (possibly in Boss Room) triggering a send to the server after the connection has closed (which reverts `UnityTransport.ServerClientId` to its default value of 0). Of course, ideally there'd never be such a send-after-disconnect and that's what should be ultimately addressed. But the bug is quite hard to reproduce, so as a stopgap until we have something better I'm making a fix that only avoids the last and more user-visible consequences of the issue.
Just a few minor cleanups in Unity Transport: - Remove the internal `NetworkDriver` accessor. There's a public `GetNetworkDriver` nowadays that can be used for the same purpose. - Add a `using` directive for transport errors which avoids using the full (and long) type name. - Remove the internal "state" member. The same information can be gleaned by looking at the driver's state and the value of `m_ServerClientId`. Plus, the `Listening` state did not have the same meaning as it does in NGO itself, which could lead to confusion. - Simplify `ErrorUtilities` to avoid the useless constants and only providing strings for errors users can actually do something about. Also moved it to the bottom of the file. The top is too prime real estate for such a minor utility. :P
…form Parent Detection (Unity-Technologies#3387) This resolves issues with in-scene placed NetworkObject parenting where the original parent has changed. This resolves the issue where loading a scene would not order the serialization of loaded in-scene placed NetworkObjects based on their parent-child hierarchy. This also resolves an issue where a `NetworkTransform` would think it was parented if nested under anything as well as removes the spamming error message when parenting a `NetworkObject` with `NetworkTransform` and using local space for synchronization (can be handled in documentation as to why this is a bad idea but there may be edge cases where a user might want to do this anyway). [MTT-11883](https://jira.unity3d.com/browse/MTT-11883) <!-- Add RFC link here if applicable. --> ## Changelog - Fixed: Issue where in-scene placed `NetworkObjects` could fail to synchronize its transform properly (especially without a `NetworkTransform`) if their parenting changes from the default when the scene is loaded and if the same scene remains loaded between network sessions while the parenting is completely different from the original hierarchy. - Changed: The scene loading event serialization order for in-scene placed `NetworkObject`s to be based on their parent-child hierarchy. - Changed: Removing the error message when a `NetworkObject` with `NetworkTransform` is parented and placed in local space when using rigidbody for motion. ## Testing and Documentation - Includes no additional tests (_requires manual testing due to scene loading constraints_). - No documentation changes or additions were necessary. <!-- Uncomment and mark items off with a * if this PR deprecates any API: ### Deprecated API - [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter yyyy-mm-dd)` entry. - [ ] An [api updater] was added. - [ ] Deprecation of the API is explained in the CHANGELOG. - [ ] The users can understand why this API was removed and what they should use instead. -->
It was noted that webgl builds started timing out more often in the span of the last month so this PR aims to increase the timeout for this job
Due to nature of NGO of having 2 development branches (`develop` for NGOv1.X and `develop-2.0.0` for NGOv2.X) we need to ensure that relevant changes are landing in only one branch (when it's relevant to only develop-2.0.0 for example) or both of them. For people not familiar with NGO structure (but also for us) it might be easy to omit the fact of making a backport (or forward port) so this PR includes a GitHub workflow that will check if "**## Backport**" section exist in the PR thus making it mandatory. This will add a bit of work to each PR but it will ensure that developers get reminded about backports and hopefully this will lead to - Easier PR tracking since every PR will contain a description of a backport or reasoning why a backport is not needed - Reduction of potential forgotten backports which in turn could increase overall quality of NGO I tested this workflow on my fork of NGO repo and seems to be working as expected ## Backport Backport created in Unity-Technologies#3393. After this PR gets approved I will modify branch protection rules to block PRs from merging if this check fails. --------- Co-authored-by: Emma <emma.mcmillan@unity3d.com>
…ssions (Unity-Technologies#3391) This PR aims to modify the template when user wants to create support related issue. The goal is to redirect those to either DIscord or Unity Discussions where user would get much more (and faster) support and by doing this we may minimize the amount of GitHub Issues we need to take care of ## Backport PR is also backported to develop branch in Unity-Technologies#3392
…ogies#3394) This PR ports all new GitHub Actions that were added to develop branch. This will not have any temporary effect since GitHub Actions utilizes configuration from main branch (currently develop) but this ensures that when we will change main branch to be develop-2.0.0 everything will be working in the same way ## Backport This PR ports changes that were included in Unity-Technologies#3194 and Unity-Technologies#3380
This PR is a continuation of Unity-Technologies#3225 and focuses on fixing PVP errors related to PVP-151-1 "**_Public APIs should be documented_**" and all remaining PVP errors **present in pvpExceptions.json file** We currently have 137 errors to address so this PR will be a collaborative effort. If anyone want's to add to it what we should do is: 1. Check errors present in pvpExceptions.json file (preferably under "PVP-150-1", choose some to fix 2. Address those errors and when making commit remove the fixed errors from pvpExceptions file In general [new CI implementation](Unity-Technologies#3193) will catch all new errors like this so all we need to do is fix the present ones. This PR **does not** focus on PVP present in gold profile but if capacity allows, those can also be addressed. **Error present in "PVP-41-1" is to be expected** so there is no need of fixing this one! Another thing is that we could ignore error related to missing APIs for tests (so TestHelpers, EditorTests, RuntimeTests) because those are not affecting users in any way. ## Backport This PR has its equivalent in the sense of Unity-Technologies#3374
…ity-Technologies#3397) This update our internally used actions/checkout version
Unity-Technologies#3398) This PR updates our internally used actions/github-script
This PR follows up on Unity-Technologies#3389 and increases the timeout even more because it was noted that the issue is still happening. After some testing it seems that this timeout is sufficient but some investigation should be performed in the future to see why the job times out more often in such configuration (develop-2.0.0/ubuntu/trunk) ## Backport Since this PR is targeting an Issue that happens mostly in develop-2.0.0, ubuntu/trunk configuration no backport is needed (there is no that big of a problem in develop branch)
This PR merges the changes made to the v2.3.0 branch back into develop-2.0.0 while also adding an unreleased section in the changelog. ## Changelog NA ## Testing and Documentation - No tests have been added. - No documentation changes or additions were necessary. <!-- Uncomment and mark items off with a * if this PR deprecates any API: ### Deprecated API - [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter yyyy-mm-dd)` entry. - [ ] An [api updater] was added. - [ ] Deprecation of the API is explained in the CHANGELOG. - [ ] The users can understand why this API was removed and what they should use instead. -->
…#3401) This PR resolves the issue where instantiating and spawning a `NetworkObject` (A) during another `NetworkObject`'s spawn process (B) and then parenting the newly spawned `NetworkObject` (A) under the `NetworkObject` (B) would end up causing the parenting message to not properly defer the parenting message until the parent (B) was fully spawned on other already connected and synchronized clients (it would properly parent if another client late joined shortly after). [MTTB-1209](https://jira.unity3d.com/browse/MTTB-1209) fix: Unity-Technologies#3100 ## Changelog - Fixed: Issue where during a `NetworkObject` spawn if you instantiated, spawned, and parented another network prefab under the currently spawning `NetworkObject` the parenting message would not properly defer until the parent `NetworkObject` was spawned. ## Testing and Documentation - Includes new integration ParentingDuringSpawnTests test. - No documentation changes or additions were necessary. <!-- Uncomment and mark items off with a * if this PR deprecates any API: ### Deprecated API - [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter yyyy-mm-dd)` entry. - [ ] An [api updater] was added. - [ ] Deprecation of the API is explained in the CHANGELOG. - [ ] The users can understand why this API was removed and what they should use instead. --> ## Backport This requires a backport to v1.x as the `ParentSyncMessage` does not defer the message if the parent `NetworkObject` is not spawned yet.
# Conflicts: # .yamato/code-coverage.yml # .yamato/mobile-build-and-test.yml # .yamato/multiprocess-project-tests.yml # .yamato/project-pack.yml # .yamato/project-standards.yml # .yamato/project-tests.yml # .yamato/standalone-project-tests.yml # .yamato/webgl-build.yml # com.unity.netcode.gameobjects/CHANGELOG.md # com.unity.netcode.gameobjects/Editor/NetworkObjectEditor.cs # com.unity.netcode.gameobjects/Runtime/Components/NetworkTransform.cs # com.unity.netcode.gameobjects/Runtime/Connection/NetworkConnectionManager.cs # com.unity.netcode.gameobjects/Runtime/Core/NetworkManager.cs # com.unity.netcode.gameobjects/Runtime/Core/NetworkObject.cs # com.unity.netcode.gameobjects/Runtime/SceneManagement/NetworkSceneManager.cs # com.unity.netcode.gameobjects/Runtime/Spawning/NetworkSpawnManager.cs # com.unity.netcode.gameobjects/Runtime/Transports/UTP/UnityTransport.cs # com.unity.netcode.gameobjects/Tests/Runtime/DistributedAuthority/OwnershipPermissionsTests.cs # com.unity.netcode.gameobjects/package.json # minimalproject/Packages/packages-lock.json # minimalproject/ProjectSettings/ProjectVersion.txt # testproject/Assets/Tests/Runtime/testproject.runtimetests.asmdef
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Addressable scene loader changes