Changing image paths

Author: jabbacakes

com.unity.netcode.gameobjects/Documentation~/advanced-topics/network-update-loop-system/network-update-loop-reference.md

@@ -6,14 +6,14 @@ The following diagrams provide insight into the Network Update Loop process and
 
 <div class="imgwhite">
 
-![Injecting NetworkUpdateLoop Systems Into PlayerLoop](/img/injecting-networkupdatesloop.svg)
+![Injecting NetworkUpdateLoop Systems Into PlayerLoop](../images/injecting-networkupdatesloop.svg)
 
 </div>
 
 ## NetworkUpdateLoop Running INetworkUpdateSystem Updates
 
 <div class="imgwhite">
 
-![NetworkUpdateLoop Running INetworkUpdateSystem Updates](/img/runninginetworkupdatesystemupdates.svg)
+![NetworkUpdateLoop Running INetworkUpdateSystem Updates](../images/runninginetworkupdatesystemupdates.svg)
 
 </div>

com.unity.netcode.gameobjects/Documentation~/basics/connection-approval.md

@@ -204,7 +204,7 @@ The server assigns the `ConnectionApprovalCallback` when it spawns the in-scene
 
 ### Copy the alternate player Prefab's GlobalObjectIdHash value
 
-![Copy-GlobalObjectIdHash](/img/CopyGlobalObjectIdHash.png)
+![Copy-GlobalObjectIdHash](../images/CopyGlobalObjectIdHash.png)
 
 To populate the `AlternatePlayerPrefabs` list:
 

com.unity.netcode.gameobjects/Documentation~/basics/custom-networkvariables.md

@@ -239,7 +239,7 @@ You can test the code above by:
 - Creating a stand alone build and running that as a host or server.
 - Running the same scene within the Editor and connecting as a client.
     - Once connected, you can then select the `GameObject` with the attached `NetworkObject` and `TestMyCustomNetworkVariable` components so it appears in the inspector view. There you can verify the `TestMyCustomNetworkVariable.CustomNetworkVariable` property was synchronized with the client (like in the screenshot below):
-    ![ScreenShot](/img/MyCustomNetworkVariableInspectorView.png)
+    ![ScreenShot](../images/MyCustomNetworkVariableInspectorView.png)
 
 > [!NOTE]
 > You can't nest `NetworkVariable`s inside other `NetworkVariable` classes. This is because Netcode for GameObjects performs a code generation step to define serialization callbacks for each type it finds in a `NetworkVariable`. The code generation step looks for variables as fields of `NetworkBehaviour` types; it misses any `NetworkVariable`s declared anywhere else.

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

@@ -131,13 +131,13 @@ However, when you want to limit which prefabs are available (for example, to red
 
 ## Spawning with (or without) observers
 
-![image](/img/SpawnWithObservers.png)
+![image](../images/SpawnWithObservers.png)
 
 The `NetworkObject.SpawnWithObservers` property (default is true) enables you to spawn a `NetworkObject` with no initial observers. This is the recommended alternative to using `NetworkObject.CheckObjectVisibility` when you just want it to be applied globally to all clients (only when spawning an instance of the `NetworkObject` in question). If you want more precise per-client control then `NetworkObject.CheckObjectVisibility` is recommended. `NetworkObject.SpawnWithObservers` is only applied upon the initial server-side spawning and once spawned it has no impact on object visibility.
 
 ## Transform synchronization
 
-![image](/img/NetworkObject-TransformSynchronization.png)
+![image](../images/NetworkObject-TransformSynchronization.png)
 
 There are times when you want to use a NetworkObject for something that doesn't require the synchronization of its transform. You might have an [in-scene placed NetworkObject](./scenemanagement/inscene-placed-networkobjects.md) that's only used to manage game state and it doesn't make sense to incur the initial client synchronization cost of synchronizing its transform. To prevent a NetworkObject from initially synchronizing its transform when spawned, deselect the **Synchronize Transform** property. This property is enabled by default.
 
@@ -146,15 +146,15 @@ There are times when you want to use a NetworkObject for something that doesn't
 
 ## Active scene synchronization
 
-![image](/img/ActiveSceneMigration.png)
+![image](../images/ActiveSceneMigration.png)
 
 When a GameObject is instantiated, it gets instantiated in the current active scene. However, sometimes you might find that you want to change the currently active scene and would like specific NetworkObject instances to automatically migrate to the newly assigned active scene. While you could keep a list or table of the NetworkObject instances and write the code/logic to migrate them into a newly assigned active scene, this can be time consuming and become complicated depending on project size and complexity. The alternate and recommended way to handle this is by enabling the **Active Scene Synchronization** property of each NetworkObject you want to automatically migrate into any newly assigned scene. This property defaults to disabled.
 
 Refer to the [NetworkSceneManager active scene synchronization](../basics/scenemanagement/using-networkscenemanager#active-scene-synchronization) page for more details.
 
 ## Scene migration synchronization
 
-![image](/img/SceneMigrationSynchronization.png)
+![image](../images/SceneMigrationSynchronization.png)
 
 Similar to [`NetworkObject.ActiveSceneSynchronization`](#active-scene-synchronization), [`NetworkObject.SceneMigrationSynchronization`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkObject.html#Unity_Netcode_NetworkObject_SceneMigrationSynchronization) automatically synchronizes client-side NetworkObject instances that are migrated to a scene via [`SceneManager.MoveGameObjectToScene`](https://docs.unity3d.com/ScriptReference/SceneManagement.SceneManager.MoveGameObjectToScene.html) on the host or server side. This can be useful if you have a specific scene you wish to migrate NetworkObject instances to that is not the currently active scene.
 

com.unity.netcode.gameobjects/Documentation~/basics/object-spawning.md

@@ -102,7 +102,7 @@ m_SpawnedNetworkObject.Despawn();
 
 To make this the default from the editor Inspector view:
 
-![image](/img/DontDestroyWithOwner.png)
+![image](../images/DontDestroyWithOwner.png)
 
 As an alternative way, you can make the `NetworkObject.DontDestroyWithOwner` property default to `true` by setting it on the `NetworkObject` itself like in the above screenshot.
 
@@ -299,17 +299,17 @@ You might run across a situation where you still want other components on the ro
 
 Below is an example of what a non-pooled friendly Prefab might look like:
 
-![image](/img/non-pooled-friendly-prefab.png)
+![image](../images/non-pooled-friendly-prefab.png)
 
 The issues you might run into with the above Prefab hierarchy is that everything is on a single `GameObject`, and as such if you wanted to disable the `MeshRenderer` and the `NetworkObjectLabel`, [one of our classes in the Netcode for GameObjects test project](https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/blob/f0631414e5a5358a5ac7811d43273b1a82a60ca9/testproject/Assets/Scripts/NetworkObjectLabel.cs#L4), you would need to get those component types before disabling them (that is, during `Start` or `OnNetworkSpawn` or get them when `OnNetworkDespawn` is invoked).
 
 To reduce this level of complexity, a more "pooled dynamic spawning" friendly Prefab heirarchy might look like this:
 
-![image](/img/pooled-friendly-prefab.png)
+![image](../images/pooled-friendly-prefab.png)
 
 The `NetworkObject` sits at the root `GameObject` of the network prefab. The child `GameObject`, SpawnedComponents, then has everything that you might want to have disabled when the network Prefab instance isn't spawned:
 
-![image](/img/pooled-friendly-prefab-child.png)
+![image](../images/pooled-friendly-prefab-child.png)
 
 This reduces the complexity down to setting the SpawnedComponents `GameObject` to inactive, which will also disable all of the components attached to it.
 

com.unity.netcode.gameobjects/Documentation~/basics/scenemanagement/client-synchronization-mode.md

@@ -12,7 +12,7 @@ If you are already familiar with Netcode for GameObjects, then this is most like
 
 This means any scene that is loaded on the client side prior to being synchronized will be unloaded when the first/default active scene is loaded.
 
-![image](/img/ClientSynchronizationModeSingle.png)
+![image](../images/ClientSynchronizationModeSingle.png)
 
 The above image shows a high level overview of single mode client synchronization. For this scenario, a client had just left a network session where the game session was on Level 1. The client still has two common scenes to all levels, Enemy Spawner and World Items scenes, and the Level scenes contain unique assets/settings based on the level number reached. The client then joins a new game session that is on Level 3. With single mode client synchronization, the currently active scene on the server-side is the first scene loaded in `LoadSceneMode.Single` on the client-side (thus why we refer to the client synchronization mode as "single"). By default, loading a new scene in `LoadSceneMode.Single` mode will unload all currently loaded scenes before loading the new scene. Then, for each additional scene that the server requires the client to have loaded in order to be fully synchronized, all remaining scenes are loaded additively (`LoadSceneMode.Additive`).
 
@@ -25,7 +25,7 @@ Additive client synchronization is mode similar to additive scene loading in tha
 
 This can be particularly useful if you have common UI element scenes (i.e. menu interfaces) that you would like to persist throughout the duration of the application instance's life cycle (i.e. from the time the application starts to the time it is stopped/exited).  It can also be useful to have certain scenes pre-loaded ahead of time to reduce load times when connecting to an existing network session.
 
-![image](/img/ClientSynchronizationModeAdditive.png)
+![image](../images/ClientSynchronizationModeAdditive.png)
 
 In the above image we can see a scenario where a server has a Menu UI Scene that it ignores using `NetworkSceneManager.VerifySceneBeforeLoading`, two scenes that the project is configured to always have pre-loaded _(Enemy Spawner and World Items scenes)_, and the server has reached "level 3" of the networked game session so it has the Level 3 scene loaded. The client side almost mirrors the server side (scenes loaded relative) when it began the synchronization process. The only difference between the server and the client was the Level 3 scene that the client has to load in order to be fully synchronized with the server.
 
@@ -39,7 +39,7 @@ When this flag is set on the client side any scenes that were not synchronized w
 ### NetworkSceneManager.VerifySceneBeforeUnloading
 When `NetworkSceneManager.PostSynchronizationSceneUnloading` is set to `true` and the client synchronization mode is `LoadSceneMode.Additive`, if this callback is set then for each scene that is about to be unloaded the set callback will be invoked. If it returns `true` the scene will be unloaded and if it returns `false` the scene will remain loaded. This is useful if you have specific scenes you want to persist (menu interfaces etc.) but you also want some of the unused scenes (i.e. not used during synchronization) to be unloaded.
 
-![image](/img/ClientSynchronizationModeAdditive2.png)
+![image](../images/ClientSynchronizationModeAdditive2.png)
 
 Let's take the previous client synchronization mode scenario into consideration with the client side having `NetworkSceneManager.PostSynchronizationSceneUnloading` set to `true` and registering a callback for `NetworkSceneManager.VerifySceneBeforeUnloading` where it returns false when client synchronization attempts to unload the Menu UI Scene. Let's also assume this game allows clients to join other network sessions while still in a current network session and that the client had just come from a previous game where the server was still on "level 1" (so the client has the level 1 scene still loaded). When the client begins to synchronize the two pre-loaded scenes are used for synchronization, the client still has to load the Level 3 scene, but at the end of the synchronization `NetworkSceneManager` begins to unload any remaining scenes not synchronized by the server and the client. When the Menu UI Scene is checked if it can be unloaded, the client side `NetworkSceneManager.VerifySceneBeforeUnloading` callback returns `false` so that scene remains loaded. Finally, the Level 1 scene is verified to be unloaded via `NetworkSceneManager.VerifySceneBeforeUnloading` which the user logic determines is "ok" to unload so it returns `true` and the Level 1 scene is unloaded.
 

com.unity.netcode.gameobjects/Documentation~/basics/scenemanagement/scene-events.md

@@ -57,7 +57,7 @@ While client synchronization does fall partially outside of the scene management
 <br/>
 Below is a diagram of the client connection approval and synchronization process:
 
-![image](/img/scenemanagement_synchronization_overview.png)
+![image](../images/scenemanagement_synchronization_overview.png)
 
 Starting with the "Player" in the top right part of the above diagram, the client (Player) runs through the connection and approval process first which occurs within the `NetworkManager`.  Once approved, the server-side `NetworkSceneManager` begins the client synchronization process by sending the `SceneEventType.Synchronize` Scene Event message to the approved client.  The client then processes through the synchronization message.  Once the client is finished processing the synchronize message, it responds to the server with a `SceneEventType.SynchronizeComplete` message. At this point the client is considered "synchronized".  If the server determines any `NetworkObject` was despawned during the client-side synchronization message processing period, it will send a list of `NetworkObject` identifiers to the client via the `SceneEventType.ReSynchronize` message and the client will locally despawn the `NetworkObject`s.
 
@@ -228,10 +228,10 @@ You can stop the coroutine checking the progress upon receiving any of the follo
 The SceneEvent class has values that may or may not be set depending upon the `SceneEventType`.  Below are two quick lookup tables to determine which property is set for each `SceneEventType`.
 
 **Part-1**<br/>
-![image](/img/SceneEventProperties-1.png)<br/>
+![image](../images/SceneEventProperties-1.png)<br/>
 
 **Part-2** <br/>
-![image](/img/SceneEventProperties-2.png)<br/>
+![image](../images/SceneEventProperties-2.png)<br/>
 
 So, the big "take-away" from the above table is that you need to understand the `SceneEventType` context of the `SceneEvent` you are processing to know which properties are valid and you can use.  As an example, it wouldn't make sense to provide the AsyncOperation for the following `SceneEventType`s:
 - LoadComplete or LoadEventCompleted

com.unity.netcode.gameobjects/Documentation~/basics/spawning-synchronization.md

@@ -6,7 +6,7 @@ Ensuring that objects spawn in a synchronized manner across clients can be diffi
 
 Due to the restrictive nature of only the server having the authority to spawn objects, visual anomalies between clients are common in [client-server](../terms-concepts/client-server.md) contexts. This typically occurs when using an owner-authoritative motion model, also known as a ClientNetworkTransform, and trying to visually synchronize the spawning of an object relative to a local player's current position (for example, a player shooting a projectile).
 
-![Client server spawn synchronization](/img/client-server-spawn-sync.jpg)
+![Client server spawn synchronization](../images/client-server-spawn-sync.jpg)
 
 In the diagram above, a client-owned object (a player) is in motion while firing a projectile. The code implementing this behavior involves sending a message (typically an [RPC](../advanced-topics/messaging-system.md)) from the client to the server to get an object to spawn based on the player's input. Due to the latency involved in sending this message to the server and then propagating the resulting spawn message across all clients, including back to the initiating client, the spawn projectile message reaches the initiating client after the client's local player has moved, resulting in a visual disconnect between the local player and the projectile.
 

com.unity.netcode.gameobjects/Documentation~/components/networkanimator.md

@@ -34,7 +34,7 @@ The `Animator` trigger property type ("trigger") is basically nothing more than
 
 The default setting for `NetworkAnimator` is server authoritative mode. When operating in server authoritative mode, any animation state changes that are set (triggers) or detected (change in layer, state, or any `Animator` properties excluding triggers) on the server side will be synchronized with all clients. Because the server initiates any synchronization of changes to an `Animator` 's state, a client that's the owner of the `NetworkObject` associated with the `NetworkAnimator` can lag by roughly the full round trip time (RTT). Below is a timing diagram to show this:
 
-![ServerAuthMode](/img/NetworkAnimatorServerAuthTiming.png)
+![ServerAuthMode](../images/NetworkAnimatorServerAuthTiming.png)
 
 In the above diagram, a client might be sending the server an RPC to tell the server that the player is performing some kind of action that can change the player's animations (including setting a trigger). Under this scenario, the client sends an RPC to the server (half RTT), the server processes the RPC, the associated `Animator` state changes are detected by the `NetworkAnimator` (server-side), and then all clients (including the owner client) are synchronized with the changed.
 
@@ -63,7 +63,7 @@ Usually, your project's design (or personal preference) might require that owner
 
 Looking at the timing for an owner authoritative `NetworkAnimator`, in the diagram below, you can see that while the owner client gets "immediate visual animation response" the non-owner clients end up being roughly one full RTT behind the owner client and a host would be half RTT behind the owner client.
 
-![ServerAuthMode](/img/NetworkAnimatorOwnerAuthTiming.png)
+![ServerAuthMode](../images/NetworkAnimatorOwnerAuthTiming.png)
 
 In the above diagram, it shows that the owner client has an `Animator` state change that's detected by the `NetworkAnimator` ( `OwnerNetworkAnimator`) which automatically synchronizes the server with the changed state. The server applies the change(s) locally and then broadcasts this state change to all non-owner clients.
 
@@ -90,13 +90,13 @@ Using `NetworkAnimator` is a pretty straight forward approach with the only subt
 
 If you decide you want to use the server authoritative model, then you can add a `NetworkAnimator` component to either the same `GameObject` that has the `NetworkObject` component attached to it or any child `GameObject`. In the below screenshot, you can see a network Prefab that houses two authoritative models. The `NetworkAnimatorCube-Server` `GameObject` has an `Animator` component, an `AnimatedCubeController` component (used for manual testing), and the `NetworkAnimator` component that has a reference to the `Animator` component.
 
-![Usage-1](/img/NetworkAnimatorUsage-1.png)
+![Usage-1](../images/NetworkAnimatorUsage-1.png)
 
 ### Owner Authoritative
 
 If you decide you want to use the owner authoritative model, then (for example purposes) you would use your derived `OwnerNetworkAnimator` component as opposed to the default `NetworkAnimator` component like in the screenshot below:
 
-![Usage-1](/img/NetworkAnimatorUsage-2.png)
+![Usage-1](../images/NetworkAnimatorUsage-2.png)
 
 > [!NOTE]
 > While it isn't advised to have different `NetworkAnimator` authoritative models "under the same root network Prefab `GameObject`, " you can have multiple children that each have their own `Animator` and `NetworkAnimator` all housed under a single `NetworkObject` and all use the same authoritative model. However, you should always consider the balance between performance (CPU or bandwidth consumption) and convenience/modularity.