ExecuteCommand and non serial code

Options
I noticed with the command architecture that the ExecuteCommand function expects you to interpret the input and ultimately fill in the result in the same function.

Is there a way to defer the sending of the results? The issue is that certain systems/design patterns, in this case the

Kinematic Character Controller
https://assetstore.unity.com/packages/tools/physics/kinematic-character-controller-99131

Updates as a batch. It can't really be executed serially like the built in unity character controller operates. That means the ExecuteCommand on the server can't resolve the result of that input within the context of that function call.

If there isn't a way to handle the command results in a slightly more asynchronous manner, such as sending the result later in the frame, then I effectively can't use the command system for server authoritative movement, or I can't use the Kinematic Character Controller system. That would be unacceptable to me, so I'm looking for alternatives.

How much built in functionality do I effectively lose from the server authoritative movement capabilities of bolt if I just sent the input through a separate event and the results?

I'm thinking if I move the input aspect of the player input command to an event, I can send it to Bolt.GlobalTargets.OnlyServer, and then the server can set it as an input and then after the Kinematic controller system updates, send out the results to the clients with Bolt.GlobalTargets.AllClients.

Comments

  • JeremyS
    Options
    After some more reading, it appears that not using the command pipeline would effectively cut me off from one of the biggest benefits of Bolt, which is the predictable server authoritative pipeline, which I obviously prefer not to do.

    The question is, is there a way to utilize the command pipeline in a way that the result of ExecuteCommand can be filled in later in the frame, and not inside ExecuteCommand?
  • stanchion
    Options
    Anything you use whether its character, kinematic motion, or physics based needs to be "steppable" so you can catch up to the present once you receive a correction from the server
    KCC guide: https://docs.google.com/document/d/1oHUoyblHA45qJ8-4OyL9IDItOvvoQT59pAfC0r4-kQc/edit
  • JeremyS
    Options
    Excellent, thanks