needle-mirror
diff --git a/‎.footignore‎
Lines changed: 1 addition & 0 deletions b/‎.footignore‎
Lines changed: 1 addition & 0 deletions
diff --git a/‎CHANGELOG.md‎
Lines changed: 127 additions & 23 deletions b/‎CHANGELOG.md‎
Lines changed: 127 additions & 23 deletions
diff --git a/‎Documentation~/TableOfContents.md‎
Lines changed: 1 addition & 0 deletions b/‎Documentation~/TableOfContents.md‎
Lines changed: 1 addition & 0 deletions
diff --git a/‎Documentation~/client-server-worlds.md‎
Lines changed: 15 additions & 3 deletions b/‎Documentation~/client-server-worlds.md‎
Lines changed: 15 additions & 3 deletions
diff --git a/‎Documentation~/command-stream.md‎
Lines changed: 154 additions & 12 deletions b/‎Documentation~/command-stream.md‎
Lines changed: 154 additions & 12 deletions
@@ -0,0 +1 @@
+ValidationExceptions.json
@@ -7,6 +7,7 @@
 * [Ghost snapshots](ghost-snapshots.md)
 * [Prediction](prediction.md)
 * [Time synchronization](time-synchronization.md)
+* [Optimizations](optimizations.md)
 * [Logging](logging.md)
 * [Physics](physics.md)
 * [Ghost types and variants](ghost-types-templates.md)
 
@@ -76,7 +76,7 @@ The default number of simulation ticks is 60. The component also has values for
 * `Sleep` for `Application.TargetFrameRate` to reduce CPU load
 * `Auto` to use `Sleep` on headless servers and `BusyWait` otherwise
 
-The client updates at a dynamic time step, with the exception of prediction code which always runs at a fixed time step to match the server. The prediction runs in the [GhostPredictionSystemGroup](https://docs.unity3d.com/Packages/com.unity.netcode@latest/index.html?subfolder=/api/Unity.NetCode.GhostPredictionSystemGroup.html) and applies its own fixed time step for prediction.
+The client updates at a dynamic time step, with the exception of prediction code which always runs at a fixed time step to match the server. The prediction runs in the [PredictedSimulationSystemGroup](https://docs.unity3d.com/Packages/com.unity.netcode@latest/index.html?subfolder=/api/Unity.NetCode.PredictedSimulationSystemGroup.html) and applies its own fixed time step for prediction.
 
 ## Standalone builds
 
@@ -86,7 +86,7 @@ To build a client-only game, add the ```UNITY_CLIENT``` define to the __Scriptin
 
 ## World migration
 
-Sometimes you want to be able to destroy the world you are in and spin up another world without loosing your connection state. In order to do this we supply a DriverMigrationSystem, that allows a user to Store and Load Transport related information so a smooth world transition can be made. 
+Sometimes you want to be able to destroy the world you are in and spin up another world without loosing your connection state. In order to do this we supply a DriverMigrationSystem, that allows a user to Store and Load Transport related information so a smooth world transition can be made.
 
 ```
 public World MigrateWorld(World sourceWorld)
@@ -109,4 +109,16 @@ public World MigrateWorld(World sourceWorld)
 
     return ClientServerBootstrap.CreateServerWorld(DefaultWorld, newWorld.Name, newWorld);
 }
-```
+```
+
+## Thin Clients
+
+Thin clients are a tool to help test and debug in the editor by running simulated dummy clients with your normal client and server worlds. See the _Playmode Tools_ section above for how to configure them
+
+These clients are heavily stripped down and should run as little logic as possible so they don't put a heavy load on the CPU while testing. Each thin client added adds a little bit of extra work to be computed each frame.
+
+Only systems which have explicitly been set up to run on thin client worlds will run, marked with the `WorldSystemFilterFlags.ThinClientSimulation` flag on the `WorldSystemFilter` attribute. No rendering is done for thin client data so they are invisible to the presentation.
+
+In some cases like in `MonoBehaviour` scripts you might need to check if it's running on a thin client and then early out or cancel processing, the `World.IsThinClient()` can be used in those cases.
+
+Most commonly the only important work they need to do is generate random inputs for the server to process. These inputs usually need to be added to a manually created dummy entity as no ghost spawning is done on thin clients. Not even for it's own local ghost/player.
@@ -16,48 +16,190 @@ When you need to access inputs on the client and server, it is important to read
 
 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 buffer.
 
+## Automatic command input setup using IInputComponentData
+
+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.
+>
+>[!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.
+
+### 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.
+
+### How it works
+
+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
+
+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
+  - Take current input data component and add to command buffer, also recording current tick
+- Apply inputs for current tick to input component data
+  - 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_
+
+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.
+
+### Example code
+
+Simple input values for character movement (with jumping):
+
+```c#
+using Unity.Entities;
+using Unity.NetCode;
+
+[GenerateAuthoringComponent]
+public struct PlayerInput : IInputComponentData
+{
+    public int Horizontal;
+    public int Vertical;
+    public InputEvent Jump;
+}
+```
+
+Input gathering system, it basically takes current inputs and applies to the input component data on the local players entity.
+
+```c#
+[UpdateInGroup(typeof(GhostInputSystemGroup))]
+[AlwaysSynchronizeSystem]
+public partial class GatherInputs : SystemBase
+{
+    protected override void OnCreate()
+    {
+        RequireForUpdate<PlayerInput>();
+    }
+
+    protected override void OnUpdate()
+    {
+        bool jump = UnityEngine.Input.GetKeyDown("space");
+        bool left = UnityEngine.Input.GetKey("left");
+        //...
+
+        var networkId = GetSingleton<NetworkIdComponent>().Value;
+        Entities
+            .WithName("GatherInput")
+            .ForEach((ref PlayerInput inputData, ref GhostOwnerComponent owner) =>
+            {
+                if (owner.NetworkId != networkId)
+                    return;
+
+                inputData = default;
+
+                if (jump)
+                    inputData.Jump.Set();
+                if (left)
+                    inputData.Horizontal -= 1;
+                //...
+            }).ScheduleParallel();
+    }
+}
+```
+
+Processing input system, takes current input values stored on the players input component and applies the equivalent movement actions.
+
+```c#
+    [UpdateInGroup(typeof(PredictedSimulationSystemGroup))]
+    public partial class ProcessInputs : SystemBase
+    {
+        protected override void OnCreate()
+        {
+            RequireForUpdate<PlayerInput>();
+        }
+        protected override void OnUpdate()
+        {
+            var movementSpeed = Time.DeltaTime * 3;
+            Entities.WithAll<Simulate>().WithName("ProcessInputForTick").ForEach(
+                (ref PlayerInput input, ref Translation trans, ref PlayerMovement movement) =>
+                {
+                    if (input.Jump.IsSet)
+                        movement.JumpVelocity = 10; // start jump routine
+
+                    // handle jump event logic, movement logic etc
+                }).ScheduleParallel();
+        }
+    }
+```
+
 ## Manual serialization
 
 In order to implement serialization manually you need to add the `[NetCodeDisableCommandCodeGen]` attribute to the struct implementing the `ICommandData` interface.
 
-You will also need to create a struct implementing `ICommandDataSerializaer<T>` - where `<T>` is your `ICommandData` struct.
+You will also need to create a struct implementing `ICommandDataSerializer<T>` - where `<T>` is your `ICommandData` struct.
 
-[ICommandDataSerializaer](https://docs.unity3d.com/Packages/com.unity.netcode@latest/index.html?subfolder=/api/Unity.NetCode.ICommandDataSerializer-1.html) has two __Serialize__ and two __Deserialize__ methods: one pair for raw values, and one pair for delta compressed values. The system sends multiple inputs in each command packet. The first packet contains raw data but the rest are compressed using delta compression. Delta compression compresses inputs well because the rate of change is low.
+[ICommandDataSerializer](https://docs.unity3d.com/Packages/com.unity.netcode@latest/index.html?subfolder=/api/Unity.NetCode.ICommandDataSerializer-1.html) has two __Serialize__ and two __Deserialize__ methods: one pair for raw values, and one pair for delta compressed values. The system sends multiple inputs in each command packet. The first packet contains raw data but the rest are compressed using delta compression. Delta compression compresses inputs well because the rate of change is low.
 
 As well as creating a struct you need to create specific instances of the generic systems `CommandSendSystem` and `CommandReceiveSystem`. To do this, extend the base system, for example with
 ```c#
-public class MyCommandSendCommandSystem : CommandSendSystem<MyCommandSerializer, MyCommand>
+[UpdateInGroup(typeof(CommandSendSystemGroup))]
+[BurstCompile]
+public partial struct MyCommandSendCommandSystem : ISystem
 {
+    CommandSendSystem<MyCommandSerializer, MyCommand> m_CommandSend;
     [BurstCompile]
     struct SendJob : IJobEntityBatch
     {
-        public SendJobData data;
+        public CommandSendSystem<MyCommandSerializer, MyCommand>.SendJobData data;
         public void Execute(ArchetypeChunk chunk, int orderIndex)
         {
             data.Execute(chunk, orderIndex);
         }
     }
-    protected override void OnUpdate()
+    [BurstCompile]
+    public void OnCreate(ref SystemState state)
+    {
+        m_CommandSend.OnCreate(ref state);
+    }
+    [BurstCompile]
+    public void OnDestroy(ref SystemState state)
+    {}
+    [BurstCompile]
+    public void OnUpdate(ref SystemState state)
     {
-        var sendJob = new SendJob{data = InitJobData()};
-        ScheduleJobData(sendJob);
+        if (!m_CommandSend.ShouldRunCommandJob(ref state))
+            return;
+        var sendJob = new SendJob{data = m_CommandSend.InitJobData(ref state)};
+        state.Dependency = sendJob.Schedule(m_CommandSend.Query, state.Dependency);
     }
 }
-public class MyCommandReceiveCommandSystem : CommandReceiveSystem<MyCommandSerializer, MyCommand>
+[UpdateInGroup(typeof(CommandReceiveSystemGroup))]
+[BurstCompile]
+public partial struct MyCommandReceiveCommandSystem : ISystem
 {
+    CommandReceiveSystem<MyCommandSerializer, MyCommand> m_CommandRecv;
     [BurstCompile]
     struct ReceiveJob : IJobEntityBatch
     {
-        public ReceiveJobData data;
+        public CommandReceiveSystem<MyCommandSerializer, MyCommand>.ReceiveJobData data;
         public void Execute(ArchetypeChunk chunk, int orderIndex)
         {
             data.Execute(chunk, orderIndex);
         }
     }
-    protected override void OnUpdate()
+    [BurstCompile]
+    public void OnCreate(ref SystemState state)
+    {
+        m_CommandRecv.OnCreate(ref state);
+    }
+    [BurstCompile]
+    public void OnDestroy(ref SystemState state)
+    {}
+    [BurstCompile]
+    public void OnUpdate(ref SystemState state)
     {
-        var recvJob = new ReceiveJob{data = InitJobData()};
-        ScheduleJobData(recvJob);
+        var recvJob = new ReceiveJob{data = m_CommandRecv.InitJobData(ref state)};
+        state.Dependency = recvJob.Schedule(m_CommandRecv.Query, state.Dependency);
     }
 }
 ```