Comments by HGMuller

No. Members can see submissions too, nowadays. You would not be able to see it if you are not signed in. It is not published.

Fairy-Max confirms the given position is mate in 4. It prefers a slightly different line:

d5c3 b1a1 e3c2 a1b1 c2d2 b1c1 c3d1

In general 3-vs-1 end-games are very easy once the bare King is trapped in a corner (say resticted to a1-b1), You just approach with your second piece, and position it for the kill. The 3-vs-1 checkmating applet discusses what the requirement for the pieces is to be able to make that final kill. In this case it is even easier than usual, because the Wazir-Maos are so powerful that there are already checkmate positions that do not even need the white King. (Like the one Fairy-Max ends up in.) These can provide additional threats next to the normal patterns.

The hard part is usually to get the King in that corner.

Yes, HaChu was written by me, and yes, I am in practice the only WinBoard/XBoard developer. PM on WinBoard forum is not really a good way to reach me, as my inbox there is overflowing. TalkChess.com would be a better forum, but for private communication e-mail would be preferable. However, I usually prefer public over private communication; most things that are discussed tend to be useful for others as well.

The mnemonic pieces were indeed conceived from the wish to be able to play these horrendously large games with virtually no learning at all, because 95% of the piece symbols unambiguously indicates its move. So you only have to worry about a hand-full of (often very special and very powerful) pieces, such as Lions, Teaching Kings and Fire Demons.

It is great that you are working on a replacement for the 81Doju Chu-Shogi website. In practice it might be difficult to get the population of that website to migrate to yours, through, no matter how nice it is. Especially the Japanese players. Setting up a new site also means the loss of the database of all games that have been played so far. Perhaps it would have a better chance of success if you would just build a new client for the existing 81Dojo Chu server.

It would be even nicer if instead of a button that shows you the GAME code so that you can copy-paste it, there would be a button 'Create Preset'. Which would send the HTML requests to the server (through AJAX calls) that are needed to open the preset edit page, and deposit the the code there as if the Save button was pressed. This should be technically possible, as the pages are on the same server.

Of course the user should then have to supply the name of the variant, and the name of the settings file first. But there could be text entries for those. The Wizard could in response display the link through which you can edit the created preset. Or perhaps open that preset in edit mode itself, in another browser window. The user would then only have to adapt the settings for the graphics (color, piece theme...).

So, I added some documentation for it in the area you quoted from.

To make sure I understand this: the formal parameters of the function will have to be written at the end of the function, each prefixed with '=', in the order the corresponding actual parameters will appear in the function call? And the function call will then 'eat away' always that number of parameters from the stack, whether they are used or not? So I could write something like

def BadZone == 9 rank #destination =origin =destination =locustsqr =dropsqr =droppedpiece;

to get a function called with 5 parameters, and only testing if the second is on rank 9?

Yes, you did that right; it is supposed to work that way. But I had not implemented setting of e.p. rights by a W* move in the betza.txt include. (Which needs other code than that for setting the rights on a lame leap, which sets them on jumped-over squares rather than visited squares.) In fact I had not implemented the W* at all, yet. The Betza compiler encodes this special case by specifying a range of -1, but the interpreting GAME code should then of course recognize this special case, to recalculate it as the distance of the fromSqr to the board middle. I quickly added the code for that yesterday evening, when I saw you would need it.

I added the code for setting the e.p. squares now, and tested it in the preset you made.

Zone confinement now also works for the highlighting, with the aid of the 'user-supplied' BadZone function. And I have implemented non-final-leg e.p. capture in the betza.txt include file now, so that works too.

Only remaining imperfection is that when an edge capture is mandatory it still highlights other moves.

The highest numbered placeholder should not exceed the number of different placeholders that you use. So, for example, if you use #4 as a placeholder, you should also include #3, #2, and #1.

I have just been waging a battle with this rule. This really is an extremely troublesome property of GAME code; is it really necessary to treat functions so sloppily? I understand that you somehow have to know how many arguments a function call has to delete from the stack. But why does it care if the earlier arguments are actually used to compute the function result? It should be able to just ignore them.

I have an application where I want to make it possible for a user to supply a function that could veto a normally valid pseudo-legal move generated by the library code, e.g. because it lands outside a confinement zone as in Xiangqi, or captures a piece type it should not be able to capture (e.g. the Jianggi Cannon x Cannon ban). To this end the library code has to call that function from some appropriate place, and it passes all the available information about the move to it, because there is no telling what kind of conditions the variant imposes. So it passes origin, destination, optional locust-capture square all to the function. But in individual cases the decision might require one some of the items (e.g. just the destination). It is really inconvenient having to include dummy operations on all the unused arguments. It completely mystifies a function that a user of the library would have to supply (and is bad for efficiency). Currently I work around it by writing something like

def BadZone cond 1 fn Edge #1 join #0 join #2 join #3 #4;

where the entire join club is just there to produce a dummy result that is never used (but cannot even be parenthesized to suppress its evaluation, as then the trick doesn't work anymore).

OK, that should simplify highlighting of legal moves. But the rule that (some) captures are mandatory actually is another global rule that creates a difference between legal and pseudo-legal. In Losers Chess this rule has lower priority than the checking rule, here it seems to have higher priority, even when the checking rule would be employed. Pseudo-legal highlighting will be easy here. It will still require me to put a 'hook' into the general code with which a user can interface his own code for the zone confinement; I will make this a function call that passes the full move (fromSqr, toSqr, locustSqr, dropSqr and droppedPiece), which returns whether the move is pseudo-legal, but for efficiency will only be called when a global flag 'zonal' is set.) Besides confinement, such a user-supplied function can also be used for enforcing restrictions what peiec types can capture each other.

It has been useful to attempt this, because it made me discover that the Diagram code had suffered a regression: the Betza compiler used to flag which pieces are inversion-symmetric, so that the GAME-code generator in the wizard page could draw on this to decide whether separate table entries should be made for white and black pieces. This code had disappeared!

I am now thinking how the general GAME-code in the include file could be enhanced in order to interface with variant-specific code. Rule enforcing is in general easy, as when there are extra global rules that outlaw some pseudo-legal moves, you can just test for compliance to these independently of the normal code (e.g. before you call the latter), and 'die' if they are violated. But legal-move highlighting requires such a compliance test to be called from somewhere deep inside the standard code, after the MakeMove of of every pseudo-legal move. Normally the code only does a check test there, and pushes the moves to the legal list when it doesn't expose the King.

The problem with mandatory capture is that you have to know in advance whether such a capture is possible to judge whether a non-capture (or in this case also a non-mandatory capture). An obvious way to do that would be to first make a list of all moves that are legal ignoring the rule, and then test whether there is a mandatory one amongst these. If there is, all non-mandatory moves should be purged from the list. This could be done entirely after the standard code. If I would know how to revoke a previous setlegal command.

@Fergus - What would be the best way to manipulate the $legalmoves array, if I want to remove some moves that in hindsight must not be highlighted after all? Would the following code work?

set tmp $legalmoves;
setsytem legalmoves array; // clear the legal list
for m #tmp:
  if fn SomeTest #m:
    setlegal m;
  endif;
next;

I have another question about GAME-code syntax. In

if fn F X or B:

would this be read as if( B || F(X) ) or as if( F(B || X) )?

It doesn't matter much in which language they are, as the lettering is too small to read anyway.

What intrigues me, though, is that the left document has the map of Netherlands / Belgium / Luxemburg as a logo (in the colors of the Belgian flag).

Isn't it a bit strange that we rely on (old and disagreeing) western sources, while in this age of the internet it should be easy to get feedback directly from Korean players? Discussing disagreements between Gollon, Murray and Pritchard might be interesting in an article reviewing their books, but mistakes they might have made do not deserve to be mentioned in a rule description of the game. I never mention the 'Murray Lion' in the Chu Shogi article...

The Fairy-Stockfish developer has included Janggi in his engine now, and claims to have received a lot of feedback during its implementation from Korean amateur and pro Janggi players. I believe him. Which means I consider the current rule implementation in Stockfish to be reliable. Notable point in this are:

• Turn passing is always unconditionally allowed, not just when it is forced.
• The Bikjang rule for King facing is not applied in every tournament. If it is not, King facing is legal.
• If it is, but is declined, it has (indeed) no effect on the possibility to win later for either player.
• The point-counting tie breaker is not applied in every tournament.

So there are actually four sub-variants, bepending on application of Bikjang and point-counting rule.

It also seems wrong to describe Bikjang as "the Generals checking each other". Check is an imminent loss because of King capture. There is neither loss or King capture here, just a draw offer that can be accepted or declined. The whole idea that King facing is a check seems to be contamination by Xiangqi concepts.

I think the problem is that no royal is explicitly defined, so that the Eagle is taken to be royal. This somehow tickles a bug in the Diagram, as I run into the JavaScript error message 'aSide' undefined. So it somehow wasn't able to locate the castling partners because of this royalty issue.