Question Help me understand thin client inputs please

So for the past few hours I've been pouring over ECS Netcode 1.0 documentation, and I'm struggling to implement thin client input simulations.

The Networked Cube sample recommends you use CubeInput : IInputComponentData, but looking at any existing samples - this does not seem to be usable for thin clients.

My current understanding is that to simulate inputs on a thin client, I must:

1. Create a dummy input entity
2. Give it an input buffer of my input typer
3. give it a GhostOwner component filled with NetworkId's singleton's value
   
4. Make the CommandTarget singleton point at it

Specifically, the examples in Megacity Multiplayer, and Netcode Samples' Asteroids, both hint that I should add a buffer of inputs to do this...
But IInputComponentData is not a buffer element...

In the Asteroids sample, ShipCommandData extends ICommandData, which is a buffer element, however to my understanding this is an outdated sample simply patched for 1.0.0 and written originally for 0.50?

In the MegaCity sample, the PlayerVehicleInput is an IInputCommandData as expected... but then there's this suspiciously commented out line in the thin input system.

Code (CSharp):

1.  
2.                 // NOTE: The buffer type might not be recognized in your IDE but it will be generated and Unity will recognize it.
3.                 // TODO : verify this buffer
4.                 //state.EntityManager.AddBuffer<Unity.MegaCity.Gameplay.Generated.PlayerVehicleInputInputBufferData>(inputEntity);

I've tried to replicate MegaCity's thin client input system 1-to-1 code wise, simply using my own cube input component data instead, without the commented out line... and it simply doesn't work. Trying to point to whatever generated component could exist for my input fails as well though it might be the IDE's fault and my failure at guessing the proper path.

I have checked the entities hierarchy and I can confirm that the system does run and I do have a thin client input entity. But there is no input buffer, the server doesn't seem to receive any inputs from it, and holds an empty input buffer.


It is frustrating that the documentation does not cover thin clients to any usable degree, and that the code involved in getting them working has to be found on other samples. I am failing to grasp where is the process going wrong.

From what I can see in the Entities Hierarchy, the thin client does not spawn any ghosts, so there is no entity which is tracked by default, despite the real client properly witnessing said thin client, indicating the server did make a successful connection with it and gave it a player...

Does anyone please have any pointers? What would be required in order to get a thin client working on the networked cube tutorial?

 

Thanks for explaining the server also has to set the command target, I believe this is the only part I was missing after more experiments last night.

I managed to get the generated class IInputComponentData found by adding an assembly definition for my own code (with way too many assembly references just to get ECS working with it) and then adding `
MyCode.Generated.CubeInputInputBufferData` buffer. Though the IDE doesn't recognize it and now permanently tells me I have an error, the code does compile on Unity's side.

For the server, to get the specific player's connection, checking the MegaCity multiplayer demo, the code is quite significantly different. It appears that MegaCity checks for connections without NetworkStreamInGame and then spawns them in, as opposed to the explicit request from the player in the networked cube sample. The code that I ended up adapting for the networked cube sample is

Code (CSharp):

1. commandBuffer.SetComponent(reqSrc.ValueRO.SourceConnection, new CommandTarget { targetEntity = player });

After including both the buffer and the commandtarget on the server, I can confirm this works.

That said, I have to ask whether it would be better to just use ICommandData explicitly, instead? I want to verify my understanding... the purpose IInputComponentData is for convenience with prediction features, as the value is always made to fit the generated buffer matching the frame, is that correct? how would code using CommandData work for prediction reading instead?

Also, if a connection can only have one command target set explicitly, I assume this design is done so that all player input goes through a single entity? so in a case of me wanting to run multiple entities for a single actual player, I would have one input entity with all their inputs and the other entities just point to that input entity to read its components?

I'm asking this because I intended to have 3 characters controlled by every player and assumed they would have separate components storing their intended movement data, but if I can only set one command target entity I would have to change how the code is constructed, so I want to make sure I properly understand please. Is there any way to achieve multiple input entities per connection?

Edit: with thin clients working, I added a button to spawn thin clients on the fly by creating thin client worlds, however, every time I do so, I get this warning:

Code (CSharp):

1. Ignoring invalid [Unity.Entities.UpdateBeforeAttribute] attribute on Unity.NetCode.GhostSimulationSystemGroup targeting Unity.NetCode.PredictedSimulationSystemGroup.
2. This attribute can only order systems that are members of the same ComponentSystemGroup instance.
3. Make sure that both systems are in the same system group with [UpdateInGroup(typeof(Unity.Entities.SimulationSystemGroup))],
4. or by manually adding both systems to the same group's update list.

This only occurs when spawning thin client worlds. Spawning more regular client worlds does not cause this warning. The only two systems of mine that have ThinClient world system filters are "GoInGameClientSystem" as per instructed by the networked cube sample, and "ThinClientCubeInputSystem". The latter uses UpdateInGroup(GhostInputSystemGroup)... my point being that I don't have any UpdateBefore attributes in use at all. What is going on here? how do I get rid of this erronoous warning?

 

Any resolution to this? I'm encountering this exact "bug", but in my case it appears the bug only exists on creation and still functions identically...

 

Btw have u also move auto generated xxxCopyImputToCommandBufferSystem from GhostInputSystemGroup to another new system group so it's possible to add systems in between xxx system and xxxCopyImputToCommandBufferSystem to do something? It's the feature I requested long time ago.

 

Curious is that 1.1 schedule to next release or it's still small 1.0.x patch release?