Search Unity

Feedback Why force Predicted for Auto Command Target?

Discussion in 'NetCode for ECS' started by Jawsarn, Jan 16, 2023.

  1. Jawsarn

    Jawsarn

    Joined:
    Jan 12, 2017
    Posts:
    245
    Setting it up manually I can have the entity marked as Interpolated, so why is this restriction here?
    I think in many setups you send the commands to a client which relays the inputs to the controlled avatar, the client entity does not need to be predicted afaik here?
     
  2. NikiWalker

    NikiWalker

    Unity Technologies

    Joined:
    May 18, 2021
    Posts:
    315
    Hey Jawsarn,

    Apologies, can you clarify exactly what you mean? Are you saying:
    • That you can manually point the `CommandTargetComponent` to an Interpolated entity?
    • And that this setup works? Or doesn't work?
    • And therefore: You would like `AutoCommandTarget` to work for Interpolated entities?
    • Are you running into any errors or bugs?
    If possible, could you also describe your use-case for interpolated, controllable ghost entities, please?
    Cheers!
     
  3. Jawsarn

    Jawsarn

    Joined:
    Jan 12, 2017
    Posts:
    245
    For sure.

    Yes. In my previous setup where I was not using the IInputComponentData and "Support Auto Command Target" feature I could assign with the CommandTargetComponent to my Client entity which was marked as interpolated.

    Using the "Support Auto Command Target" feature does not support keeping the client entity interpolated. See reference:
    https://docs.unity3d.com/Packages/com.unity.netcode@1.0/manual/command-stream.html
    Firstly I don't see why it is "obvious" that it needs to be marked predicted since this worked fine when it was not predicted when doing it manually, as a side to me this also sound a bit condesending to have in a manual.
    The entity that is controlled is the avatar entity and not the client entity. The client entity is still the one receiving commands as it can trigger actions by input outside the avatar control. The client entity does not need to predict any of its ghost field, I would guess having it marked as predicted causes more overhead - but if it doesn't it wouldn't cause any issues having it marked as predicted from what I can see right now. But it is weird that command stream is connected to how the client runs its simulation.

    Cheers^^
     
    NikiWalker likes this.
  4. timjohansson

    timjohansson

    Unity Technologies

    Joined:
    Jul 13, 2016
    Posts:
    473
    Internally we copy the data back and forth between the IInputComponentData and an internal buffer used for sending and rollbacks. This is done in the prediction loop for the current prediction tick, and we cannot modify interpolated ghosts or ghosts without the simulate tag in the prediction loop.
    Given that I don't see where the client entity would apply the inputs or how you would get the inputs for the correct prediction tick to the avatar if the client entity is interpolated and owns the input. It can't reliably happen it in the prediciton loop since the values on the client entity are not in sync with the prediction tick, which means it will not be the same behavior and timing as the server.

    I assume this worked before because you could access the buffer directly on the client entity? Did you trigger the non-avatar actions in the prediction loop? If so, how did you deal with shouldPredict / WithAll<Simulate> for the client entity?

    Assuming you don't have any systems in the prediction loop operating on the client entity the only difference if you make it predicted is that it would be set to the most recent received values instead of the values at the interpolation time which includes a multiple frame delay between receiving and applying the values. It does not add any measurable overhead as long as there are no prediction systems.

    As a side note, IInputCommandData is designed to allow multiple command streams, which means you could have the inputs stored on the avatar and a separate input type for non-avatar actions on another entity, but that does not really change much related to your question.
     
  5. Jawsarn

    Jawsarn

    Joined:
    Jan 12, 2017
    Posts:
    245
    Thank you for the detailed answer.

    What do you mean with
    I understand the purpose of it not making sense to modify by serialized ghost fields, but I don't see why the command stream is tied to this. Maybe I'm missing some understanding.

    I move the commands from client to avatar in the beginning of my prediction system.

    I do not have such actions yet. But the idea would be the player press space to trigger a spawn of avatar which would be only on the server side and not require prediction for client.

    Good to know!

    As a side this is also a subject I'm interested in as I have controllable objects which I currently composed with avatar input through the client command stream. Does this provide significant overhead to have multiple active at the same time?

    Thank you
     
  6. timjohansson

    timjohansson

    Unity Technologies

    Joined:
    Jul 13, 2016
    Posts:
    473
    I was not talking about the command stream as such, but the IInputCommandData. IInputCommandData holds the inputs for the current tick only, it is not a buffer. In order to make that hold the correct values we need to copy the correct state from the internal command stream buffer to the input component in the prediction loop - which we cannot do unless the entity is predicted. The buffer for holding the IInputCommandData is generated and pretty hard to figure out the name of and access.
    I don't think we have tried the combination of interpolated ghost, auto command target and not using IInputCommandData so I don't know for sure if that works or not.

    Splitting the inputs will add 20 or so bytes per command stream packet send from the client to the server, but not much overhead apart from that.
     
  7. NikiWalker

    NikiWalker

    Unity Technologies

    Joined:
    May 18, 2021
    Posts:
    315
    Interpolated ghosts with Input and AutoCommandTarget is now supported in [1.2.0-pre.4] - 2023-11-28.
    Interpolated ghosts now support IInputComponentData and AutoCommandTarget.
     
    LastNameLeft and Jawsarn like this.