The problem is that this has to be done at the moment the move is applied to the board, and (in the AI) will also have to be undone when the move is taken back during thinking ahead. Which is a different moment as when the move is generated, during which a user-supplied Tinker script can be called to judge or modify the moves. Moves are first generated and put in a list before anything is done with them. (And then tried out one by one.)
A Tinker script can suppress generation of the move. (E.g. because the piece the moving Bishop tries to swap has already moved; moved pieces are distingishable from unmoved ones.) But if it wants special things to happen during execution of the move, it would have to specify these in the move encoding. Currently moves are stored as an array of squares to modify, a promotion piece, and (optionally) a drop piece. Where it is understood that the first two squares are origin and destination of the basic move, i.e. the origin is cleared, and the promotion piece (which can be the moving piece itself) will be put in the destination. For any additionally mentioned square it depends on the board occupancy: if an empty square is mentioned, the drop piece will be put there, if an occupied square is mentioned, it will be cleared.
So an e.p. capture (or other locust capture) would mention the e.p. square as third square, a castling would mention the rook's origin and destination as extra squares, and a rook as drop piece. A swap move would repeat the origin as a third square, and mention the original occupant of the destination as a drop piece.
This encoding system does not allow for in-place replacement of a piece by another; they are either deleted or dropped on empty, and the latter can occur on at most a single square. Except for the moved piece; this can promote, even when destination equals origin, and its origin can be repopulated. But here we would have to change the occupants of three squares into three others, swapping two and demoting the third.
The problem is that this has to be done at the moment the move is applied to the board, and (in the AI) will also have to be undone when the move is taken back during thinking ahead. Which is a different moment as when the move is generated, during which a user-supplied Tinker script can be called to judge or modify the moves. Moves are first generated and put in a list before anything is done with them. (And then tried out one by one.)
A Tinker script can suppress generation of the move. (E.g. because the piece the moving Bishop tries to swap has already moved; moved pieces are distingishable from unmoved ones.) But if it wants special things to happen during execution of the move, it would have to specify these in the move encoding. Currently moves are stored as an array of squares to modify, a promotion piece, and (optionally) a drop piece. Where it is understood that the first two squares are origin and destination of the basic move, i.e. the origin is cleared, and the promotion piece (which can be the moving piece itself) will be put in the destination. For any additionally mentioned square it depends on the board occupancy: if an empty square is mentioned, the drop piece will be put there, if an occupied square is mentioned, it will be cleared.
So an e.p. capture (or other locust capture) would mention the e.p. square as third square, a castling would mention the rook's origin and destination as extra squares, and a rook as drop piece. A swap move would repeat the origin as a third square, and mention the original occupant of the destination as a drop piece.
This encoding system does not allow for in-place replacement of a piece by another; they are either deleted or dropped on empty, and the latter can occur on at most a single square. Except for the moved piece; this can promote, even when destination equals origin, and its origin can be repopulated. But here we would have to change the occupants of three squares into three others, swapping two and demoting the third.