@HG: auto moveing and lift,put,drag

[Daniel Shawul]

I now checked the previous code and handling hover is complex not because Winboard uses a referee that is playing a game. The copy of the search stack have to be updated as legs are made step by step. Keeping the state synchronized with the leg move updates on a separate board is what made it complicated.

I guess reverse entry could be a convention to make this work. Click any number of empty or opponent squares before you click a piece of your own, and it will capture them all with a multi-leg move (i.e. send 'usermove LEG1,LEG2,LEG3,...' to the engine). With an engine that supports 'click' there would be much more flexibility: the GUI could send the individual squares in any order, and keep that up until the engine/referee responds with 'move' (in the mean time performing highlighting as requested). An engine would be aware of the possible ambiguities in move termination, and could apply its own conventions to resolve them (e.g. to terminate entry that might have continued, click the same piece again as last time).

I read that again. The part I don't understand is why the GUI has to keep a list of clicked squares. If a square not shared between the short/long version of the move is clicked, it is clear the longer version will be made. So we are assuming user only clicked shared squares in which case a signal is required. That doesn't necessarily have to be the piece that has to be clicked again but it makes more sense. Clicking any square twice can be used as the signal too I think.

[Daniel Shawul]

I think I have got the solution for the chu-shogi lion move that can be used for many other cases too. When the user clicks on any square that is clicked before, the referee sends ALL the moves that are so far filtered out. Then the GUI displays the moves in a menu for the user to choose from! In this case there will only be two to choose from.That was the method I thought about orignally before the clicks came in i.e sending the move list from which user can select its moves. That was a bit awkward because there could be too many moves as in the case of amazons, but a few clicks after it would be significantly reduced.
AND this method works perfectly for _promotions_ too. User clicks the pawn first, and then clicks it again to get a menu of 4 options, from which he can choose and make the move. The beauty of this is that I don't need extra code for promotions or anything, it works for cases with multiple options we may have not thought about.
If the user prefers to get the menu at any time, all he has to do is click the same square again. And he can do that any time to make moves through the move list. We can still use 'move' command from referee. If it gets two or more moves,it displays a menu instead of making any move.

I think that is one less headache...What do you think ?

[hgm]

Well, I am not so keen on popups.

What is against using a second click on the same square to signal move termination? If I have L on e1 and opponents on d2 and e2, there are moves Lxd2, Lxe2, Lxd2xe2 and Lxe2xd2. After clicking d2, the referee waits, because there still are many possibilities (amongst which 1 and 3). The user can now click e2, which would make the referee realize he wants to play 3, or d2 to choose 1. The challenge is how to do it without referee. But accumulating to-clicks until you click an own piece seems to do it. A second click on the last target you selected during this'spring loading' before you clicked an own piece can act as reset of the entry procedure.

This would work for most games where you only move a single piece. Capture own can be used as a convention for moving multiple pieces (as in FRC castling).

[Daniel Shawul]

Well if the shorter move has variations which does not require clicking another square, then that will not work. For example the shorter move could have promotion options ... Not the case for chu-shogi lion but still may happen in other cases.

We can use a click on the same square to signal the referee to send us a single move i.e the shorter one instead of a move list. But I still like the idea of popups since there is no other way to offer option for promotions pieces. So we need another signal if we reserve clicking on any square again to send a move. Plus the popup could be a faster way of making a move in some cases. So we can still have that I guess.

Btw I changed it to "moves 2 e2e3 e2e4" instead of using teh same command "move" to signal popups.

Edit
I don't think you can get away without using the referee in 'alien' mode. There are just too many exceptions to handle them all in a uniform manner. For example promotions. Shogi for instance has each piece promote to a different piece, that would be too much to handle for the GUI. I think whenever a 'human is about to play, the referee has to be there. Because of that I am going to add referee in FICS play too. Referee is not required in engine-engine or other cases because they will make moves by themselves.

[Engin]

hello Daniel,

one question: can your JavaBoard GUI connect to ICC, FICS or HGM servers and support UCI protocol ?

[Daniel Shawul]

hello Daniel,

one question: can your JavaBoard GUI connect to ICC, FICS or HGM servers and support UCI protocol ?

FICS works especially the PC version. You can use the console mode to connect your engine there and play thousands of games. ICC and HGM servers should work too but I have not tested them. I tried to include only common code for the ICS servers, but I think later I may have added FICS specific code especially for the mobile version. UCI works through polyglot. Maybe some time I will add native support but it is not at the top of todo list.
My major goal is mobile platforms because there are already many GUIs that can do it on the PC.

[Engin]

ok, thx, but on PC there are no existing any GUI that play on ICS with native UCI protocol without an adapter, i don't mean any commercial one like ChessPartner thats support UCI engine and play on ICS server (thats the only one ! ).

So we have only one good choice with the winboard + polyglot adapter, by the way, i dont like to use my engine with an adapter, forget all other GUIs like Arena, Shredder, Fritz, and such ones, because they are all shit works on ICS or did not support ICS never.

[hgm]

Engine can specify promo piece in move it sends, and dumb GUI will obey thay. True problem in large Shogi variants is that there are more piece types thsn letters. (E.g. Taykyoku Shogi has 209 piece types, not counting promotions.) So 2-letter piece names are required. Also gor board files,btw (36x36).

You know engime can already cause popups with reply? (askuser command.)

[Daniel Shawul]

Engine can specify promo piece in move it sends, and dumb GUI will obey thay. True problem in large Shogi variants is that there are more piece types thsn letters. (E.g. Taykyoku Shogi has 209 piece types, not counting promotions.) So 2-letter piece names are required. Also gor board files,btw (36x36).

You know engime can already cause popups with reply? (askuser command.)

I guess I could use 'askuser' instead of 'moves' then. But are you sure that will work for you, because a list has to be displayed of all the moves (or promotion pieces ). It looks like askuser is something suitable for edit box

askuser REPTAG MESSAGE
Here REPTAG is a string containing no whitespace, and MESSAGE consists of any characters, including whitespace, to the end of the line. xboard pops up a question dialog that says MESSAGE and has a typein box. If the user types in "bar", xboard sends "REPTAG bar" to the engine. The user can cancel the dialog and send nothing.

Then the gui sends back the result to the referee, but we need the gui to finish of making the move. But I guess this is not much of a problem. The list of moves however is necessary, otherwise we assume the gui or user knows what to input in the editbox (i.e promotion pieces etc).

I don't know what we can do about the 209 piece types you mentioned. Even all of ASCII is not enough for that, so a double character looks like a better soulution. But we have to get our fen,move,san,epd parsers rewritten...

[Daniel Shawul]

Hi Engin. I checked and it works for ICC and FICS. There was no game to observe from HG's server so I couldn't check. It should work for that and many other servers too. They all follow the same ICS protocol and all that a GUI needs is the positon be sent in style 12 format.

About using an adapter, I think you should not worry too much about loosing time. HG measured the latency for polyglot and found it to be small...
Edit
I use regex pattern matcher a lot to check game start,game end, tells etc... so it can only reliably work for FICS. After observing one game in ICC, it stopped because the pattern for game end is a little different than FICS. I don't know why these things are not included in the protocol...