WB protocol and variant names

[Daniel Shawul]

Ok here are the variant's for alien version the shogi variants have a different name now. Are the names right?

Code: Select all

feature variants="shogi,gorogoro,minishogi,judkins,crazyhouse,atomic,ultima,normal,losalamos,bigchess,courier,capablanca
,gothic,grand,makruk,shatranj,knightmate,berolina,spartan,coordinatorchess,immobilizerchess,withdrawerchess,longleaperch
ess,advancerchess,pushmepullyuschess,omegachess,quadruplechess,triplechess"

The chess version has this

Code: Select all

feature variants="normal,spartan,knightmate,shatranj,makruk,berolina,jetan,grand,gothic,capablanca,courier,suicide,givea
way,wildcastle,nocastle"

Checkers has 'international' instead of '10x10+0_checkers'

Code: Select all

feature variants="checkers,international"

Go, I changed the names as follows. Should I just send one 'go' and let windboard try out many sizes. For internal use I need a name for the variant that is supported, but may be for winboard it is not necessary.

Code: Select all

feature variants="go,go1313,go1919"

[hgm]

Yes, that looks OK. There might currently be problems with names that are substrings of other names, as WinBoard uses strstr on the variants feature parameter to see if the variant name is part of it, without paying attention to the commas. So if an engine plays minishogi, WinBoard might think it also plays shogi. This, however, should be considered a WinBoard bug, and I should fix it.

About Go, wouldn't it be more logical to equate plain 'go' to the 19x19 variant, and write go9x9 and go13x13 for the smaller variants? (I would recommend to use a x between width and height.)

I am not sure if spaces in variant names would currently work, or if they should be made to work. But if the variant name is what will literally appear on the buttons, it might be nice if they were allowed. (So you could use "go 13x13" for better readability.)

[Daniel Shawul]

Most probably because I gave you the wrong game definition. The promotion zone should be the 6th rank. So change the line '2 8 8' to '2 6 6'

[Daniel Shawul]

Ok I have changed the Go variants as you suggested, and also the name of the international variant to 'polish' which I think is the same. I did not put spaces between 'go 13x13' cause nebiyu will probably crash. But if you find that it useful, I will add spaces. You can download it here. It has the fixed losalmos game spec as well.
Let me know when the winboard (not xboard) is ready with the new variant buttons.

[hgm]

OK, I downloaded it. No automatic prefixing seems more versatile, because when prefixing would be desired (e.g. for backward compatibility, to play minishogi against an engine that only knows it as 5x5+5_shogi, one can always write 5x5+5_shogi as the engine-defined name in the Alien.ini file. One can even duplicate the definition there, to have the same game available as 5x5+5_shogi and minishogi. (Admittedly not very elegant, but it would work.)

About your assignment of parent variants:

I noticed that for variants like 'withdrawerchess' you specified 'ultima' as parent variant. But 'ultima' is not a standard WB variant; it is itself played as 'alien', which is only supported in the Alien Edition. Now WinBoard recognizes any text string that does not contain the name of a standard variant as VariantNormal. (A bit weird, but a legacy of the fact that in ICS play the variant is set by parsing the PGN Event tag, which would say something like "ICS wild(23) game", where 'wild(23)' then would be recognized as Crazyhouse.) For normal Chess it would say "ICS game", so that should be recognized as VariantNormal rather than VariantUnknown.

The variants feature of course does not contain such nonsense, so if a name in there parses as VariantNormal I check if it indeed was spelled as "normal", and if not, correct it to VariantUnknown. But when parsing the name of the parent variant from the 'setup' command, VariantUnknown is not an acceptable outcome. So any unimplemented name there would be interpreted as VariantNormal.

Now in the standard edition of WB this is not too much of a problem, because iy could not play withdrawerches anyway, not supporting variant alien and intra-game setup commands. But when you sepcify the parent variant as 'ultima', it would also not work under the Alen Edition. The parent variant really has to be 'alien'.

Another issue:

You defined the parent variant of omegachess as 'alien'. Is this just because of the different promotion zone? With the new highlighting convention, where moves to purple squares are treated as moves into the zone, this would no longer require board updates, as the GUI would be in control of promotion choice to start with. For moves received in text form (from engine or in PGN) promotion suffixes are unconditionally obeyed by WinBoard when legality testing is off, wherever the are on the board. So such variants without weird captures can use 'normal' as parent variant without problems. (But 'alien' would be recognized by the standard edition of WB as 'normal' anyway. So it would only make a difference when you play under the Alien Edition.)

[hgm]

I wonder if you have any ideas about the following:

In the attempt to move all rule knowledge to the engine, the GUI loses the ability to generate and parse SAN. The area where this really hurts is in displaying the engine PV. I don't want to put the burden on engine developers to convert the PV to SAN (which would introduce the new problem for the GUI to play out the PV anyway). But even with a referee engine that would be able to do the conversion (e.g. by responding with a "legal move LONGALGEBRAIC SAN" on any move you feed it), it would cause unacceptable overhead if you had to feed every move of every PV that the playing engine sends you to the referee, and process the 'legal move' replies (and then undo-ing all of them to get back to the game position).

This is a really nasty problem, and I am running a bit out of ideas for it. In truly alien variants playing out the PV on the GUI's variation board is nasty anyway, because it would also require board updates from the referee engine for every move the user steps through. But at least this is only done in response to user request, not for every PV the engine sends.

To ameliorate the problem, one method could be to let the (referee) engine load some rule knowledge into the GUI. E.g. after sending the initial setup command, it could use a "piecetype ID MOVE_DEFINITION" command to the GUI for all non-standard pieces involved in the setup. The move definition could be a list of triples (deltaRank, deltaFile, rightFlags), perhaps extendable with extra fields for secondary step and rights after hopping.

It would be very hard to make this completely general, however. In particular for truly alien variants, with weird capture modes. Jump captures as in Checkers can still easily be generalized, but it is hard for me to imagine a system of describing captures that would handle the other Ultima pieces, for example.

An alternative would be to limit the communication overhead with the referee by introducing a "SAN2long" and "long2SAN" commands that would offer an entire squence of moves on the same line, which the referee would then convert in the requested direction before sending the result back in "SAN" or "long" commands, again as a single line, without changing its game state.

[Daniel Shawul]

I had the parent variants set long time ago without much thinking, and thought ultima was one of the standard variants. I have changed it now so that ultima itself and all its successors have parent 'alien'.
I have also changed the parent of omegachess to normal. I thought the protruding corner squares would be a problem which is why I called it alien. The rest ,i.e. triple/quadruple chess, should still be alien because of many players.

[Daniel Shawul]

In the attempt to move all rule knowledge to the engine, the GUI loses the ability to generate and parse SAN. The area where this really hurts is in displaying the engine PV. I don't want to put the burden on engine developers to convert the PV to SAN (which would introduce the new problem for the GUI to play out the PV anyway). But even with a referee engine that would be able to do the conversion (e.g. by responding with a "legal move LONGALGEBRAIC SAN" on any move you feed it), it would cause unacceptable overhead if you had to feed every move of every PV that the playing engine sends you to the referee, and process the 'legal move' replies (and then undo-ing all of them to get back to the game position).

Well so far I never tried to convert moves to SAN in alien mode, but in ICS games you get both a standard (e2e4) and beautified SAN notation (e4), so I send the former to the referee and the SAN notation to the PGN viewer etc. The referee never gets the SAN at any point but the corresponding e2e4 notation once. Well that works well for ICS because one of the player sends SAN but for your case I think it is better to let Winboard itself because it has already the infrastructure and avoids significant delays as well. The highest load of requests the referee gets is with highlights, the rest are done once every move. The referee can be requested for SAN conversion but I don't think it is portable to many alien variants that don't have SAN representation and also complicates referee's job.

This is a really nasty problem, and I am running a bit out of ideas for it. In truly alien variants playing out the PV on the GUI's variation board is nasty anyway, because it would also require board updates from the referee engine for every move the user steps through. But at least this is only done in response to user request, not for every PV the engine sends.

I handle this differently in alien mode. The referee sends back a setup with the position's FEN which the GUI should store, or an illegal move notification. After that the deal with the referee is off, and the GUI should be able to handle game reviews upto the current move without asking suggestions from the ref. One thing I like about this scheme is that, you can compare two consecutive FEN's and highlight the differences. Note that it works without interpreting the move and asking referee. The user clicks here and there in the PGN, and winboard picks up FEN's it stored for itself and compares previous with current position. Admittedly this can fail when user clicks move 4 and then 10, but it works well overall.

An alternative would be to limit the communication overhead with the referee by introducing a "SAN2long" and "long2SAN" commands that would offer an entire sequence of moves on the same line, which the referee would then convert in the requested direction before sending the result back in "SAN" or "long" commands, again as a single line, without changing its game state.

That will definitely reduce the load if you send one PV line at once but remember the engine could be pondering which starts from a different position, may have illegal moves (which is not much of a problem), etc

This is a really nasty problem, and I am running a bit out of ideas for it. In truly alien variants playing out the PV on the GUI's variation board is nasty anyway, because it would also require board updates from the referee engine for every move the user steps through. But at least this is only done in response to user request, not for every PV the engine sends

I guess there is no escaping the fact that the PV has to go through the referee engine as well. I didn't have Variation window so this was not a problem. If indeed the variation window is necessary, then it may be better to step through move by move instead of a whole PV line. The referee sends with a setup as usual , infact we may extend 'setup' to accomodate a SAN notation for the last move as well. Then winboard should store those future positions (PVs) and play through them when user clicks here and there in the PV. So this becomes similar to the previous way of handling already played moves. In both cases, it is better to reduce the load on the referee if winboard stores positions (sort of like caching) and never request again for information that it already did.


I will think about your other suggestions.

[hgm]

OK, I uploaded a WinBoard beta to http://hgm.nubati.net/WinBoard-4.8beta.zip . This has the engine-defined variant names, a patch to allow blacking out of squares (marked by * in FEN, needed to get a nicer display with Omega Chess), and (hopefully) a fully functional 'promotion on purple'. Especially the latter was a bit tricky, because WinBoard has so many modes to enter promotion moves. With -sweepPromotions false you should get an old-fashioned promotion popup for any move to a purple square. This is not too convenient for engine-defined variants, however, as the standard popup does not contain all piece types, and might mention them by names not usual for the variant. (Like Chancellor for Champion and Archbishop for Wizzard.)

With -sweepPromotions true you can always do a click-click move to a purple square, in which case you can make a non-static click on the to-square to adjust the piece on the to-square to the desired type before you release the mouse button for the to-click. With a static click it should take a default piece, but this is sort of ill-defined in non-standard variants, as it has no idea what the most valuable piece is.

The most tricky to get working was the detour underpromotion, which is normally triggered when you grab a Pawn on 7th rank. Pulling it back before you move it to and release it on the promotion square then can be used to alter the type from the default promotion type. The problem with this mode is that it can only work if you know by the from-square alone that there is going to be a promotion. For standard Pawns on the 7th rank that is indeed the case. But this mode cannot be used for Shogi promotions of other pieces, which only have some promotion move but also many non-promoting moves.

To make it work even for Pawns in response to a purple square (because the zone is different from that of the parent variant) was problematic, because when you pick up the piece there are no highlights yet. So it had to trigger this mode in a delayed fashion, on reception of the highlight command. It will now check the highlights to determine number of promotion moves and other moves, and if all moves are promotion moves it promotes the Pawn (or other piece) you are dragging, so that it will start to cycle through the various choices when it is pulled backwards. When you finally release it on the purple square, it will stay there as the chosen type.

One problem I had was that the purple square is no longer purple at that point. WinBoard also sends hover command to the engine when the mouse pointer enters a purple square (as I did not define separate colors for promotions with and without capture), and as a matter of fact I did test this on a promotion that was also a capture. Nebiyu then sent a highlight command which did color the to-square 'transparent' (T). And of course it still is in that state when you release the mouse button to put the piece on that square, as you must do that before you leave the square again. So I had to introduce a flag that forces promotion without testing the square color, set at the point where it became clear all moves would be promotions (which is needed to trigger this mode in the first place).

Btw, why do you send this transparency FEN. In Ultima you color the victims green, when one hovers above a to-square marked as a capture (in red). So it would be logical to color the promotion square green rather than transparent if you hover over it. Although for replacement capture it is not very useful to indicate the victim at all, as it should be clear to anyone that what was there must disappear (as we cannot stack pieces). Perhaps it would be better to have the engine not respond at all to a hover command for a move that only captures what is on the hover square (and certainly if it captures nothing at all, and the hover command was only sent because you hovered over an empty promotion square).

I guess that when the engine indicates capture victims in green when you hover above the to-square, the GUI could use this info when you release the piece there to perform all 'side-effect captures' even without receiving any board updates. When the engine moves, however, there would be no highlights, so this is probably of little value. And board updates would still be needed for side effects other than removal of pieces.

[Daniel Shawul]

OK, I uploaded a WinBoard beta to http://hgm.nubati.net/WinBoard-4.8beta.zip . This has the engine-defined variant names, a patch to allow blacking out of squares (marked by * in FEN, needed to get a nicer display with Omega Chess)

This is really great. Now almost most of the variants in NebiyuAlien are supported except for those with parent=alien. Here are some issues I observed at playing quick games, more later..
a) When selecting variant the second time, all variant buttons are enabled including those the engine doesn't support. And also it will not change the selected variant no matter which button you check. This happens only after you select a non-standard variant.
b) Omega chess forfeit due to illegal move (a0b3), probably because parent variant is normal.
c) Triple/Quadruple chess boards not displayed right, also Checkers/Reversi/Go not supported yet. This will probably take you a lot of work so just FYI.

With a static click it should take a default piece, but this is sort of ill-defined in non-standard variants, as it has no idea what the most valuable piece is.

For variants with parent != alien, such as losalamos it will much problem to use existing infrastructure for promotion assistance i.e. color highlights to identify promotion and illegal moves. But I think variants with parent=alien are best handled via referee engine. When you implement that you can ask Nebiyu for 'movelist' to get a list of moves at any time, then you can use it to resolve ambiguous moves such as promotions and multiple-legged moves in checkers. Randomly clicking squares on the path will filter out the move list and the last remaining move will be made automatically.

More later...