H. G. Muller wrote on Thu, Jun 22, 2017 12:56 PM UTC:
Note that the standard way used by GUIs to handle Chess960 castlings is by dragging the King on top of the Rook you want to castle with. Or, in text form, write it as if the King captures its own Rook.
This works fine to distinguish King solo moves from castlings where the King moves to the same square. But it loses the possibility to select between castlings that differ in the location where the King ends, (as you have in Wildebeest Chess). In XBoard I excpanded on the idea by entering such flexible castlings as a multi-leg move including a friendly capture of the Rook. So you start capturing the relevant Rook with the King as firrst leg of the move. But because the move was defined as two-leg, this does not conclude the move entry, but you have indicate the King destination square after that. This still assumes that the Rook destination is fully implied from the other three squares.
Note that the standard way used by GUIs to handle Chess960 castlings is by dragging the King on top of the Rook you want to castle with. Or, in text form, write it as if the King captures its own Rook.
This works fine to distinguish King solo moves from castlings where the King moves to the same square. But it loses the possibility to select between castlings that differ in the location where the King ends, (as you have in Wildebeest Chess). In XBoard I excpanded on the idea by entering such flexible castlings as a multi-leg move including a friendly capture of the Rook. So you start capturing the relevant Rook with the King as firrst leg of the move. But because the move was defined as two-leg, this does not conclude the move entry, but you have indicate the King destination square after that. This still assumes that the Rook destination is fully implied from the other three squares.