FEN hmolvkwgcdx/1e3s3f1/ppprppptppp/3p3p3/11/11/11/3P3P3/PPPTPPPRPPP/1F3S3E1/XDCGWKVLOMH w - 0 1
Now you've lost me. Will sjaakii recognise T or X in the string ?
Have you just created this string or have I been working from the wrong one all this time?
Is there already an X and a T in the Chu string ?
Indeed. Chu uses X for Phoenix ("Archbishop") and T for Tiger ("Nightrider"). But here I use them for Oxcart ("Lance") and Trecherous Fox ("Princess").
I suppose Sjaak will recognize it if in your piece definitions of Oxcart say that it has ID "X", and of Treacherous Fox that it has ID "T". I don't think that there is a restriction in Sjaak on what letters it can use as piece ID.
XBoard has a problem that it cannot use promotion suffixes x and beyond. This because they will cause ambiguity with the capture symbol. So in normal variants the use of X should be avoided, but in Shogi the pieces do never needed to be mentioned by their name, as all promotions are indicated by the suffix '+'.
hgm wrote:Archbishop is used for Phoenix in Chu, which promotes to Queen.
I do read your posts carefully, then go away and 'try' to reproduce what you say happens, or should happen, in practice. But, it often doesn't and this is one more case.
Clearly, in this case, Archbishop promotes to Phoenix.
So, if what you say is 'correct' and, I am using parent chu, why/how can this be happening. It's very confusing to read the manual and then see something else happen.
FEN hmolvkwgcdx/1e3s3f1/ppprppptppp/3p3p3/11/11/11/3P3P3/PPPTPPPRPPP/1F3S3E1/XDCGWKVLOMH w - 0 1
Now you've lost me. Will sjaakii recognise T or X in the string ?
Have you just created this string or have I been working from the wrong one all this time?
Is there already an X and a T in the Chu string ?
Indeed. Chu uses X for Phoenix ("Archbishop") and T for Tiger ("Nightrider"). But here I use them for Oxcart ("Lance") and Trecherous Fox ("Princess").
I suppose Sjaak will recognize it if in your piece definitions of Oxcart say that it has ID "X", and of Treacherous Fox that it has ID "T". I don't think that there is a restriction in Sjaak on what letters it can use as piece ID.
XBoard has a problem that it cannot use promotion suffixes x and beyond. This because they will cause ambiguity with the capture symbol. So in normal variants the use of X should be avoided, but in Shogi the pieces do never needed to be mentioned by their name, as all promotions are indicated by the suffix '+'.
myfish wrote:How far along with washogi is hachu?
It sets up, but won't play either in human/machine or machine/machine ?
It plays human vs engine. It seems I made a typo in the conversion of XBoard piece IDs to internal piece names, however, which prevents loading of a position. And in engine-defined variants the second engine always gets the position loaded that the first gave in its setup command. This prevents Two Machines from working.
myfish wrote:How far along with washogi is hachu?
It sets up, but won't play either in human/machine or machine/machine ?
It plays human vs engine. It seems I made a typo in the conversion of XBoard piece IDs to internal piece names, however, which prevents loading of a position. And in engine-defined variants the second engine always gets the position loaded that the first gave in its setup command. This prevents Two Machines from working.
char fenNames[] = "RV....DKDEFL..DHGB......SMLNKN..FK....BT..VMEWPH..LN"; // pairs of char
I will patch the code.
Yes, in human/hachu interaction, I can move but, hachu's clock simply ticks away yet, it looks like it's processing moves. It didn't move after 4 minutes in one case so I simply assumed something was indeed wrong.
It plays awful, though. Not enough forward drive on its promotable steppers in the end-game.
Evert wrote:It doesn't, but it would be good if it does also for restrictions on where you're allowed to drop pieces.
I think XBoard also doesn't send lift commands if you don't have highlighting switched on, but that could be changed I'm sure.
I would have to check that. But I think there is nothing against requiring highlighting to be switched on in these exotic variants. You could not play Chu without highlighting either (unless you type Lion double moves).
The protocol would have to be extended to specify what to send for holdings pickups. These have no square number, so I guess you would need to send the piece type. Like "lift @P" perhaps.
I would have suggested "P@", but either should work.
I would recommend engines to be reluctant to highlight drops if nothing special is going on, though. Marking every empty square on the board is just distracting. If you want to force promotion on those it would be necessary, though. For normal Shogi it would be best to only use it on Pawn drops.
Makes sense. Either the engine should ignore lift if the board comes out to all empty squares on the board (is that allowed though?), or XBoard needs to suppress highlighting in that case.
I currently take the point of view that promotion of promoted pieces makes no sense, so specifying promotion on them flips them back to their demoted form (applied only to Shogi-like promotions). If we go with a separate character for it, I would vote for '-' over '=', otherwise it could be confusing (you might expect '=' to mean deferral of demotion in that case). Plus, I filter out the '=' as optional before matching the move string to make life easier for myself.
Well, - is out of the question, because it is used a connector in some move formats, like Pe3-e4, Lnxc3-d2, and would cause ambiguity.
Unless there's a format that has "-" as a last character I don't see how it's ambiguous. Sjaak understands SAN and two forms of LAN ({from}{to}{promotion} and {piece}{from}-{to}{promotion}) and I don't think it gets confused by this.
hgm wrote:It plays awful, though. Not enough forward drive on its promotable steppers in the end-game.
I'm not sure Sjaak would fare any better. It has an evaluation term for pushing "pawns" but whether those pieces would be considered "pawns" is another matter.
hgm wrote:Archbishop is used for Phoenix in Chu, which promotes to Queen.
I do read your posts carefully, then go away and 'try' to reproduce what you say happens, or should happen, in practice. But, it often doesn't and this is one more case.
Well, the confusion here is that White/BlackPhoenix.svg aren't actually the images used for a Phoenix, but for a promoted Phoenix. Which is game-technically a Queen. (But in kanji representations does not use the image for a Queen, but for a +Ph.) Same with Kirin. These are images not present in the default theme, where they are replaced by the 'backups' Queen and Lion (and Prince by King).
In a special theme you of course don't mind what it promotes to; iven if it had promoted to DirtyHarry then you would just have made a DirtyHarry.svg file that contained the same kanji as Queen.svg, but in red. But in the default theme it is convenient that +Ph (and in the Wa case +SO) uses the same Glyph as Ln (Wa: CE), and not a completely different one.
myfish wrote:Yes, in human/hachu interaction, I can move but, hachu's clock simply ticks away yet, it looks like it's processing moves. It didn't move after 4 minutes in one case so I simply assumed something was indeed wrong.
That is strange. When I move (after starting XBoard with HaChu, and selecting washogi from the New Variant menu), it starts to produce Thinking Output immediately, and moves after a few seconds. I have set it for 40 moves/min, though.
Evert wrote:I'm not sure Sjaak would fare any better. It has an evaluation term for pushing "pawns" but whether those pieces would be considered "pawns" is another matter.
Well, it is a known defect of HaChu also in Chu, and it is on my to-do list to fix it (but I have not really worked on HaChu for a year now). The problem is that HaChu does have opening/end-game piece values (very important with promoting sliders), but it does not have separate Piece-Square tables for opening and end-game. It really needs to use end-game tables that push more aggressively for promoting its steppers. I guess this should depend on the promotion gain, however; in Wa some promotions add next to nothing (like 1 extra move). I don't want every piece to have its own PST in HaChu (which is intended to handle hundreds of piece types on 25x25 boards), but I could afford having 3 different stepper end-game tables for poor, medium and strong promotion. The latter would be something like Gold -> Rook or Side Mover -> Free Boar in Chu, and Owl -> Eagle in Wa. Medium would be Copper -> Side Mover and Silver -> Vertical Mover in Chu. Not entirely sure how to classify Pawn -> Gold. Gold isn't all that strong, but the Pawn is almost completely worthless, so it still is a reasonable gain. Perhaps the Pawns need separate treatment anyway (depending on whether they are passers?). I guess the concept of 'passer' is usuful for 1d sliders like Lances too. More P + L + RC in one file as the opponent has basically creates a passer-like situation.
