needle-mirror
diff --git a/‎CHANGELOG.md‎
Lines changed: 86 additions & 31 deletions b/‎CHANGELOG.md‎
Lines changed: 86 additions & 31 deletions
diff --git a/‎Documentation~/command-stream.md‎
Lines changed: 41 additions & 28 deletions b/‎Documentation~/command-stream.md‎
Lines changed: 41 additions & 28 deletions
@@ -17,10 +17,27 @@ The queued commands are then automatically sent at regular interval by `CommandS
 
 The systems responsible for writing to the command buffers must all run inside the [GhostInputSystemGroup](https://docs.unity3d.com/Packages/com.unity.netcode@latest/index.html?subfolder=/api/Unity.NetCode.GhostInputSystemGroup.html).
 
+### ICommandData serialization and payload limit
+When using ICommand, the Netcode for Entities package automatically generated the command serialization code for you. </br>
+Commands serialization take place in the `CommandSendSystemGroup`. Each individual command is serialized and enqueued into the `OutgoingCommandDataStreamBufferComponent` (present on the network connection) 
+by its own code-generated system. </br> The `CommandSendPacketSystem` is then responsible to flush the outgoing buffer at `SimulationTickRate` interval. 
+
+In order to fight packet losses, along with with last input, we also include as a form of redundancy the last 3 input. 
+Each redundant command is delta compressed against the command for the current tick. The final serialized data looks something like:
+
+```
+| Tick, Command | CommandDelta(Tick-1, Tick) | CommandDelta(Tick-2, Tick) | CommandDelta(Tick-3, Tick)|
+```
+
+**The package enforce a size limit of 1024 bytes** to the command payload. The check is performed when the command is serialise into the outgoing buffer and
+an error will be reported to the application if the encoded payload that does not respect the constraint.
+
 ### Receiving commands on the server
-`ICommamdData` are automatically received by the server by the `NetworkStreamReceiveSystem` and added to the `IncomingCommandDataStreamBufferComponent` buffer. The `CommandReceiveSystem` is then responsible 
+`ICommandData` are automatically received by the server by the `NetworkStreamReceiveSystem` and added to the `IncomingCommandDataStreamBufferComponent` buffer. The `CommandReceiveSystem` is then responsible 
 to dispatch the command data to the target entity (which the command belong to).
->![NOTE] The server must only receive commands from the clients. It should never overwrite or change the input received by the client.
+
+> [!NOTE]
+> The server must only receive commands from the clients. It should never overwrite or change the input received by the client.
 
 ## Automatic handling of commands. The AutoCommandTarget component.
 If you add your `ICommandData` component to a ghost (for which the following options has been enabled in the `GhostAuthoringComponent):
@@ -29,23 +46,24 @@ If you add your `ICommandData` component to a ghost (for which the following opt
 
 <img src="images/enable-autocommand.png" width="500" alt="enable-autocommand"/>
 
-the commands for that ghost will **automatically be sent to the server**. Obviously, the following rules apply:
+the commands for that ghost will **automatically be sent to the server**. The following rules apply:
 - the ghost must be owned by your client (requiring the server to set the `GhostOwnerComponent` to your `NetworkIdComponent.Value`), 
-- the ghost is `Predicted` or `OwnerPredicted` (i.e. you therefore cannot use an `ICommandData` to control interpolated ghosts),
+- the ghost is `Predicted` or `OwnerPredicted` (i.e. you cannot use an `ICommandData` to control interpolated ghosts),
 - the [AutoCommandTarget](https://docs.unity3d.com/Packages/com.unity.netcode@latest/index.html?subfolder=/api/Unity.NetCode.AutoCommandTarget.html).Enabled flag is set to true.
 
 If you are not using `Auto Command Target`, your game code must set the [CommandTargetComponent](https://docs.unity3d.com/Packages/com.unity.netcode@latest/index.html?subfolder=/api/Unity.NetCode.CommandTargetComponent.html) on the connection entity to reference the entity that the `ICommandData` component has been attached to. 
-<br/> You can have multiple command systems, and Netcode for Entities will select the correct one (based on the `ICommandData` type of the entity that points to `CommandTargetComponent`).
+<br/> You can have multiple `ICommandData` in your game, and Netcode for Entities will only send the `ICommandData` for the entity that `CommandTargetComponent` points to.
 
 When you need to access the inputs from the buffer, you can use an extension method for `DynamicBuffer<ICommandData>` called `GetDataAtTick` which gets the matching tick for a specific frame. You can also use the `AddCommandData` utility method (which adds more commands to the ring-buffer for you).
 
->~[NOTE] When you update the state of your simulation inside the prediction loop, you must rely only on the commands present in the `ICommandData` buffer (for a given input type). 
+> [!NOTE]
+> When you update the state of your simulation inside the prediction loop, you must rely only on the commands present in the `ICommandData` buffer (for a given input type). 
 Polling input directly, by using UnityEngine.Input or other similar method, or relying on input information not present in the struct implementing the `ICommandData` interface may cause client
 mis-prediction. </br>
 
 ## Checking which ghost entities are owned by the player, on the client.
 > [!NOTE]
-It is required you use (and implement) the `GhostOwnerComponent` functionality, for commands to work properly. For example: By checking the 'Has Owner' checkbox in the `GhostAuthoringComponent`.
+> It is required you use (and implement) the `GhostOwnerComponent` functionality, for commands to work properly. For example: By checking the 'Has Owner' checkbox in the `GhostAuthoringComponent`.
 
 **On the client, it is very common to want to lookup (i.e. query for) entities that are owned by the local player.** 
 This is problematic, as multiple ghosts may have the same `CommandBuffer` as your "locally owned" ghost (e.g. when using [Remove Player Prediction](prediction.md#remote-players-prediction), _every other "player" ghost_ will have this buffer),
@@ -62,7 +80,7 @@ Entities
     .WithAll<GhostOwnerIsLocal>()
     .ForEach((ref MyComponent myComponent)=>
     {
-        // your logic here will be applied only to the entities onwed by "you" (the local player).        
+        // your logic here will be applied only to the entities owned by the local player.    
     }).Run();
 ```
 ### Use the GhostOwnerComponent
@@ -71,12 +89,11 @@ You can filter the entities manually by checking that the `GhostOwnerComponent.N
 ```c#
 var localPlayerId = GetSingleton<NetworkIdComponent>().Value;
 Entities
-    .WithAll<GhostOwnerIsLocal>()
     .ForEach((ref MyComponent myComponent, in GhostOwnerComponent owner)=>
     {
         if(owner.NetworkId == localPlayerId)
         {
-            // your logic here will be applied only to the entitis onwed by the local player.
+            // your logic here will be applied only to the entities owned by the local player.
         }                
     }).Run();
 ```
@@ -86,11 +103,13 @@ Entities
 It's possible to have most of the things mentioned above for command data usage set up automatically for you given an input component data struct you have set up. You need to inherit the `IInputComponentData` interface on the input struct and the task of adding it to the command data buffer and retrieving back from the buffer when processing inputs will be handled automatically via code generated systems. For this to work it is required to have input gathering and input processing (like movement system) set up in two separate systems.
 
 > [!NOTE]
-> It is required you use the `GhostOwnerComponent` functionality, for example by checking the `Has Owner` checkbox in the ghost authoring component for this to work.
+> It is required that you use the `GhostOwnerComponent` functionality, for example by checking the `Has Owner` checkbox in the ghost authoring component for this to work.
 >
->[!NOTE]
+> [!NOTE]
 > Per prefab overrides done in the ghost authoring component inspector are disabled for input components and their companion buffer. You can add a ghost component attribute on the input component in code and it will apply to the buffer as well.
 
+Because input struct implementing `IInputComponentData` are baked by `ICommandData`, [the 1024 bytes limit for the payload](ICommandData serialization and payload limit) also apply. 
+
 ### Input events
 
 By using the `InputEvent` type within `IInputComponentData` inputs you can guarantee one off events (for example gathered by `UnityEngine.Input.GetKeyDown`) will be synchronized properly with the server and registered exactly once. Even when the exact input tick where the input event was first registered is dropped on its way to the server.
@@ -99,21 +118,21 @@ By using the `InputEvent` type within `IInputComponentData` inputs you can guara
 
 Given an input component data you'll have these systems set up.
 
-- Gather input system
-  - Take input events and save in the input component data
-- Process input system
-  - Take current input component and process the values
+- Gather input system (Client loop)
+  - Take input events and save them in the input component data. This happens in `GhostInputSystemGroup`.
+- Process input system (Server or prediction loop)
+  - Take current input component and process the values. This _usually_ happens in `PredictedSimulationSystemGroup`.
 
 With `IInputComponentData` netcode handling it looks like this with code generated systems.
 
-- _Gather input system_
-  - _Take input events and save in an input component data_
-- Copy input to command buffer
+- _Gather input system (Client loop)_
+  - _Take input events and save them in the input component data. This happens in `GhostInputSystemGroup`._
+- Copy input to command buffer (Client loop)
   - Take current input data component and add to command buffer, also recording current tick
-- Apply inputs for current tick to input component data
+- Apply inputs for current tick to input component data (Server or prediction loop)
   - Retrieve inputs from command buffer for current tick and apply to input component. With prediction multiple input values could be applied as prediction rolls back (see [Prediction](prediction.md)).
-- _Process input system_
-  - _Take current input component and process the values_
+- _Process input system (Server or prediction loop)_
+  - _Take current input component and process the values. This _usually_ happens in `PredictedSimulationSystemGroup`._
 
 The first and last steps are the same as with the single player input handling, and these are the only systems you need to write/manage. An important difference, with netcode enabled input, is that the processing system can be called multiple times per tick as previous ticks (rollback) are handled.
 
@@ -223,9 +242,6 @@ public partial struct MyCommandSendCommandSystem : ISystem
         m_CommandSend.OnCreate(ref state);
     }
     [BurstCompile]
-    public void OnDestroy(ref SystemState state)
-    {}
-    [BurstCompile]
     public void OnUpdate(ref SystemState state)
     {
         if (!m_CommandSend.ShouldRunCommandJob(ref state))
@@ -255,9 +271,6 @@ public partial struct MyCommandReceiveCommandSystem : ISystem
         m_CommandRecv.OnCreate(ref state);
     }
     [BurstCompile]
-    public void OnDestroy(ref SystemState state)
-    {}
-    [BurstCompile]
     public void OnUpdate(ref SystemState state)
     {
         var recvJob = new ReceiveJob{data = m_CommandRecv.InitJobData(ref state)};