Comments by HGMuller

Link?

Thank you for your kind words. I also count Macadamia Shogi as one of the best variants amongst my designs. But of course almost all the credit for that should come from Maka Dai Dai Shogi having such unique and interesting rules; all I did was throw stuff out...

It appears the missing kanji tiles were never made. And probably for a reason: the tiles representation uses the Chu-Shogi 1-kanji set, and in most cases I would be at a loss what kanji to pick for the missing tiles. E.g. in the case of Free Gold both the kanji for Free and for Gold are already in use (for Free King and Gold General, respectively). I suppose one could argue that a red Gold would do, because there isn't any piece that would promote to a normal Gold General. The 'Tiles-1' set in the Maka Dai Dai Shogi article suffers from the same problem; only the 'Tiles-2' button produces a reasonably complete set of kanji pieces.

What I did now is copy the 2-kanji pieces from the Maka Dai Dai set to the Chu Shogi set, so that we now have a mixed 1-kanji/2-kanji set for Macadamia Shogi there.

The Emperor is still missing in all sets, though. It required 4 kanji to spell the name of this piece, and I could not fit that on the tiles. So I am not sure how I should make one.

I had to pause the work on the C version of the Interactive Diagram due to other pressing business, but I certainly plan to resume it.

I don't think "if turn < 2:" , using < as infix operator is valid GAME code; I would expect something like "if < turn 2:"

I don't think you can do this in the Pre-Game code; I expect turn always to be 0 there, no matter how long the game is already progressing. Every time you submit or request the preset page GC would first execute the Pre-Game section, then the Pre-Move and Post-move sections for every stored move to set up the current position (increasing 'turn' in the process), and finally the Post-Game section. Preparation for the move to come (such as highlighting) should be done in the Post-Game section (where 'turn' will reflect the number of moves played so far).

(Uses Shatranj version, K+G vs. K is mentioned in historical sources)

Note that the historical sources only mention that K + promoted Gold (= Rook) vs K is a win.

The HaChu engine allows Ln x P x Ln if no recapture is possible, which I am convinced is the historic rule. Historic sources give an example that makes it clear the situation after the capture that should be decisive ('hidden protector').

Jocly can handle anything, because basically you have to program the game yoursself in JavaScript. the standard software would not have any problem in displaying pieces that stick out of their square, at least in 3d. You would probably have to rewrite or alter some of the standard routines for chess variants; the easiest approach would be to define a multi-square piece as multiple pieces, one movable, the others just being dragged with it as a side effect.

If you search the betza.txt file he does that himself. I'm not sure why but it works.

Beware that not everything in betza.txt might work. The continuemove that occurs in HandleMove is in a code branch that would try to resolve a remaining ambiguity, e.g. in case the first leg of a multi-move that had just been entered could also be a move in its own right. Most variants don't have such situations, so bugs there would not be quickly discovered.

I notice that the other occurrence of continuemove in betza.txt is actually in GameEnd (i.e. the Post-Game section), and that it is basically a deferred execution there: HandleMove discovers the entered move is incomplete (and could continue in multiple ways), and then sets a variable ok to 2 to relay that information to GameEnd, so it can do the continuemove there. I might have done things in such a round-about way because of what Fergus says.

I am not sure what the problem would be with using continuemove in the Post-Move section. I understand it should only be done after all moves of the game have been executed before invoking it, or the user would be presented a wrong position when prompted for entering the second part of the move. And using it in the Post-Game section guarantees that, as GC only executes that after the Post-Moves of all moves. But the Post-Move after the last move is basically executed together together with Post-Game, with nothing happening in between. So I could very well imaging that things that should not be used during execution of the Post-Move section of earlier moves are harmless in the Post-Move of the last move. (But this is just speculation.)

The HandleMove routine in betza.txt makes this distinction, as for efficiency reasons it only does a proper legality test there, and that is also the point where it would discover the entered move is still ambiguous. So it might get away with invoking continuemove in the part that is only executed for the last move. In that case using it in your Initial routines conditionally (when move 2 is not yet entered) would work too, as this can only happen on the last move of the sequence, just before invoking the Post-Game section; in the stored moves the prelude should always be present as a pair.

Anyway, in the Post-Move 2 for black's initial turn, which will be followed by the normal GameEnd when you are entering black's placement, you could simply do set ok 2 on an incomplete move, so let GameEnd invoke continuemove. After Post-Move 1 your own Post-Game-1 code will be executed. You could also use ok as a signal that the move found in Post-Move 1 was incomplete, and in that case let the Post-Game-1 code highight moves for the second placement, rather than the first, before making it invoke continuemove.

Too bad that can't be done in an Interactive Diagram. :~(

Well, Interactive Diagrams also allow scripting, through supplying a JavaScript xxxTinker routine that would post-process all generated moves. You could also use that to add dragging along dummy neighbors, which would have no moves of their own, or reject moves where this dragged neighbor would collide with something. (Or you might alter the XBetza of the moving partner to make lame detours for guaranteeing the involved squares are empty. E.g. a forward Rook move that should be able to drag along a dummy on the square on the right of it without collisions could be fr(ablabr)ablF.)

In fact, calling it more than once could result in the wrong value for $movenum. So, it makes sense to reserve its use for the Post-Move code.

I suppose you meant to write Post-Game code here?

If a Post-Move code would only use continuemove when it detects the current move is incomplete, it would automatically be called at most once, as all earlier moves in the game should be complete for the game to progress to the current one. Also note that the PTA-automated code is running with the "do not add moves" checkbox ticked, so that Post-Move initially is in fact Pre-Move, and only starts to do post-move processing when the code actually orders the move to be done. From the code you show it seems important to do continuemove after the last move was made (if this was incomplete).

I think the main danger of using continuemove at the termination of Post-Move is that it would not automatically suppress or alter what happens in Post-Game. While it is conceivable you want to use different highlighting for the second part of the move than you would have at the start of a turn, and you would not want the legality test, things that the Post-Game code would normally do.

So the best solution for Aurelian is probably to parse the move (in the prelude) in Post-Move, always perform the first move, then test if the second move was present, also make it if it was, but set variable ok to 2 when it wasn't. The Post-Game code for the prelude could then test the value of ok, and abort after invoking continuemove if it had value 2, possibly after recalculating the highlighting.

Indeed, the counterstrike should be forbidden here.

The Interactive Diagram does implement the counterstrike rule: when you place both Lions in front of an enemy GB, switch on the AI, and play GBxLn, it will not capture the Lion. In the highlighting you won't see it, though, as the I.D. does pseudo-legal highlighting. Moves that expose you to check will also be highlighted. (If it is the King making such moves these are highlighted in grey, but betzaNew.js doesn't even do that anymore. Perhaps one of these days I will subject the highlighted moves to a legality test, and use another highlight symbol for the illegal ones.)

The same test appears to work in Jocly, though. And then it doesn't even highlight the counterstrike GBxLn.

The captureMatrix is not something that should be specified per piece. There is only a single capture matrix, with a row for each attacker piece type. In such a row there should be the event descriptor for every piece it captures (starting with an empty square, i.e. the non-capture).

Fairy-Max communicares through CECP ('WinBoard protocol'), described at https://www.gnu.org/software/xboard/engine-intf.html#5 . It is not really designed for running on the command line.

You get command sequences like

memory 64

level 40 5 0

new

variant capablanca

usermove f2f4

I would think x nand y should produce the same value as nand x y by definition, the only difference being that y (and thus its possible side effects) would not be executed if the value of x already fixes the outcome (i.e equals false).