Add support for a delay on ClientCommands

[christerk]

We'll need to be able to pause the playing of model updates in order to play audio (for example long distance player movement) and display animations (passes, kick-off results, etc).

I suggest adding a promise based action queue to the CommandHandler, with settings in the ClientCommand for things like simple time delays or a fully asynchronous "wait for animation to complete" type delay.

[SanityResort]

How about defining the animation as part of the command? When the command is processed it triggers an animation/delay at the end if needed. That way the CommandHandler would not need to know about that.

Just an idea, no clue yet if or how that would integrate with the existing command processing as I have not looked at it yet. Would there be any advantages in having the CommandHandler to deal with those?

[christerk]

Well sure, but the animation inevitable takes some time to render, so the CommandHandler must be able to wait for that to complete before starting to do other actions.

I wasn't suggesting the CommandHandler works as an animation orchestrator, but it needs to be able to delay executing commands until an animation (or sound) has completed.

[SanityResort]

So we can't wait synchronously for the animation to complete? Can we have a callback triggered once the animation completes? If neither works then I guess the command needs to know how long it's animation is supposed to render and return that to the handler. But that could still lead to timing issues especially on slower devices.

Or maybe we are just misunderstanding each other ;-)

[christerk]

That's the thing, you use promises as a way to deal with the asynchronous nature of that stuff..

Promises are just cleaner than having callbacks.