I'm confused about u. I'm trying the move dyaubQ but when I try it out the replaced piece never ends up where I expected it too, on it's original square.
The problem you are running into here is that locust capture of a friendly piece is used by the Diagram for encoding castlings. (As a locust capture by the king of its own rook. That allows indicating both the castling partner and the King destination.) So when the GUI performs the move that you entered, it tries to castle with the captured piece, and would relocate it even when there would not have been a u.) The u modifier is officially defined only for unloading the piece that was captured at the end of the move. (This to side-step the issue what we should unload when multiple pieces are captured.)
I am not sure what you are trying to achieve here. If u would have been defined as unloading the last (or only) victim that was captured during the move, the described move would unload the victim at the square it was captured (and then steps back one square). Are you trying to use this as a method for hopping over (or in this case bouncing back from) friendly pieces only? I guess it would be nice if (say) dyaufQ could be used to describe a Grasshopper that can only hop over friendly pieces, and cyaufQ for only hopping over enemies. I suppose the definition of u could be adapted to always unload the last piece that was captured before it, and if none was captured, the first piece captured after it. (And then exclude that piece from relocation by any following u.) That way you could always slip in as many cau and dau combinations you want, as alternative to pa. I could of course limit the interpretation of friendly locust capture as castling by the GUI to pieces that acually have castling defined as one of their moves.
It seems something else is wrong too, as I have to enter the first leg twice as locust square, before the final destination gets highlighted. This could be a consequence of that unload squares must also be clicked (e.g. the Valkyrie from Odin's Rune Chess allows relocation of the captured piece anywhere along the path of the move, and you will have to indicate where. So with afudQ it first lets you select the (empty) unload square, and then the (friendly) victim at the final destination. So I guess it first prompts you for the locust victim, and then for the unload square. Which is a bit silly when these must be the same according to the move description. I can streamline this, but with end-point victims only this situation was not supposed to occur.
[Edit] I did reserve the castling interpretation of friendly locust capture now for pieces that can castle. This means you can at least now define such moves on other pieces. But of course such captures are not likely to occur in a variant as such, as the players would avoid those like the plague. That becomes different when the piece reappears somewhere else. Problem is that the internal move representation of the GUI only has a single locust square, and it is already used to indicate the locust capture. When it points to an empty square it is interpreted as an unload. Of course an unload on the same square as the capture really is a no-op; it just becomes a simple (hopper) move, and the e.p. square would not have to be set or indicated at all, just as for entering hops you don't have to indicate the mount. So the highlighting function should be changed to treat locust capture + unload on the same square the same as a hop, the only difference being that it tests whether the victim has the right color.
The problem you are running into here is that locust capture of a friendly piece is used by the Diagram for encoding castlings. (As a locust capture by the king of its own rook. That allows indicating both the castling partner and the King destination.) So when the GUI performs the move that you entered, it tries to castle with the captured piece, and would relocate it even when there would not have been a u.) The u modifier is officially defined only for unloading the piece that was captured at the end of the move. (This to side-step the issue what we should unload when multiple pieces are captured.)
I am not sure what you are trying to achieve here. If u would have been defined as unloading the last (or only) victim that was captured during the move, the described move would unload the victim at the square it was captured (and then steps back one square). Are you trying to use this as a method for hopping over (or in this case bouncing back from) friendly pieces only? I guess it would be nice if (say) dyaufQ could be used to describe a Grasshopper that can only hop over friendly pieces, and cyaufQ for only hopping over enemies. I suppose the definition of u could be adapted to always unload the last piece that was captured before it, and if none was captured, the first piece captured after it. (And then exclude that piece from relocation by any following u.) That way you could always slip in as many cau and dau combinations you want, as alternative to pa. I could of course limit the interpretation of friendly locust capture as castling by the GUI to pieces that acually have castling defined as one of their moves.
It seems something else is wrong too, as I have to enter the first leg twice as locust square, before the final destination gets highlighted. This could be a consequence of that unload squares must also be clicked (e.g. the Valkyrie from Odin's Rune Chess allows relocation of the captured piece anywhere along the path of the move, and you will have to indicate where. So with afudQ it first lets you select the (empty) unload square, and then the (friendly) victim at the final destination. So I guess it first prompts you for the locust victim, and then for the unload square. Which is a bit silly when these must be the same according to the move description. I can streamline this, but with end-point victims only this situation was not supposed to occur.
[Edit] I did reserve the castling interpretation of friendly locust capture now for pieces that can castle. This means you can at least now define such moves on other pieces. But of course such captures are not likely to occur in a variant as such, as the players would avoid those like the plague. That becomes different when the piece reappears somewhere else. Problem is that the internal move representation of the GUI only has a single locust square, and it is already used to indicate the locust capture. When it points to an empty square it is interpreted as an unload. Of course an unload on the same square as the capture really is a no-op; it just becomes a simple (hopper) move, and the e.p. square would not have to be set or indicated at all, just as for entering hops you don't have to indicate the mount. So the highlighting function should be changed to treat locust capture + unload on the same square the same as a hop, the only difference being that it tests whether the victim has the right color.