It appears that trajectories that go temporarily off board (the XBetza o mode) are not yet implemented in the GAME code. And the Advancer is defined through such a trajectory, as a multi-leg move that first overshoots its destination by one step, and then takes that step back. This as part of the test that there is no enemy there that should be removed; empty squares, friendly pieces and the step going off board would all be OK; they are not enemy pieces. But the GAME code does not implement the off-board case, so the furthest destination of an Advancer move that hits the edge would not be considered valid, as there is no room for the extra back-and-forth.
In the context of the Interactive Diagram this was easy, as squares are specified by coordinates, which automatically describe an infinite plane. In the context of GAME code this is a bit harder, as squares are specified by arbitrary labels, and there are no labels for 'virtual locations' beyond the board. So there is no instruction for stepping back onto the board, because there is no way to specify from where you should step back.
This means I can not literally translate the JavaScript code of the ID that handles this to GAME code, in order to fix the problem. A work-around would be to have the GAME code process the step-off, step-on legs at the end of the Advancer move as a pair instead of one by one: if it sees that the first of these allows o mode, and would stray off board, it should not try to make the step, but look ahead one leg, combine the two steps (which then should lead to an on-board square), and take that to continue.
This is not a trivial fix, so I will think more about it when I return from shopping.
[Edit] OK, I made a temporary fix, which allows you to fully use the Advancer: I made the betza.txt include file assume that any attempt to step off board by a move with o-mode would be the first leg of a back-and-forth step at the end of the move, and approve the move to the start square of that leg. This obviously would not work for cases where the move travels further, such as a reflecting Bishop.
It appears that trajectories that go temporarily off board (the XBetza o mode) are not yet implemented in the GAME code. And the Advancer is defined through such a trajectory, as a multi-leg move that first overshoots its destination by one step, and then takes that step back. This as part of the test that there is no enemy there that should be removed; empty squares, friendly pieces and the step going off board would all be OK; they are not enemy pieces. But the GAME code does not implement the off-board case, so the furthest destination of an Advancer move that hits the edge would not be considered valid, as there is no room for the extra back-and-forth.
In the context of the Interactive Diagram this was easy, as squares are specified by coordinates, which automatically describe an infinite plane. In the context of GAME code this is a bit harder, as squares are specified by arbitrary labels, and there are no labels for 'virtual locations' beyond the board. So there is no instruction for stepping back onto the board, because there is no way to specify from where you should step back.
This means I can not literally translate the JavaScript code of the ID that handles this to GAME code, in order to fix the problem. A work-around would be to have the GAME code process the step-off, step-on legs at the end of the Advancer move as a pair instead of one by one: if it sees that the first of these allows o mode, and would stray off board, it should not try to make the step, but look ahead one leg, combine the two steps (which then should lead to an on-board square), and take that to continue.
This is not a trivial fix, so I will think more about it when I return from shopping.
[Edit] OK, I made a temporary fix, which allows you to fully use the Advancer: I made the betza.txt include file assume that any attempt to step off board by a move with o-mode would be the first leg of a back-and-forth step at the end of the move, and approve the move to the start square of that leg. This obviously would not work for cases where the move travels further, such as a reflecting Bishop.