[Fix] Files correctly generated but paths in MD files didn't match

Major:
- The docfx on the github action rported to be enable to find the ~/resources/... files.
- So we tried to use relative paths this time.

DocFX/articles/Dev/about_UI.md

@@ -7,7 +7,7 @@ In _ECellDive_, every interaction with objects or UI menus is performed remotely
 
 We separated the inputs of _ECellDive_ in three sets of action maps for the movements (teleportation & continuous), the ray-based interaction with UI and modules (grab & move, press button), the ray-based and volumetric interactions with modules to make custom groups. Users can switch cycle on them thanks to the component [InputModeManager](xref:ECellDive.Input.InputModeManager) (in `Controllers` of the `Player` prefab). The component exposes access to two fields [refLeftControlSwitch](xref:ECellDive.Input.InputModeManager.refLeftControlSwitch) and [refRightControlSwitch](xref:ECellDive.Input.InputModeManager.refRightControlSwitch) to specify which action will trigger the input mode cycle on the respective controller. In turn, the action are listening to buttons of the controllers. Hence, when the user press the corresponding button, the action is performed which leads to execution of [LeftControllerModeSwitch](xref:ECellDive.Input.InputModeManager.LeftControllerModeSwitch(InputAction.CallbackContext)) or [RightControllerModeSwitch](xref:ECellDive.Input.InputModeManager.RightControllerModeSwitch(InputAction.CallbackContext)). Those two methods respectively increment the [leftControllerModeID](xref:ECellDive.Input.InputModeManager.leftControllerModeID) and [rightControllerModeID](xref:ECellDive.Input.InputModeManager.rightControllerModeID): the ray-based controls are associated with value `0`, the movement controls with value `1`, and the group controls with value `2`. From `2`, the value cycles to `0`. [leftControllerModeID](xref:ECellDive.Input.InputModeManager.leftControllerModeID) and [rightControllerModeID](xref:ECellDive.Input.InputModeManager.rightControllerModeID) are network variables which changes trigger the network event `OnValueChanged` to which the methods [ApplyLeftControllerActionMapSwitch](xref:ECellDive.Input.InputModeManager.ApplyLeftControllerActionMapSwitch(System.Int32,System.Int32)), [ApplyLeftControllerInteractorsSwitch](xref:ECellDive.Input.InputModeManager.ApplyLeftControllerInteractorsSwitch(System.Int32,System.Int32)), [ApplyRightControllerActionMapSwitch](xref:ECellDive.Input.InputModeManager.ApplyRightControllerActionMapSwitch(System.Int32,System.Int32)) and [ApplyRightControllerInteractorsSwitch](xref:ECellDive.Input.InputModeManager.ApplyRightControllerInteractorsSwitch(System.Int32,System.Int32)) have respectively subscribed. Finally, in those methods, the action maps and interactors the previous [leftControllerModeID](xref:ECellDive.Input.InputModeManager.leftControllerModeID) or [leftControllerModeID](xref:ECellDive.Input.InputModeManager.leftControllerModeID) are deactivated while the ones of the new value are activated. Finally, the information tags of the buttons are updated to match the new input mode.
 
-<img src="~/resources/diagrams/uiSwitchInputMode.svg" alt="UI Switch Input Mode"/>
+<img src="../../resources/diagrams/uiSwitchInputMode.svg" alt="UI Switch Input Mode"/>
 
 ## 2D UI menus
 All 2D UI panel menus are hand-made. Until this point during development, it has been more cost-efficient to duplicate already existing 2D UI items than to spend time making a procedural script that could generate some base menus. As a consequence there is quite a number of 2D UI items in the projects that resemble each other and have only been slightly modified.

DocFX/articles/Dev/about_multiplayer.md

@@ -28,7 +28,7 @@ When a user imports data in a dive scene from a [Kosmogora-like](~/articles/User
 
 In the system we implemented, the data is fragmented into chunks of 1024 bytes at most. Then the [GameNetModuleSpawner](xref:ECellDive.Multiplayer.GameNetModuleSpawner) on the server side spawns the GO, assigns the fragmented data to it and gives ownership of the GO back to the client who made the request first. Finally the owner fragments are broadcasted one by one to all clients by the server. Then, the fragments are reassembled on the side of each client and relevant data is extracted to initialize the module encapsulating the data. This last bit is specific to every data module.
 
-<img src="~/resources/diagrams/multiplayerDataBroadcastRPC.svg" alt="Multiplayer Data Broadcast RPC Example"/>
+<img src="../../resources/diagrams/multiplayerDataBroadcastRPC.svg" alt="Multiplayer Data Broadcast RPC Example"/>
 
 A big downside of the current implementation state of the method is that the client only checks is it has received all fragments but it has not way to know which fragment is missing, should it be the case. This must be covered before even thinking of enabling multiplayer session through the internet for _ECellDive_.  
 
@@ -39,5 +39,5 @@ Before users can dive in a data module (e.g., [CyJsonModule](xref:ECellDive.Modu
 
 A [GameNetModule](xref:ECellDive.Modules.GameNetModule) implementing [GenerativeDiveInC](xref:ECellDive.Modules.GameNetModule.GenerativeDiveInC) (see also the explanations about [_Dive Scenes_](./about_scenes.md#dive-scenes)) can request the generation of the data to the server thanks to [RequestSourceDataGenerationServerRpc](xref:ECellDive.Modules.GameNetModule.RequestSourceDataGenerationServerRpc(System.UInt64)) (which it must also implement). The details of how the generation is implemented is specific for every data module. Here is an example of what it looks like for [CyJsonModule](xref:ECellDive.Modules.CyJsonModule):
 
-<img src="~/resources/diagrams/multiplayerSpawnBroadcast.svg" alt="Multiplayer Spawn Broadcast Example"/>
+<img src="../../resources/diagrams/multiplayerSpawnBroadcast.svg" alt="Multiplayer Spawn Broadcast Example"/>
 

DocFX/articles/Dev/about_scenes.md

@@ -47,4 +47,4 @@ Despite the apparently good match between our concept of _Dive Scene_ and a _Uni
 
 So, in fact, in _ECellDive_, players who dive from a scene to another, never leave the `Main` _Unity Scene_. Our [DiveScenesManager](xref:ECellDive.SceneManagement.DiveScenesManager) keeps track of which gameobject of the _Unity Scene_ belongs to which _Dive Scene_ and, when a user dives, the manager [hides](xref:ECellDive.SceneManagement.DiveScenesManager.HideScene(System.Int32,System.UInt64)) the gameobjects of the previous _Dive Scene_ and [shows](xref:ECellDive.SceneManagement.DiveScenesManager.ShowScene(System.Int32,System.UInt64)) the gameobjects of the new _Dive Scene_. Fellow divers on the multiplayer network are also hidden and showed depending on the _Dive Scene_ they are currently exploring. Bellow is a sequence diagram representing the relevant communications. [GenerativeDiveIn](xref:ECellDive.Interfaces.IDive.GenerativeDiveIn), [HideScene](xref:ECellDive.SceneManagement.DiveScenesManager.HideScene(System.Int32,System.UInt64)), and [ShowScene](xref:ECellDive.SceneManagement.DiveScenesManager.ShowScene(System.Int32,System.UInt64)) involve more communications with every clients of the network which are not represented here.
 
-<img src="~/resources/diagrams/sceneManagementDive.svg" alt="Scene Management Dive"/>
+<img src="../../resources/diagrams/sceneManagementDive.svg" alt="Scene Management Dive"/>