chore: Merging release/1.13.1 back to develop (#3554)

This PR includes changes from recently released NGOv1.13.1 which is

- DOCS fix by @jabbacakes 
- Update of CHANGELOG and package version
- Added `"disableProjectUpdate": false` to testproject which is
unrelated to 1.13.1 release but I noticed that this was the reason of
failures for newer release setup so I added it here

## Backport
No backport needed

---------

Co-authored-by: Amy Reeve <amy.reeve@unity3d.com>

Author: michalChrobot

com.unity.netcode.gameobjects/CHANGELOG.md

@@ -28,6 +28,12 @@ Additional documentation and release notes are available at [Multiplayer Documen
 
 ### Changed
 
+## [1.13.1] - 2025-07-07
+
+### Added
+
+- Added documentation to package repository.
+
 ## [1.13.0] - 2025-04-29
 
 ### Added

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

@@ -44,7 +44,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)
@@ -83,3 +82,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/object-pooling.md

@@ -6,7 +6,7 @@ See [Introduction to Object Pooling](https://learn.unity.com/tutorial/introducti
 
 ## NetworkPrefabInstanceHandler
 
-You can register your own spawn handlers by including the `INetworkPrefabInstanceHandler` interface and registering with the `NetworkPrefabHandler`.  
+You can register your own spawn handlers by including the `INetworkPrefabInstanceHandler` interface and registering with the `NetworkPrefabHandler`.
 ```csharp
     public interface INetworkPrefabInstanceHandler
     {
@@ -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.
+
+-->

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

@@ -21,7 +21,7 @@ Some collision events aren't fired when using `NetworkRigidbody`.
 
 ## NetworkRigidbody and ClientNetworkTransform
 
-You can use NetworkRigidbody with the [`ClientNetworkTransform`](../components/networktransform.md#clientnetworktransform) package sample to allow the owner client of a NetworkObject to move it authoritatively. In this mode, collisions only result in realistic dynamic collisions if the object is colliding with other NetworkObjects (owned by the same client).
+You can use NetworkRigidbody with the [`ClientNetworkTransform`](../components/networktransform.md) package sample to allow the owner client of a NetworkObject to move it authoritatively. In this mode, collisions only result in realistic dynamic collisions if the object is colliding with other NetworkObjects (owned by the same client).
 
 > [!NOTE]
 > Add the ClientNetworkTransform component to your GameObject first. Otherwise the NetworkRigidbody automatically adds a regular NetworkTransform.
@@ -30,9 +30,7 @@ You can use NetworkRigidbody with the [`ClientNetworkTransform`](../components/n
 
 A common issue with physics in multiplayer games is lag and how objects update on basically different timelines. For example, a player would be on a timeline that's offset by the network latency relative to your server's objects. One way to prepare for this is to test your game with artificial lag. You might catch some weird delayed collisions that would otherwise make it into production.
 
-The ClientDriven [bitesize sample](../learn/bitesize/bitesize-clientdriven.md) addresses this by manually adding forces server-side to offer a buffer before an actual collision, but it still feels wobbly at times. However, this isn't really a solution.
-
-The best way to address the issue of physics latency is to create a custom `NetworkTransform` with a custom physics-based interpolator. You can also use the [Network Simulator tool](../../tools/network-simulator.md) to spot issues with latency.
+The best way to address the issue of physics latency is to create a custom `NetworkTransform` with a custom physics-based interpolator. You can also use the [Network Simulator tool](https://docs.unity3d.com/Packages/com.unity.multiplayer.tools@latest?subfolder=/manual/network-simulator) to spot issues with latency.
 
 ## Message processing vs. applying changes to state (timing considerations)
 
@@ -53,8 +51,8 @@ From this list of update stages, the `EarlyUpdate` and `FixedUpdate` stages have
 
 While `NetworkTransform` offers interpolation as a way to smooth between delta state updates, it doesn't get applied to the authoritative instance. You can use `Rigidbody.interpolation` for your authoritative instance while maintaining a strict server-authoritative motion model.
 
-To have a client control their owned objects, you can use either [RPCs](message-system/rpc.md) or [NetworkVariables](../basics/networkvariables.md) on the client-side. However, this often results in the host-client's updates working as expected, but with slight jitter when a client sends updates. You might be scanning for key or device input during the `Update` to `LateUpdate` stages. Any input from the host player is applied after the `FixedUpdate` stage (i.e. physics simulation for the frame has already run), but input from client players is sent via a message and processed, with a half RTT delay, on the host side (or processed 1 network tick + half RTT if using NetworkVariables). Because of when messages are processed, client input updates run the risk of being processed during the `EarlyUpdate` stage which occurs just before the current frame's `FixedUpdate` stage.
+To have a client control their owned objects, you can use either [RPCs](message-system/rpc.md) or [NetworkVariables](../basics/networkvariable.md) on the client-side. However, this often results in the host-client's updates working as expected, but with slight jitter when a client sends updates. You might be scanning for key or device input during the `Update` to `LateUpdate` stages. Any input from the host player is applied after the `FixedUpdate` stage (i.e. physics simulation for the frame has already run), but input from client players is sent via a message and processed, with a half RTT delay, on the host side (or processed 1 network tick + half RTT if using NetworkVariables). Because of when messages are processed, client input updates run the risk of being processed during the `EarlyUpdate` stage which occurs just before the current frame's `FixedUpdate` stage.
 
 To avoid this kind of scenario, it's recommended that you apply any changes received via messages to a Rigidbody _after_ the FixedUpdate has run for the current frame. If you [look at how `NetworkTransform` handles its changes to transform state](https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/blob/a2c6f7da5be5af077427eef9c1598fa741585b82/com.unity.netcode.gameobjects/Components/NetworkTransform.cs#L3028), you can see that state updates are applied during the `Update` stage, but are received during the `EarlyUpdate` stage. Following this kind of pattern when synchronizing changes to a Rigidbody via messages will help you to avoid unexpected results in your Netcode for GameObjects project.
 
-The best way to address the issue of physics latency is to create a custom `NetworkTransform` with a custom physics-based interpolator. You can also use the [Network Simulator tool](../../tools/network-simulator.md) to spot issues with latency.
+The best way to address the issue of physics latency is to create a custom `NetworkTransform` with a custom physics-based interpolator. You can also use the [Network Simulator tool](https://docs.unity3d.com/Packages/com.unity.multiplayer.tools@latest?subfolder=/manual/network-simulator) to spot issues with latency.

com.unity.netcode.gameobjects/Documentation~/advanced-topics/reconnecting-mid-game.md

@@ -64,12 +64,10 @@ Depending on your game, you might want to add the following features as well:
 
 ## Automatic reconnection example
 
-Check out the [Boss Room sample](../learn/bossroom/getting-started-boss-room.md) for an example implementation of automatic reconnection.
 
 The entry point for this feature is in [this class](https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/v2.2.0/Assets/Scripts/ConnectionManagement/ConnectionState/ClientReconnectingState.cs). Boss Room's implementation uses a state inside a state machine that starts a coroutine on entering it ( `ReconnectCoroutine`) that attempts to reconnect a few times sequentially, until it either succeeds, surpasses the defined maximum number of attempts, or is cancelled. (Check out `OnClientConnected`, `OnClientDisconnect`, `OnDisconnectReasonReceived`, and `OnUserRequestedShutdown`.)
 
 The reconnecting state is entered when a client disconnects unexpectedly. (Check out `OnClientDisconnect` in [this class](https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/v2.2.0/Assets/Scripts/ConnectionManagement/ConnectionState/ClientConnectedState.cs))
 
 > [!NOTE]
 > This sample connects with [Lobby](https://docs.unity.com/lobby/unity-lobby-service-overview.html) and [Relay](https://docs.unity.com/relay/get-started.html) services, so the client must make sure it has left the lobby before each reconnection try.
-> For more information about how Boss Room leverages Lobby and Relay, refer to [Getting Started with Boss Room](../learn/bossroom/getting-started-boss-room.md#register-the-project-with-unity-gaming-services-ugs).

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

@@ -23,6 +23,8 @@ The best way to reconnect players depends on your game. For example, if you use
 
 In cases where we don't use the Player Object approach and instead manually attribute client ownership to `NetworkObject`(s), we can keep the objects that a player owns when they disconnect, and set the reconnected player as their new owner. To accomplish this, the only data we would need to keep would be the mapping between those objects and their owning player's identifier, then when a player reconnects we can use this mapping to set them as the new owner. This mapping can be as simple as a dictionary mapping the player identifier with the `NetworkObjectId`(s) of the `NetworkObject`(s) they own. Then, in the `OnClientConnectedCallback` from the `NetworkManager`, the server can set the ownership of these objects.
 
+<!-- Commenting this out until we can get external code references working
+
 Here is an example from the Boss Room sample, showing some simple session management. The game uses the Player Object approach and a GUID to identify unique players.
 
 ```csharp reference
@@ -36,3 +38,5 @@ In this case, since game sessions are quite short, the session data is only clea
 This code is in Boss Room's utilities package so it can be easily reused. You can add this package via the `Package Manager` window in the Unity Editor by selecting `add from Git URL` and adding the following URL: "https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop.git?path=/Packages/com.unity.multiplayer.samples.coop#main"
 
 Or you can directly add this line to your `manifest.json` file: "com.unity.multiplayer.samples.coop": "https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop.git?path=/Packages/com.unity.multiplayer.samples.coop#main"
+
+-->

com.unity.netcode.gameobjects/Documentation~/basics/maxnumberplayers.md

@@ -2,16 +2,18 @@
 
 Netcode for GameObjects provides a way to customize the [connection approval process](connection-approval.md) that can reject incoming connections based on any number of user-specific reasons.
 
+<!-- Commenting this out until we can get external code references working
+
 Boss Room provides one example of how to handle limiting the number of players through the connection approval process:
 
 ```csharp reference
 https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/v2.2.0/Assets/Scripts/ConnectionManagement/ConnectionState/HostingState.cs
 
 ```
+-->
 
 The code below shows an example of an over-capacity check that would prevent more than a certain pre-defined number of players from connecting.
 
-
 ```csharp
 if( m_Portal.NetManager.ConnectedClientsIds.Count >= CharSelectData.k_MaxLobbyPlayers )
 {
@@ -21,6 +23,9 @@ if( m_Portal.NetManager.ConnectedClientsIds.Count >= CharSelectData.k_MaxLobbyPl
 
 > [!NOTE]​
 > In connection approval delegate, Netcode for GameObjects doesn't support sending anything more than a Boolean back.
+
+<!-- Commenting this out until we can get external code references working
 > Boss Room shows a way to offer meaningful error code to the client by invoking a client RPC in the same channel that Netcode for GameObjects uses for its connection callback.
+-->
 
 When using Relay, ensure the maximum number of peer connections allowed by the host satisfies the logic implemented in the connection approval delegate.

com.unity.netcode.gameobjects/Documentation~/basics/networkobject.md

@@ -2,7 +2,7 @@
 
 A NetworkObject is a [GameObject](https://docs.unity3d.com/Manual/GameObjects.html) with a NetworkObject component and at least one [NetworkBehaviour](networkbehaviour.md) component, which enables the GameObject to respond to and interact with netcode.
 
-Netcode for GameObjects' high level components, [the RPC system](../advanced-topics/messaging-system.md), [object spawning](../object-spawning), and [`NetworkVariable`](networkvariable.md)s all rely on there being at least two Netcode components added to a GameObject:
+Netcode for GameObjects' high level components, [the RPC system](../advanced-topics/messaging-system.md), [object spawning](object-spawning), and [`NetworkVariable`](networkvariable.md)s all rely on there being at least two Netcode components added to a GameObject:
 
   1. `NetworkObject`
   2. [`NetworkBehaviour`](networkbehaviour.md)
@@ -165,6 +165,5 @@ Similar to [`NetworkObject.ActiveSceneSynchronization`](#active-scene-synchroniz
 
 ## Additional resources
 
-- [PlayerObjects and player prefabs](playerobjects.md)
 - [NetworkBehaviour](networkbehaviour.md)
 - [NetworkVariable](networkvariable.md)