Merge branch 'develop-2.0.0' into fix/avoid-unnecessry-gc-alloc

Author: NoelStephensUnity

.yamato/_triggers.yml

@@ -45,19 +45,20 @@
 # Since standards job is a part of initial checks it's not present as direct dependency here!!!!!!!!!!!!!!!!!!!!
 pull_request_trigger:
   name: Pull Request Trigger (develop, develop-2.0.0, & release branches)
+  # Run the following tests on a selection of different desktop platforms
   dependencies:
-    # Run package EditMode and Playmode package tests on trunk
-    - .yamato/_run-all.yml#run_all_package_tests_trunk
-    # Run package EditMode and Playmode package tests on minimum supported editor (6000.0 in case of NGOv2.X)
-    - .yamato/_run-all.yml#run_all_package_tests_6000
-    # Run project EditMode and Playmode project tests on trunk
-    - .yamato/_run-all.yml#run_all_project_tests_trunk
-    # Run project EditMode and Playmode project tests on minimum supported editor (6000.0 in case of NGOv2.X)
-    - .yamato/_run-all.yml#run_all_project_tests_6000
-    # Run standalone test. Run windows standalone tests as this is our most common platform, and run ubuntu rust tests.
+    # Run package EditMode and Playmode package tests on trunk and an older supported editor (6000.0)
+    - .yamato/package-tests.yml#package_test_-_ngo_trunk_mac
+    - .yamato/package-tests.yml#package_test_-_ngo_6000.0_win
+
+    # Run testproject EditMode and Playmode project tests on trunk and an older supported editor (6000.0)
+    - .yamato/project-tests.yml#test_testproject_win_trunk
+    - .yamato/project-tests.yml#test_testproject_mac_6000.0
+
+    # Run standalone test. We run it only on Ubuntu since it's the fastest machine, and it was noted that for example distribution on macOS is taking 40m since we switched to Apple Silicon
     # Coverage on other standalone machines is present in Nightly job so it's enough to not run all of them for PRs
     - .yamato/desktop-standalone-tests.yml#desktop_standalone_test_testproject_win_il2cpp_6000.0
-    - .yamato/cmb-service-standalone-tests.yml#cmb_service_standalone_test_testproject_ubuntu_il2cpp_6000.0
+    - .yamato/cmb-service-standalone-tests.yml#cmb_service_standalone_test_testproject_ubuntu_il2cpp_trunk
   triggers:
     cancel_old_ci: true
     pull_requests:

.yamato/project.metafile

@@ -19,7 +19,7 @@
 # The small agent was created to handle jobs that don't involve running Unity and are in general super light when it comes to resource usage (for example pack job).
 # It uses ubuntu since Linux VMs are faster and cheaper to provision than Mac or Windows Virtual Machines (VMs).
 # The b1.small flavour is nearly always sufficient for jobs that don’t involve running Unity Editor.
-small_agent_platform: 
+small_agent_platform:
     - name: ubuntu
       type: Unity::VM
       image: package-ci/ubuntu-22.04:v4
@@ -40,7 +40,7 @@ test_platforms:
           image: package-ci/ubuntu-22.04:v4
           flavor: b1.large
           standalone: StandaloneLinux64
-    desktop:  
+    desktop:
         - name: ubuntu
           type: Unity::VM
           image: package-ci/ubuntu-22.04:v4
@@ -146,7 +146,7 @@ test_platforms:
           image: package-ci/win10-xbox:v4
           flavor: b1.large
           standalone: GameCoreScarlett
-    
+
 # EDITOR CONFIGURATIONS-------------------------------------------------------------------------------
 # Editors to be used for testing. NGOv2.X official support started from 6000.0 editor
 # TODO: When a new editor will be released it should be added to this list
@@ -156,13 +156,14 @@ validation_editors:
         - trunk
     all:
         - 6000.0
-        - 6000.1 
+        - 6000.1
+        - 6000.2
         - trunk
-        
-        
+
+
 # Scripting backends used by Standalone RunTimeTests---------------------------------------------------
 
-scripting_backends: 
+scripting_backends:
   - mono
   - il2cpp
 

com.unity.netcode.gameobjects/CHANGELOG.md

@@ -10,17 +10,25 @@ Additional documentation and release notes are available at [Multiplayer Documen
 
 ### Added
 
+- Added serializer for `Pose` (#3546)
 - Added methods `GetDefaultNetworkSettings` and `GetDefaultPipelineConfigurations` to `UnityTransport`. These can be used to retrieve the default settings and pipeline stages that are used by `UnityTransport`. This is useful when providing a custom driver constructor through `UnityTransport.s_DriverConstructor`, since it allows reusing or tuning the existing configuration instead of trying to recreate it. This means a transport with a custom driver can now easily benefit from most of the features of `UnityTransport`, like integration with the Network Simulator and Network Profiler from the multiplayer tools package. (#3501)
 - Added mappings between `ClientId` and `TransportId`. (#3516)
 - Added `NetworkPrefabInstanceHandlerWithData<T>`, a variant of `INetworkPrefabInstanceHandler` that provides access to custom instantiation data directly within the `Instantiate()` method. (#3430)
 
 ### Fixed
 
+- Fixed regression issue in v2.x where `NetworkObject.GetNetworkBehaviourAtOrderIndex` was converted from public to internal. (#3541)
+- Fixed ensuring OnValueChanged callback is still triggered on the authority when a collection changes and then reverts to the previous value in the same frame. (#3539)
 - Fixed synchronizing the destroyGameObject parameter to clients for InScenePlaced network objects. (#3514)
 - Fixed distributed authority related issue where enabling the `NetworkObject.DestroyWithScene` would cause errors when a destroying non-authority instances due to loading (single mode) or unloading scene events. (#3500)
 
 ### Changed
 
+## [2.4.4] - 2025-07-07
+
+### Added
+
+- Added documentation to package repository.
 
 ## [2.4.3] - 2025-06-25
 

com.unity.netcode.gameobjects/Documentation~/TableOfContents.md

@@ -55,7 +55,6 @@
     * [Reliability](advanced-topics/message-system/reliability.md)
     * [RPC params](advanced-topics/message-system/rpc-params.md)
     * [RPC vs NetworkVariables](learn/rpcvnetvar.md)
-    * [RPC and NetworkVariable examples](learn/rpcnetvarexamples.md)
     * [RPC compatibility](advanced-topics/message-system/rpc-compatibility.md)
   * [Custom messages](advanced-topics/message-system/custom-messages.md)
   * [Connection events](advanced-topics/connection-events.md)
@@ -94,3 +93,11 @@
   * [Troubleshooting](troubleshooting/troubleshooting.md)
   * [Error messages](troubleshooting/error-messages.md)
 * [FAQ](learn/faq.md)
+* [Samples](samples.md)
+  * [Boss Room](samples/bossroom/bossroom-landing.md)
+    - [Boss Room](samples/bossroom/getting-started-boss-room.md)
+    - [Boss Room architecture](samples/bossroom/architecture.md)
+    * [NetworkObject parenting](samples/bossroom/networkobject-parenting.md)
+    * [Optimizing Boss Room](samples/bossroom/optimizing-bossroom.md)
+    * [NetworkRigidbody](samples/bossroom/networkrigidbody.md)
+    * [Spawn NetworkObjects](samples/bossroom/spawn-networkobjects.md)

com.unity.netcode.gameobjects/Documentation~/advanced-topics/bufferserializer.md

@@ -1,6 +1,6 @@
 # BufferSerializer
 
-`BufferSerializer<TReaderWriter>` is the bi-directional serializer primarily used for serializing within [`INetworkSerializable`](inetworkserializable.md) types. It wraps [`FastBufferWriter` and `FastBufferReader`](fastbufferwriter-fastbufferreader.md) to provide high performance serialization, but has a couple of differences to make it more user-friendly:
+`BufferSerializer<TReaderWriter>` is the bi-directional serializer primarily used for serializing within [`INetworkSerializable`](serialization/inetworkserializable.md) types. It wraps [`FastBufferWriter` and `FastBufferReader`](fastbufferwriter-fastbufferreader.md) to provide high performance serialization, but has a couple of differences to make it more user-friendly:
 
 - Rather than writing separate methods for serializing and deserializing, `BufferSerializer<TReaderWriter>` allows writing a single method that can handle both operations, which reduces the possibility of a mismatch between the two
 - `BufferSerializer<TReaderWriter>` does bound checking on every read and write by default, making it easier to avoid mistakes around manual bounds checking required by `FastBufferWriter` and `FastBufferReader`

com.unity.netcode.gameobjects/Documentation~/advanced-topics/client-anticipation.md

@@ -6,7 +6,7 @@ Client anticipation uses `AnticipatedNetworkVariable<T>` and `AnticipatedNetwork
 
 ## Overview
 
-Games with a server-authoritative architecture often face the problem of making the game feel responsive despite [latency](../learn/ladandpacketloss.md). For example, when a user wants to change the color of an object from green to blue they click a button in the UI, an RPC is sent to the server, and the server changes the object to blue. From the client's perspective, the object doesn't change to blue until the server responds to that message, resulting in a perceived delay for the user.
+Games with a server-authoritative architecture often face the problem of making the game feel responsive despite [latency](../learn/lagandpacketloss.md). For example, when a user wants to change the color of an object from green to blue they click a button in the UI, an RPC is sent to the server, and the server changes the object to blue. From the client's perspective, the object doesn't change to blue until the server responds to that message, resulting in a perceived delay for the user.
 
 ![](../images/sequence_diagrams/Anticipation/ServerAuthoritative.png)
 

com.unity.netcode.gameobjects/Documentation~/advanced-topics/custom-serialization.md

@@ -39,7 +39,7 @@ public static class SerializationExtensions
 
 The code generation for RPCs will automatically pick up and use these functions, and they'll become available via `FastBufferWriter` and `FastBufferReader` directly.
 
-You can also optionally use the same method to add support for `BufferSerializer<TReaderWriter>.SerializeValue()`, if you wish, which will make this type readily available within [`INetworkSerializable`](/advanced-topics/serialization/inetworkserializable.md) types:
+You can also optionally use the same method to add support for `BufferSerializer<TReaderWriter>.SerializeValue()`, if you wish, which will make this type readily available within [`INetworkSerializable`](serialization/inetworkserializable.md) types:
 
 ```csharp
 // The class name doesn't matter here.

com.unity.netcode.gameobjects/Documentation~/advanced-topics/fastbufferwriter-fastbufferreader.md

@@ -121,7 +121,7 @@ For performance reasons, by default, `FastBufferReader` and `FastBufferWriter` *
 > **In editor mode and development builds**, calling these functions records a watermark point, and any attempt to read or write past the watermark point will throw an exception. This ensures these functions are used properly, while avoiding the performance cost of per-operation checking in production builds. In production builds, attempting to read or write past the end of the buffer will cause undefined behavior, likely program instability and/or crashes.
 
 
-For convenience, every `WriteValue()` and `ReadValue()` method has an equivalent `WriteValueSafe()` and `ReadValueSafe()` that does bounds checking for you, throwing `OverflowException` if the boundary is exceeded. Additionally, some methods, such as arrays (where the amount of data being read can't be known until the size value is read) and [`INetworkSerializable`](inetworkserializable.md) values (where the size can't be predicted outside the implementation) will always do bounds checking internally.
+For convenience, every `WriteValue()` and `ReadValue()` method has an equivalent `WriteValueSafe()` and `ReadValueSafe()` that does bounds checking for you, throwing `OverflowException` if the boundary is exceeded. Additionally, some methods, such as arrays (where the amount of data being read can't be known until the size value is read) and [`INetworkSerializable`](serialization/inetworkserializable.md) values (where the size can't be predicted outside the implementation) will always do bounds checking internally.
 
 ## Bitwise Reading and Writing
 

com.unity.netcode.gameobjects/Documentation~/advanced-topics/message-system/rpc.md

@@ -218,4 +218,3 @@ There are a few other parameters that can be passed to either the `Rpc` attribut
 ## Additional resources
 
 * [RPC parameters](rpc-params.md)
-* [Boss Room RPC Examples](../../learn/bossroom/bossroom-actions.md)

com.unity.netcode.gameobjects/Documentation~/advanced-topics/object-pooling.md

@@ -16,10 +16,14 @@ You can register your own spawn handlers by including the `INetworkPrefabInstanc
 ```
 Netcode will use the `Instantiate` and `Destroy` methods in place of default spawn handlers for the `NetworkObject` used during spawning and despawning.  Because the message to instantiate a new `NetworkObject` originates from a Host or Server, both won't have the Instantiate method invoked. All clients (excluding a Host) will have the instantiate method invoked if the `INetworkPrefabInstanceHandler` implementation is  registered with `NetworkPrefabHandler` (`NetworkManager.PrefabHandler`) and a Host or Server spawns the registered/associated `NetworkObject`.
 
+<!-- Commenting this out until we can get external code references working
+
 The following example is from the Boss Room Sample. It shows how object pooling is used to handle the different projectile objects. In that example, the class `NetworkObjectPool` is the data structure containing the pooled objects and the class `PooledPrefabInstanceHandler` is the handler implementing `INetworkPrefabInstanceHandler`.
 
 ```csharp reference
 https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/v2.2.0/Assets/Scripts/Infrastructure/NetworkObjectPool.cs
 ```
 
 Let's have a look at `NetworkObjectPool` first. `PooledPrefabsList` has a list of prefabs to handle, with an initial number of instances to spawn for each. The `RegisterPrefabInternal` method, called in `OnNetworkSpawn`, initializes the different pools for each Prefab as `ObjectPool`s inside the `m_PooledObjects` dictionary. It also instantiates the handlers for each Prefab and registers them. To use these objects, a user then needs to obtain it via the `GetNetworkObject` method before spawning it, then return the object to the pool after use with `ReturnNetworkObject` before despawning it. This only needs to be done on the server, as the `PooledPrefabInstanceHandler` will handle it on the client(s) when the network object's `Spawn` or `Despawn` method is called, via its `Instantiate` and `Destroy` methods. Inside those methods, the `PooledPrefabInstanceHandler` simply calls the pool to get the corresponding object, or to return it.
+
+-->