Should be able to interrupt and "splice" actions into action queue

Think about the AI pathing we did for Kraken. What if in the update loop I wanted to have the ship randomly “look back” and then return back to what it was going to do (moveTo).

I should be able to do something like this using action API:

lookbackTimer: number = 500;
update(engine, delta): void {
  if (this.lookbackTimer <= 0) {
    var actions = [
      new RotateBy(...), // look back
      new RotateBy(...)  // return back to original
    };
    this.actionQueue.queueAfterCurrentAction(actions, interrupt: true/false);
  }
  this.lookbackTimer -= delta;
}

Essentially allow me to insert actions into the queue as it’s being processed but also allow me to choose whether I want to wait until the current action is done or interrupt immediately (cancel) and then resume again later. In the case I’m talking about, I’d want to wait until the current rotation/moveTo is done, then lookback, then reverse lookback, then resume action queue. However I could also see interrupting a moveTo (for example in the middle), doing the lookback actions, then resuming the moveTo from where it left off (pause/resume).

[eonarheim]

@LePhil Definitely a bug. I think I know what the problem here is, and I definitely would expect your test case to be true.

Basically actions don’t handle large update values or update boundaries well 😦 before the next action can activate, a frame must elapse. Basically it is only possible for 1 action to complete per frame (update) given the current implementation.

Normally updates fire at 60FPS (every ~16ms) so at run time things “mostly” work although the accumulated error piles up quickly, see codepen https://codepen.io/eonarheim/pen/LOJeQe?editors=0010

Here is a snippet of the ActionQueue update, and it only concerns itself with the current action and if it completes.

With a slightly modified version of your test and excalibur that logs delta and position it’s very clear:

         actor = new ex.Actor(0, 0);
         expect(actor.pos.x).toBe(0); // T = 0
         
         actor.actions.moveBy(100, 0, 100);
         actor.actions.moveBy(200, 0, 100);

         actor.update(engine, 1);
         actor.update(engine, 50);
         actor.update(engine, 1);
         expect(actor.pos.x).toBe(50); // T = 50

         actor.actions.moveBy(300, 0, 100);

         actor.update(engine, 1);
         actor.update(engine, 50);
         actor.update(engine, 1);
         expect(actor.pos.x).toBe(100); // T = 100

         actor.update(engine, 1);
         actor.update(engine, 100);
         actor.update(engine, 1);
         expect(actor.pos.x).toBe(200); // T = 200

         actor.update(engine, 1);
         actor.update(engine, 100);
         actor.update(engine, 1);
         expect(actor.pos.x).toBe(300); // T = 300

Console out:

27 11 2017 18:14:15.810:INFO [HeadlessChrome 0.0.0 (Windows 10 0.0.0)]: Connected on socket _i2DF0JD6Ln_U8vcAAAA with id 24412154
LOG: 'Update (1) ms - Actor pos: (0, 0)'
LOG: 'Update (50) ms - Actor pos: (1, 0)'
LOG: 'Update (1) ms - Actor pos: (51, 0)'
LOG: 'Update (1) ms - Actor pos: (52, 0)'
LOG: 'Update (50) ms - Actor pos: (53, 0)'
LOG: 'Update (1) ms - Actor pos: (103, 0)'
LOG: 'New action q'd'
LOG: 'Update (1) ms - Actor pos: (100, 0)'
LOG: 'Update (100) ms - Actor pos: (101, 0)'
LOG: 'Update (1) ms - Actor pos: (201, 0)'
LOG: 'New action q'd'
LOG: 'Update (1) ms - Actor pos: (200, 0)'
LOG: 'Update (100) ms - Actor pos: (201, 0)'
LOG: 'Update (1) ms - Actor pos: (301, 0)'
LOG: 'New action q'd'
HeadlessChrome 0.0.0 (Windows 10 0.0.0) Action moveBy can move expected over time FAILED
        Expected 52 to be 50.

I think the correct way to fix this is to retool the existing actions api to accurately position actors after updates and calculate the time each action should take.

I have a hack of the moveBy action that seems to work by moving the target actor immediately to the position rather than setting velocity. And it passes the test you provided https://github.com/excaliburjs/Excalibur/tree/bugfix-actionqueue.

[github-actions[bot]]

This issue hasn’t had any recent activity lately and is being marked as stale automatically.