WinBoard, exotic version

[Daniel Shawul]

The crash was due to buffer problem like the fen copying one.
So I sent them separately and that worked. But the previous variants
are overwritten so this is not a solution.

Edit: There are many non-conformants things in shogi like my FEN has enpassant and castling status etc, so I have to fix that.
So it is better to wrap this up here. I will work on it in time.
I think you can make the installer package with what we already have.

[Daniel Shawul]

The record number of moves found so far is 530. These positions will never occur in games. During games, I have a move list of 128 moves. Even with all edge and corner squares covered with kings, the number of legal moves cannot exceed this.

Duplicate checking is very easy and cheap.

When you have finished a particular capture, you add it to the move list. If the current move list has 2 or more elements, and if the number of captured pieces of the current capture is 4 or more (and this is a very strong pre-condition), then you simply do a linear search over the move stack and check whether the last move is unique. In my program I simply call an STL find routine:

Code:

// specialization for move generation without duplicate capture checking
bool tree::node::non_unique_top(const Stack& stack, Int2Type<true>)
{
return std::find(stack.begin(), stack.end(), top(stack)) != (stack.end() - 1);
}


If this function returns <true>, then I simply pop() the move stack (i.e. decrement the counter of the move stack) and the duplicate is removed. During profiling, this never exceeds 0.1% of total resources.

Thanks. I will try to do it atleast to check if my perft is really correct. In the search there shouldn't be any overhead because of hash table hit for the duplicate move.

[hgm]

...
But it keeps crashing.

This is probably a buffer-size problem again. I will look into it. (It seems that what you send is unnecessarily long, though. There is no need to send 10x8+0_gothic if you already sent gothic.)

Btw it seems that the "variant alien" is not needed anymore. You call it "variant fairy" right?

Wrong! Variant fairy is a normal Chess variant, which only has replacement capture. It does not allow board updating during the game with setup commands. (But it does allow the first engine to specify the initial position, like in any variant, actually, when legality testing is off.) The only thing that makes it special is that the name does not refer to a strictly specified variant, but to a class of games.

To allow board updating after each move, you need to use variant alien (which also gives you multi-move capability).

But alien shares with fairy (or multi) that it is not a name associated with any particular game. So it would not be illogical if the Engine Settings menu contained a further specification of what you will actually get when you dial 'alien'. Neiyu now has only a single combobox, but it could have several, like "alien selects:", "fairy selects:", "multi selects". In principle you could do that for any variant, but it might be a bit confusing to the user if, say, "xiangqi" would select something completely different from Xiangqi.

You could also have an option "checkers selects", to choose between 8x8 Checkers and 10x10 International draughts. The protocol now grants the engine enough power that the engine can be told what it means, and that it then enforces this on the GUI. But there has always been the alternative to let the user specify the board size in the New Variant dialog (orthrough command-line options), so that the GUI forces the desired board size on the engine, by sending it "variant 10x10+0_checkers" in stead of "variant checkers".

I was sending 9x9+7_alien, 8x8+5_alien etc... just to tell it which board size it supports. May be I should attach this to the above string too just incase winboard rejects the variant.

Well, this is only important if you let the user specify a non-standard board size in the new Variant dialog. Because in that case, WB will check specifically if the engine supports, say, "10x10+0_checkers", (by looking for that string n the variants feature) rather than just "checkers". If you have told the engine that "checkers" means 10x10+0_checkers through the backdoor of the Engine Settings dialog, WB initially will not know you will be playing a 10x10 game, and just sends "checkers" to the engine,after having checked that the engine supports plain "checkers". Only when it receives the "setup" in reply, it will be switched to 10x10 mode.

I changed Nebiyu to get the holding space size from alien.ini. So this can
be specified when there are no holdings in the game.
I changed to 10x10+2_grand but winboard rejects it in the normal version.

Oops, I guess it has to be 10x10+7_grand. But I am not sure what WB reject. The 10x10+7 should be in the setup command that also carries the pieceToChar table, and WB is not supposed to ever reject that.

[hgm]

OK, I made a first draft of the installer. It can be downloaded from

http://hgm.nubati.net/WinBoard-Nebiyu.exe .

It is intended for installation in the same base folder as where people install their normal WinBoard. To make this possible I renamed winboard.exe to WB-alien.exe, and have it use a WB-alien.ini as master ini file (rather than winboard.ini). It still loads from winboard.ini, and any redirected user ini file from there. It just doesn't write settings back there, but uses its own ini, so that it shouldn't disturb the operation of a normal WinBoard with unknown options.

I have it create an "Alien Engines" group in the WinBoard menu group, where there is an entry for each Nebiyu variant.

Please check if the copyright notice for Nebiyu is OK; I could not find any, so I stole the one from Scorpio.

I guess I forgot to put in a Dark Chess engine. I will fix that tomorrow.

[hgm]

OK, I uploaded a new version of the installer. It now includes a Dark Chess engine, and a menu item for it. I changed the name of the menu group from "Alien Engines" to "Other Games"; that seemed a little clearer.

I put the copyright notice for Nebiyu now in a separate file in its own folder, and just refer to it in the license page of the installer.

[hgm]

I found a problem in NebiyuAlien for Ultima. It seems that it allows a Chameleon mimicking a long leaper to capture only when they land directly behind the piece they leap over. They are allowed to land further on the ray, but then the piece they jump over will not disappear. The markers are consistent with this: only the square behind the victim is red.

e.g.

c1x1kxli/pp1ppppp/1w6/8/1P1P1l2/8/P1P2PPP/ILXKWXLC w - - 1 4
[d]r1b1kbnr/pp1ppppp/1q6/8/1P1P1n2/8/P1P2PPP/RNBKQBNR w - - 1 4

g5=red, but h6=yellow

Another remark: the way you highlight long-leaper captures is a bit inconsistent with other Ultima captures. You already mark the victims green when picking up the piece. In itself there is nothing against that, but now you let the green markers disappear (together with the yellow) when you hover over a red square.

This is hiding information when there is a multiple capture possible. Say La1 with victims on a3 and a5. The a3 and a5 are highlighted in green, and a4, a6-a8 are red. But there is nothing that tells the user that moving to a4 will only capture a3, and not a5. So it would be better to highlight just a3 in green when you hover over a4, and a3+a5 when you hover over a6-8.

The situation is a bit different than in Checkers, where you would always have to take both.

[Daniel Shawul]

Thanks for preparing the installer. I see it can take a lot of time.
Copyright and Logo are all fine.

I think I should somehow make the alien games accessible to the rest of the world because right now it can only play against itself. Not even against fairy-max so that is a priority for me.

I found a problem in NebiyuAlien for Ultima. It seems that it allows a Chameleon mimicking a long leaper to capture only when they land directly behind the piece they leap over. They are allowed to land further on the ray, but then the piece they jump over will not disappear. The markers are consistent with this: only the square behind the victim is red.

Hmm those chameleon problems never go away it seems.. I will fix it.

Another remark: the way you highlight long-leaper captures is a bit inconsistent with other Ultima captures. You already mark the victims green when picking up the piece. In itself there is nothing against that, but now you let the green markers disappear (together with the yellow) when you hover over a red square.

This is hiding information when there is a multiple capture possible. Say La1 with victims on a3 and a5. The a3 and a5 are highlighted in green, and a4, a6-a8 are red. But there is nothing that tells the user that moving to a4 will only capture a3, and not a5. So it would be better to highlight just a3 in green when you hover over a4, and a3+a5 when you hover over a6-8.

The situation is a bit different than in Checkers, where you would always have to take both.

Yes i noticed that too only a red square is displayed when it is about to capture. It can also cause some blinking I think. I should overlap the previous highlight and the new hover highlight of greens I think.

[hgm]

Well, for the other Ultima pieces you mark the 'blast victims' with green during hover, and only show the to-square in red. This is fine. (You could consider marking the to-square with T during hover if there is no victim on it; the only requirement is that it should stay marked legal, i.e. with a capital, in case you release the piece there, but there need not be a visible marker.)

However, you break your own logic when you already mark long-leaper victims in green before you know where the long-leaper will land. Even this is not so bad, but I think you should then at least keep them marked green (or the relevant subset of them) during hover.

Indeed, making the installer was a pain, also because I needed all kind of new icons. And it turns out the Go board cannot be format independent, and really needs separate drawings for 9x9, 13x13 and 19x19. And the bmp files are huge, I hate that. I should equip WB with a new mode to cut out squares from the bitmap, e.g cutting all non-edge squares from the same spot, so that I only have to supply a 3x3 board...

[hgm]

I also found a problem in NebyuCheckers. In the following position

1p1p3p1p/p1p1p1p1p1/1p3p3p/p1p1p1p1p1/9P/10/1P7P/P1P1P1P1P1/1P1P1P1P1P/4P1P1P1 w - - 0 10

(upper-right part):
[d]1p3p1p/p1p1p1p1/3p3p/p1p1p1p1/7P/8/7P/P1P1P1P1 w - - 0 10

it does not accept any move. All 5 black pieces that should be captured are marked green, but the 4 squares I should visit are all marked cyan. No red square! And the first leg of the move is not accepted.

[Rein Halbersma]

I also found a problem in NebyuCheckers. In the following position

1p1p3p1p/p1p1p1p1p1/1p3p3p/p1p1p1p1p1/9P/10/1P7P/P1P1P1P1P1/1P1P1P1P1P/4P1P1P1 w - - 0 10

(upper-right part):
[d]1p3p1p/p1p1p1p1/3p3p/p1p1p1p1/7P/8/7P/P1P1P1P1 w - - 0 10

it does not accept any move. All 5 black pieces that should be captured are marked green, but the 4 squares I should visit are all marked cyan. No red square! And the first leg of the move is not accepted.

In English 8x8 checkers, men cannot capture backwards, so you can only capture 2 men here by h4xd8

If you use the rules of International 10x10 draughts (this variant on an 8x8 board is usually called Brazilian draughts), then you are right and you can capture five men, and in 2 different ways.