Does the Asteroids Sample "actually" use Auto Command Target?

I am checking out the updated Asteroids sample and it seems like the Server's SpawnSystem is setting the CommandTargetComponent targetEntity to the player entities when spawning players:

https://github.com/Unity-Technologi...mples/Asteroids/Server/Systems/SpawnSystem.cs

I see that the Ship prefab has "Support Auto Command Target" enabled

1. Would the Asteroids sample not work if the Server did not set the CommandTargetComponent on the Network Connection Entity?
2. I see that the ShipGhostSpawnSystem.cs has been removed so I am guessing that means that the client does not need to set the CommandTargetComponent targetEntity but the server does?

 

I have been working through a project and I realize that I am not as clear on this as I thought.

"AutoCommandTarget does not work for thin clients since thin clients do not spawn any ghosts and the AutoCommandTarget relies on ghosts."

In InputSystem.cs

• If it is a thin client, then a ICommandData where shoot = 1 is created
• If it is not a thin client, and space is pressed, then a ICommandData where shoot = 1 is created
• The thin client sends a PlayerSpawnRequest to create a ghost player for itself
• The normal client sends a PlayerSpawnRequest to create a ghost player for itself

It seems that thin clients do indeed spawn ghosts for themselves (?).

1. In the sample project it says "

// Special handling for thin clients since we can't tell if the ship is spawned or not

", how is this different than a normal client?
2. If the thin client hits space bar (which it does every 100 frames), and it does not have a ghost (which it could tell by

TryGetSingletonEntity<ShipCommandData>(out var targetEntity);

), then it should send an RPC no? I guess the question is why does

TryGetSingletonEntity<ShipCommandData>(out var targetEntity);

not work for a thin client?

 

@timjohansson @CMarastoni

I just tried to reimplement the Asteroids sample without setting the Network Connection Entity CommandTargetComponent's targetEntity field.

What I learned is that this actually breaks the flow, the reason being is this line here in InputSystem:

Code (CSharp):

1. TryGetSingletonEntity<ShipCommandData>(out var targetEntity);

• This expects there to be only 1 Player
• But without seeing the CommandTargetComponent in SpawnSystem, the Server will respond multiple times to the PlayerSpawnRequest
• That is because this check no longer works on the server side:
• Code (CSharp):

  1.                 commandBuffer.DestroyEntity(entity);
  2.                 if (!playerStateFromEntity.HasComponent(requestSource.SourceConnection) ||
  3.                     !commandTargetFromEntity.HasComponent(requestSource.SourceConnection) ||
  4.                     commandTargetFromEntity[requestSource.SourceConnection].targetEntity != Entity.Null ||
  5.                     playerStateFromEntity[requestSource.SourceConnection].IsSpawning != 0)
  6.                     return;
• This is because it will take a few frames for the ghost to appear on the client
• While the client is waiting for the ghost to appear, it is sending more RPCs
• This causes the server to spawn more ghosts

So it appears that in the Asteroids sample not only did setting the CommandTargetComponent on the Network Connection Entity serve to send ICommandData, it seems to also act as a boolean "this Network Connection Entity already has a player, do not send them another one".

This seems like it can be solved by:
1. predictively spawning the player (so the client stops spawning players because

Code (CSharp):

1. TryGetSingletonEntity<ShipCommandData>(out var targetEntity);

will be able to grab the entity next frame)
2. Use PlayerStateComponentData to track if a player has been spawned (1 = spawned), and then set this back to 0 when destroying a player

Is there another way for the server to know that the ghost has been "sent" to the client? This could be possibly a better 3rd solution.

 

This was great thank you