SjaakII 1.0 RC1

[myfish]

Nothing is set in stone, see also the edit of my previous post. I just had to make a choice to be able to proceed. We definitely should sync this. This is why I also did not push the Wa-capable HaChu yet.

For sure. However, if you are going to leave the piece names alone for now, pushing the new hachu will help me see what is where and I can make the sjaakii config mirror that.

My working config uses this.

Code: Select all

FEN: "hmocikwaubv/1e3j3f1/ppprpppqppp/3p3p3/11/11/11/3P3P3/PPPQPPPRPPP/1F3J3E1/VBUAWKICOMH w - 0 1"
XBoard pieces:  "P.BRQFEACWMOHIJ..VL.U.+.++.+.++++++++..++.+Kp.brqfeacwmohij..vl.u.+.++.+.++++++++..++.+k"

But I don't know what problems you perceive with using L/+L. OK, the +L uses the Knight image in the default theme.

The problems were likely that I used L and N in the same config.
The point is though, for people that don't know, it shouldn't point to an already utilised or possibly utilised image. It is not alone either.

[hgm]

I juggled the IDs a bit, and the following seems to give the best match with the conventional English names of the Wa pieces:

Code: Select all

pieceToCharTable: "P.C.EVLO.WGHDF.TRSXOM.+.+..+++.+++++..+++++Kp.c.evlo.wghdf.trsxom.+.+..+++.+++++..+++++k"
FEN: "hmolvkwgcdx/1e3s3f1/ppprppptppp/3p3p3/11/11/11/3P3P3/PPPTPPPRPPP/1F3S3E1/XDCGWKVLOMH");

The only cases where I could not use the first letter of one of the name parts are X for Oxcart and L for Flying Cock, as O was already taken for Owl, and C for Crow. (OK, so it is a Lying Cock now! )

I used the variant name "washogi". It would be more in line with the other variant names to call it wa, however. Or perhaps dropless_wa.

I just pushed the version to hgm.nubati.net .

[Evert]

Expect XBoard to complain too if you try to drop G while all you had in hand was N: it doesn't know where the G came from, and it doesn't know to remove the N from holdings.

Hmm, yes. But I guess it is like you say: this is just a drop move that promotes. So it would make sense to also write it as such, e.g. P@c3=G, (P@c3g in LAN), telling XBoard that a Pawn was dropped from the holdings, but appeared on the board as Gold.

Ah, good idea.

Demotion on capture would be a problem, though. Currently XBoard would only properly demote pieces that are defined as + in the pieceToCharTable, and would demote to Pawn what does not fit after that. Crazyhouse depends on the latter behavior. But of course in Crazyhouse the promoted types are configured as ~, so I could make the behavior dependent on that, rather than default. Then the default behavior for non-fitting pieces could be to shogi-demote, even if there was no + for the promoted piece.

I think for this it would be enough to simply not demote the piece at all (promotion is a bit of a misnomer here, pieces just shift back and forth between their two alternate forms): the move options are the same whether you do it or not.

A separate question is how XBoard lets you input a drop/promotion.

There still is the problem that the usual X/+X pairing does not work in Kyoto; P does not promote to +P, there, but to Rook, while Lance promotes to +P there rather than +L, and +P promotes to Lance... That means you will have to assign different XBoard internal piece types to the various pieces, and would need to use external piece images, as the default theme now would look completely non-sensical (e.g. using crossed swords for Pawn, and a the turban for Rook). But they could just be a set of renamed images from other themes.

True, but is there a good reason not to base Kyoto Shogi off 5x5+4_fairy instead? Then you can just tell it to promote to whatever glyph you like.

Anywa, SjaakII (dev version that does cyclic Shogi promotions) sortof plays it with this config (not through XBoard though, since the piece-to-char is not specified):

Code: Select all

Variant: Kyoto Shogi
Board: 5x5
FEN: "pgkst/5/5/5/TSKGP w 0 1"

Piece: King
Move: leap (0,1)|(1,1) 
Symbol: "K", "K,k" 
Flags: royal 

Piece: Pawn 
Symbol: "P", "P,p" 
Move: step N 
Promotion: all, all, "+" 
Optional promotion: empty, empty

Piece: Rook 
Symbol: "+P", "+P,+p" 
Move: slide (H,V) 
Promotion: all, all, "+" 
Optional promotion: empty, empty

Piece: Tokin
Symbol: "T", "T,t" 
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "+" 
Optional promotion: empty, empty

Piece: Lance
Symbol: "+T", "+T,+t"
Move: step 5N
Promotion: all, all, "+"
Optional promotion: empty, empty

Piece: Silver general
Symbol: "S", "S,s"
Move: aleap (0,1)|(1,1)|(1,-1)|(-1,-1)|(-1,1)
Promotion: all, all, "+"
Optional promotion: empty, empty

Piece: Bishop
Symbol: "+S", "+S,+s"
Move: slide (D,A)
Promotion: all, all, "+"
Optional promotion: empty, empty

Piece: Gold general
Symbol: "G", "G,g"
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "+"
Optional promotion: empty, empty

# Define the pieces
Piece: Knight
Symbol: "+G", "+G,+g"
Move: aleap (1,2)|(-1,2)
Promotion: all, all, "+"
Optional promotion: empty, empty

Rule: keep capture, allow drops 
Rule: repeat4 = draw 
Rule: perpetual = loss 

but the move format is messed up. It expects things like "1. Tb2+" (or "a1b2+") but then on the next move you get "2. +Tb4T" (or "b2b4t") rather than +Tb4+. This just needs some special case detection (if a piece with name+X promotes, printhe promotion character as + rather than X), but as I said already it might make more sense to base this on variant fairy rather than shogi.

Perhaps we could do a better jub by using primed characters, like O for Oxcart and O' for Owl, W for Wolf and W! for Wings, etc. But I don't know if Sjaak already supports this in its FEN parser.

It does not.

This is what I figured. And there are enough letters in the alphabet to handle Wa. Just not to always pick one that perfectly corresponds to the name. The English names seem rather liberal translations of the Japanese kanji: the second kanji in Swooping Owl and Strutting Crow is that of 'Mover' (as in 'Angle Mover' for Bishop, Vertical and Side Mover of Chu, Hook Mover of the large variants...) So where the 'Strutting' and 'Swooping' came from is a bit mysterious.

Perhaps there is a naming that more closely follows the English naming, when we abandon the usual meaning for GSCL:

C = Strutting Crow (now A)
G = flying Goose (Copper)
W = Violent Wolf (Gold)
S = Swallow's Wing (now W)
V = Violent Stag (Silver)
L = Flying Cock (now I)
X = Oxcart (Lance)
T = Treacherous Fox (now X)

I sort of dislike when piece IDs do not have their usual meaning, but I also did use S for Pawn, F for Elephant in Tori (and hated it ever since), so it might be better to stay consistent.

I'll get around to supporting the extra punctuation at some point. I'll have to check to see if it would be a lot of work to support. If the change is fairly minor (which it might be, given that I already support +X and X~) I'll fit it in 1.0.

[myfish]

wow, that's some quick work guys, glad this stuff is engaging you both. You did suggest, only make changes that 'push things' LOL

On the pieces, great HGM, I will grab the hachu push and make my sjaakii version and pieces comply with both engines and, xboard.

Might take you 5 minutes, give me a day ...

You see, what confuses is this.

Some taken from the variant.txt of ajaakii and, hgm's published code from the PTCT

Code: Select all

# The default value of the string is "PNBRQFEACWMOHIJGDVLSUKpnbrqfeacwmohijgdvlsuk", where the characters
# represent the following pieces:
#  P=Pawn actual Pawn
#  N=Knight "" Knight
#  B=Bishop "" Bishop
#  R=Rook "" Rook
#  Q=Queen "" Queen
#  F=Ferz  "" Advisor
#  E=Elephant "" Elephant
#  A=Archbishop "" Archbishop
#  C=Chancellor "" Marshall
#  W=Wazir "" Gold
#  M=Man "" Commoner
#  O=Cannon "" Canon
#  H=Nightrider "" Nightrider
#  I=Dragon Horse "" CrownedBishop
#  J=Dragon King "" CrownedRook
#  G= Grasshopper "" Princess
#  D=Elephant
#  V=Falcon "" Hawk
#  L=Lance (or Amazon/Berolina pawn) "" Lance
#  S=Snake "" Cobra
#  U=Unicorn "" Unicorn
#  K=King  "" Lion

This is just the standard string. My point being, when you 'look' for pieces in the 'default folder', what piece ARE you looking for ?

Please, for sanity, please consider using one, or the other, or even BOTH, just not a MIX of the two as it makes no sense to normal humans.

I get arrays, I get that X array relates to Y array or part of a list. I do. What I don't get, is why it's called M = Man yet, you NEVER find MAN in the default folder, it's 'commoner'.

This is repeated multiple times.

What would be very useful, is an image map of PN....etc but, in an image list for mortals.
So, P = PAWN, and show PAWN as an image next to it and so on. Just so we know what piece we are looking for IF you are inclined to edit the pieces to conform to the variant.

In fact, I might do this and, maybe you guys could make such available to people like myself if they ever suggest making pieces.

[hgm]

A separate question is how XBoard lets you input a drop/promotion.

The obvious way would be to let the engine highlight all empty squares in purple. But I don;t think XBoard sends a lift command when you pick up a piece from the holdings. An alternative is to assume any piece can promote on a drop. But this would be annoying when you use the promotion popup rather than sweep promotions, as for any drop it would ask if you wanted to promote. With sweep promotions would be nice, as not promoting could be made default, so it would not disturb other games. And in Kyoto you could do the special mouse-pointer manipulation to force select promotion. I guess that in this case dragging the piece picked up from the oldings towards (or over) the board edge before placing it could be used to promote it.

Of course it would be cleaner to do this only when configured in some way, as you never know how people might accidentally drag stuff. We could allow a new symbol in the pieceToCharTable, say '*', that would mean the same as '+', but indicate that the promoted type is also available during drops.

True, but is there a good reason not to base Kyoto Shogi off 5x5+4_fairy instead? Then you can just tell it to promote to whatever glyph you like.

Indeed, this would have been necessary anyway, because XBoard also does not have a way in Shogi to make +X demote to X. But the problem is not so much understanding text moves, but knowing how to demote captured pieces. It would also be annoying if you had to make a difficult selection from a promotion menu each time you enter a move with the mouse, because XBoard does not know you have no choice. I had planned to solve this by working in sweep promotion mode, and making sure the default is the piece with which you normally pair in case of promotion of other pieces than Pawns, even when the promoted type is not configured as '+'. But in any case it is important that XBoard knows the pairing.

Anywa, SjaakII (dev version that does cyclic Shogi promotions) sortof plays it with this config (not through XBoard though, since the piece-to-char is not specified):
...

If we want to go that way, it would perhaps be best to generalize the meaning of the optional '=' suffix for indicating deferral, to mean demotion when used on an already promoted piece.

I'll get around to supporting the extra punctuation at some point. I'll have to check to see if it would be a lot of work to support. If the change is fairly minor (which it might be, given that I already support +X and X~) I'll fit it in 1.0.

It should actually be much easier than + or ~, as the latter actually mean something, and imply a relation between X and +X. In this case they are just two-character names, with the peculiarity that the second character isn't a letter but punctuation.

[myfish]

OK, hachu built.
Variant washogi loaded.

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 ?

[Evert]

A separate question is how XBoard lets you input a drop/promotion.

The obvious way would be to let the engine highlight all empty squares in purple. But I don;t think XBoard sends a lift command when you pick up a piece from the holdings.

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.

An alternative is to assume any piece can promote on a drop. But this would be annoying when you use the promotion popup rather than sweep promotions, as for any drop it would ask if you wanted to promote. With sweep promotions would be nice, as not promoting could be made default, so it would not disturb other games. And in Kyoto you could do the special mouse-pointer manipulation to force select promotion. I guess that in this case dragging the piece picked up from the oldings towards (or over) the board edge before placing it could be used to promote it.

Of course it would be cleaner to do this only when configured in some way, as you never know how people might accidentally drag stuff. We could allow a new symbol in the pieceToCharTable, say '*', that would mean the same as '+', but indicate that the promoted type is also available during drops.

I would definitely implement this as a feature that has to be activated. I guess '*' in pieceToChar is as good a way to do it as any.

If we want to go that way, it would perhaps be best to generalize the meaning of the optional '=' suffix for indicating deferral, to mean demotion when used on an already promoted piece.

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.

[hgm]

What would be very useful, is an image map of PN....etc but, in an image list for mortals.

Well, I did publish the list earlier (in this thread, I think) of XBoard image names. It was this:

Code: Select all

char *pngPieceNames[] = // must be in same order as internal piece encoding
{ "Pawn", "Knight", "Bishop", "Rook", "Queen", "Advisor", "Elephant", "Archbishop", "Marshall", "Gold", "Commoner",
  "Canon", "Nightrider", "CrownedBishop", "CrownedRook", "Princess", "Chancellor", "Hawk", "Lance", "Cobra", "Unicorn", "Lion",
  "GoldPawn", "HSword", "PromoHorse", "PromoDragon", "Leopard", "PromoSword", "Prince", "Phoenix", "Kylin", "PromoRook", "PromoHSword",
  "Dolphin", "Chancellor", "Unicorn", "Hawk", "Sword", "Princess", "HCrown", "Knight", "Elephant", "PromoBishop", "King",
  "Claw", "GoldKnight", "GoldLance", "GoldSilver", NULL
};

There is one complication, though, which is that we are using parent variant Chu. And Chu in XBoard doesn't use the default image assignment, but shuffles them around to get a better match between pieces and images in the default theme. In the unpromoted series:

Nightrider is replaced by Claw
Chancellor by Sword
Hawk by HSword
Unicorn by Leopard

The promoted series was already designed as optimal for Chu, as no other variant was using it yet. So the order in Chu is:

Code: Select all

"Pawn", "Knight", "Bishop", "Rook", "Queen", "Advisor", "Elephant", "Archbishop", "Marshall", "Gold", "Commoner",
  "Canon", "Claw", "CrownedBishop", "CrownedRook", "Princess", "Sword", "HSword", "Lance", "Cobra", "Leopard", "Lion",
  "GoldPawn", "HSword", "PromoHorse", "PromoDragon", "Leopard", "PromoSword", "Prince", "Phoenix", "Kylin", "PromoRook", "PromoHSword",
  "Dolphin", "Chancellor", "Unicorn", "Hawk", "Sword", "Princess", "HCrown", "Knight", "Elephant", "PromoBishop", "King"

These are the images in order as they would be assigned to the locations in the pieceToCharTable. You see that some are there twice, in particular Knight, HSword, Sword and Princess, with one copy in the N/+N and G/+G slots, which are unused in Chu. (And thus cause no trouble as long as you don't use them in any chu-based variant either.)

So the procedure I followed for Wa in HaChu is that I went through all unpromoted images, to decide what Wa piece I could best represent by that glyph (aware that I would have to virtually use all of them). Like the King, Pawn, Gold, Advisor, Commoner and Lance images for Crane King, Sparrow Pawn, Violent Wolf, Flying Goose, Climbing Monkey and Oxcart, because they are commonly used for King, Pawn, Gold, Silver, Copper, and Lance in other Shogi variants, and these pieces move just like that. And then I used Queen for Cloud Eagle and Princess for Treacherous Fox, because Queen does not promote in Chu (like CE in Wa), and the narrow crown of Princess also happens to be present in a non-promoted and promoted form, and resembles the move pattern of TF rather well.
The Liberated Horse became a Cannon, because it is used in Chu for Reverse Chariot, and the moves are rather similar (and orthogonal, like the XQ Cannon). The Flying Falcon became the CrownedBishop, normally used for DH in Shogi, as it also is an enhanced Bishop, like DH. The Swallow's Wings is the Side Mover of Chu, and can thus also use the HSword, which resembles its move. The Running Rabit is somewhat similar to the Chu Vertical Mover, and a normal Sword seemed to fit such a kind of move well. ArchBishop was used for Swooping Owl because it promotes to Cloud Eagle, for which we use Queen, and Archbishop is used for Phoenix in Chu, which promotes to Queen. For the same reason Strutting Crow became a Bishop (which promotes to PromoHorse in Chu, and the Horse was used to represent Flying Falcon to which Crow promotes. That didn't leave all that many pieces, and I assigned those more or less randomly. (The Climbing Monkey became a Leopard because they are both mammals, the Blind Dog the Claws, because that was Blind Tiger in Chu. That left Elephant for the Flying Cock.)

Hmm, Elephant promotes to King in the default theme, as that has no separate Prince. So perhaps I should still pack another one for that. I hate to pick Rook, though, for something so un-Rook-like. Although the promoted piece (+R) would not be such a poor match. In general it is the promoted pieces that give awful matches now, compared to their Chu meaning: Knights that move like Kings, Lying Crowns that move like Rooks, Bishops that move like Silver, Knight-on-inverted-Rooks that move like Gold... I guess the situation could be improved a little by using the Claw for Flying Cock, as it promotes to the NR-Chimera, which represents Flying Stag in Chu, which again is quite similar in move to +FC in Wa. Then the Dog could be a Rook.

Perhaps I could make other variant-dependent substitutions of pieces not used in Chu (in particular for N/+N) to make a suitable combination of glyphs for BD. (But N would be needed in Dai. So it might be better to just wait unitil I implemented the extra pieces needed for Dai, and then pick a suitable pair out of those...)

[hgm]

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 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.

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.

[myfish]

What would be very useful, is an image map of PN....etc but, in an image list for mortals.

Well, I did publish the list earlier (in this thread, I think) of XBoard image names. It was this:

Code: Select all

char *pngPieceNames[] = // must be in same order as internal piece encoding
{ "Pawn", "Knight", "Bishop", "Rook", "Queen", "Advisor", "Elephant", "Archbishop", "Marshall", "Gold", "Commoner",
  "Canon", "Nightrider", "CrownedBishop", "CrownedRook", "Princess", "Chancellor", "Hawk", "Lance", "Cobra", "Unicorn", "Lion",
  "GoldPawn", "HSword", "PromoHorse", "PromoDragon", "Leopard", "PromoSword", "Prince", "Phoenix", "Kylin", "PromoRook", "PromoHSword",
  "Dolphin", "Chancellor", "Unicorn", "Hawk", "Sword", "Princess", "HCrown", "Knight", "Elephant", "PromoBishop", "King",
  "Claw", "GoldKnight", "GoldLance", "GoldSilver", NULL
};

There is one complication, though, which is that we are using parent variant Chu. And Chu in XBoard doesn't use the default image assignment, but shuffles them around to get a better match between pieces and images in the default theme. In the unpromoted series:

Nightrider is replaced by Claw
Chancellor by Sword
Hawk by HSword
Unicorn by Leopard

Useful indeed, if you know it. Yes, I was using the tables you posted but, you didn't mention the caveat's.

BTW::

How far along with washogi is hachu?
It sets up, but won't play either in human/machine or machine/machine ?