Compatible with Yixin protocol

[nguyencongminh090]

Protocol

Same as Gomocup protocol, just a little different

INFO timeout_match 10000
INFO time_left 10000
INFO max_node 1000
INFO max_depth 100
INFO time_increment 0
INFO caution_factor 4
INFO thread_num 1
INFO hash_size 2097152 (KB)
INFO pondering 0
INFO checkmate 1
INFO rule 1 # Maybe same with Gomocup
start 15 15

yxboard

The difference between yxboard and board is that the brain is required not to answer yxboard with a move.

yxstop

When the brain receives this command, it should stop thinking
immediately and output its move.

Another protocol such as turn, board, ... is the same as Gomocup protocol

Rule Standard

The first command for choice "Program play as black" usually is

BOARD
DONE

The first command for choice "Program play as black" usually is

BOARD
x, y, z  <--- Same as Gomocup protocol
DONE

After it maybe the same with Piskvork

Swap / Swap2 rule

Some command:

1. yxswap2step2 (Program choose color or add 2 more stones)

Example:

yxboard
12,3,2     
12,4,1
11,4,2
done
yxswap2step2

After it, engine will choose color or add 2 more stones.

1.1. Add 2 more stones:

Engine will return:

MESSAGE SWAP2 MOVE4 8 10
MESSAGE SWAP2 MOVE5 11 4

a) Opponent choose white:

start 15 15
board
10,4,1
12,7,2
13,6,1
8,10,2
11,4,1
10,7,2
done

It mean the manager will send include 3 stones from begin, 2 stones from engine and 1 stones from opponent.

b) Opponent choose black:

board
11,2,2
12,5,1
13,6,2
8,10,1
11,4,2
done

It mean the manager will send include 3 stones from begin, 2 stones from engine.

1.2. Engine choose black:

MESSAGE SWAP2 SWAP1 YES

Then after taht, the manager will send

board
8,5,1
10,5,2
9,7,1
11,7,2
done

then the game continue

1.3. Engine choose white:

MESSAGE SWAP2 SWAP1 NO

Then after that, the manager will send

start 15 15
board
11,2,2
12,2,1
12,4,2
done

and engine return the next move.

2. yxswap2step1 (Program put 3 stones)

MESSAGE SWAP2 MOVE1 3 2
MESSAGE SWAP2 MOVE2 5 5
MESSAGE SWAP2 MOVE3 5 4

The manager will ask the opponent choose color then maybe also send "BOARD" command then continue the game.

Notice:

I notice that Yixin usually send lowercase command

Support analyze mode

MESSAGE REALTIME BEST x,y <---- Show the best move from the current position
MESSAGE REALTIME POS x,y <---- Show the position is analyzing
MESSAGE REALTIME REFRESH <---- Refresh, maybe it mean clear all spot
MESSAGE REALTIME DETAIL ... (print output)

[garry-ut99]

I've seen that AG 5.6.1 supports Yixin protocol, so I've tried to run AG 5.6.1 under YixinGUI ( "protocol": "yixinboard") :

YixinGUI 1.6 (the older one which comes with Yixin):

• will crash to desktop at runtime

YixinGUI 2.1 (the newer one which comes with Rapfi):

• every time a move is put on a board it throws an error:

Received : board
Received : 13,5,2
Move 13,5 is outside of 0x0 board
Answered : ERROR Move 13,5 is outside of 0x0 board
Received : done
Answered : UNKNOWN 'done'
Received : end
AlphaGomoku successfully exits

• other times YixinGUI 2.1+ AG 5.6.1 won't run and will crash to desktop immediately at runtime

• also it doesn't seem to support "unlimited time" mode at (will crash YixinGUI to desktop at runtime),
  which sucks badly as it makes this great engine useless for playing long time games

[MaciejKozarzewski]

Regarding 'ERROR Move 13,5 is outside of 0x0 board" then it is indeed a bug, probably easy to fix.

However for the rest of issues (crashes), are you sure that it is caused by interaction with YixinBoard? Maybe AG just don't work on its own? Try running a selfcheck, by either:

• running AG from command line with --selfcheck option
• running AG normally (double-click on the executable, not via a GUI) and type selfcheck right after it starts.

Both methods will test few potentially problematic parts of code and produce selfcheck.txt file. Attach it here so I can see what went wrong.

[garry-ut99]

However for the rest of issues (crashes), are you sure that it is caused by interaction with YixinBoard?
Maybe AG just don't work on its own?

• running AG exe standalone without problems, never crashes
• running trought YixinGUI 2.1 is random: one time crashing, the other time not crashing,
  when crashing, there is a possibility to debug and it creates dump files: Yixin.exe.12548.dmp.zip

[MaciejKozarzewski]

I'm able to reproduce the problem. To me it looks like YixinBoard launches AG process then starts sending commands, but until AG actually starts processing input from std::cin there are a lot of commands that have been lost and never got to the engine. I'm not sure what I can do about it right now.

[MaciejKozarzewski]

All right, I think I solved the problem(s):

• YixinBoard and AG use different versions of zlib, but you need to copy them both into the same folder so it couldn't work. Now zlib is linked statically to AG.
• AG forgot to send 'OK' response to 'START' command when using YixinBoard protocol.
• AG was incorrectly responding to 'SHOWFORBID' command with empty list (even though it should never been sent by YixinBoard if the rule is not renju)

Things that are not a bug but still not ok:

• logging to a file is slightly broken because AG creates new logfile per every 'START' command (typically a new game), but YixinBoard sends multiple redundant 'START' commands.
• YixinBoard sends database query commands before each move. AG is now silently ignoring it to not spam the log with 'ERROR' responses.

[nguyencongminh090]

It seems good. But could you also implement message to allow the engine "show" the move is thinking during analyze?
(MESSAGE REALTIME BEST x,y <---- Show the best move from the current position). Thanks

[MaciejKozarzewski]

First of all, AG search algorithm works differently than alpha-beta search in Yixin so I don't have many of the informations (namely POS and REFRESH).
Besides, the current implementation does not allow the search engine to return some message on its own. This would require some workaround.

[garry-ut99]

I've tested the new version, and it finally works in YixinBoard.

I know it's best to use GPU binary, but still worth to report that CPU binary refuses to use more than 1 cpu thread in YixinBoard :

• multiple threads work in Piskvork GUI, or if running via Cmd, or in benchmark mode, but NOT in YixinBoard GUI
• by the way, also "Number of Threads" slider doesn't even appear in YixinBoard GUI, where it does appear in case of Raphi, curious whether the slider can be supported considering this line in README says :
  "search_threads": 1, // number of threads used by the program. This setting can be changed at runtime (depending on protocol).

SCREENSHOOT

__________________ Rapfi __________________ vs _______________ AlphaGomoku

[nguyencongminh090]

I don't know... But I tested AlphaGomoku on YixinBoard of Dblue and it worked (numberOfThread) (checked by watch task manager)

[garry-ut99]

I've checked again and it still refuses to use more than 1 core in YixinBoard 2.1 of Dblue.

[MaciejKozarzewski]

The problem with number of threads was tirvial - a typo in the implementation. I guess @nguyencongminh090 was talking about setting number of threads directly in the config file, which worked but it should also be customizable via YixinBoard.
Note: You still need to add more devices in the configuration file in order to use multiple threads. You should have at least as many elements in the list as the max number of threads you want to use. For example:
"devices": [ { "device": "CPU", "batch_size": 12}, { "device": "CPU", "batch_size": 12}, { "device": "CPU", "batch_size": 12}, { "device": "CPU", "batch_size": 12} ],
will allow up to 4 threads.

Thanks for all findings. In the newest release I think I fixed all of them. I'm not closing this issue in case you'll find other problems or have more suggestions.

[garry-ut99]

MaciejKozarzewski :
I guess nguyencongminh090 was talking about setting number of threads directly in the config file, which worked.
Note: You still need to add more devices in the configuration file in order to use multiple threads. (...)

Nope, I was talking about the same, I already had my config.json file properly adapted for multithreads, (I used --benchmark + --configure to create it so no human error here), and with this same config.json, it uses multiple threads everywhere except in YixinBoard GUI.

Now I've tried to run AG 5.7.1 in YixinBoard GUI with the same config.json from 5.7.0, but as soon as YixinBoard GUI shows up, it closes itself immediately.

Then I've auto-generated a new config.json file in 5.7.1 with --benchmark + --configure , and the YixinBoard GUI doesn't close itself anymore, but still using only 1 core.

Even pasting your example from your above comment into config.json file, altogether with setting "search_threads": 4, still using 1 core.

Attaching the both autogenerated configs : 5.7.0 config.json, 5.7.1 config.json
By the way, if you compare the both autogenerated configs in some compare tool, you will find some differencies : https://www.diffchecker.com/0zqvwRXi/

nguyencongminh090 would you keen to share your config.json so that I can check whether it will make multithreads working for me.

---

EDITED: it seems it's finally fixed in 5.7.1 (and 5.7.0 was bugged).
I'm not sure (I don't remember) how it happened that 5.7.1 was using only 1 core, one of the 2 possibilites :

• either when I run it for the first time, it silently reseted slider from 8 threads position to 1 thread in YixinBoard GUI because default config.json uses only 1 core, then I rerun it with config.file set to 8 threads, but it was still using only 1 core, once I set the slider back to 8 threads manually, and now it works
• or it was at 8 threads all the time but not working, and then when I moved the slider back to 1 and then to 8 again, it works now since then, maybe some glitch with the slider, I'm not sure

[garry-ut99]

I have another idea : some users are novice and don't know how to install AG into YixinBoard GUI :

• find a link to a separate package with YixinBoard GUI...
• a risk they find a wrong/old Yixin, instead of Dblue's one...
• download separate package with YixinBoard GUI Dblue...
• unpack separate package with YixinBoard GUI...
• download AG package...
• unpack AG package into YixinBoardGUI folder...
• overwrite dll files when asked...
• change exe name to engine.exe...
• edit the config file and change protocol from "gomocup" to "yixinboard"...

All that might be too hard for noobs to handle, maybe it would be a good idea, to provide also additional package for them (YixinBoard 2.1 + AG installed), just like Dblue does with Rapfi, so that novice users just unzip on their desktop and run and it works for noobs out of the box.

Additional benefit is that such additional distribution, given how easy is to use for noobs, will make AG more user friendly and thus more popular, and noobs who were limited to use Rapfi-Yixin package will also start using AlphaGomoku-Yixin package.

[MaciejKozarzewski]

Regarding number of threads in 5.7.0:
AG didn't send info about max supported number of threads, in which case YixinBoard assumed 1 and send such setting. But AG does properly respond to this message and overrides whatever you set in the config file. This is why it didn't work.

Regarding easier installation, I understand @garry-ut99 reasoning. But YixinBoard protocol is inconsistent, has no documentation, and in many ways violates the internal logic of AG. I don't want to invest time in implementing more support for it. I'd rather spend this time on writing my own GUI.

[garry-ut99]

I'd rather spend this time on writing my own GUI.

Ok, are you thinking about modifying/adapting YixinBoard, QPiskvork, Piskvork, or building your own GUI from scratch? Building from scratch is investing much time too, isn't any of them suitable/easy for modifying?

[nguyencongminh090]

The idea of Lizzie GUI or Gomocalc seems to be good. I'd like a GUI with can view each branch of move or display winrate in real-time. QPiskvork is not good in analysis because of no option for analysis, just for engine tournaments. Besides that, QPiskvork GUI is not nice. Piskvork is the same as QPiskvork, it doesn't support real-time analysis and unlimited time settings. I think the best one is to create a new GUI from scratch with a modern style and satisfy those needs.

[garry-ut99]

The idea of Lizzie GUI or Gomocalc seems to be good. I'd like a GUI with can view each branch of move or display winrate in real-time.

Yes I forgot about Go GUIs like LizzieGUI, but maybe because they support only GTP protocol, while AlphaGomoku supports only Gomocup/Piskvork protocol, so they are not protocol-compatible, if it's not a problem, to make them protocol-compatible, then choosing LizzieGUI can be a good idea.

Piskvork / QPiskvork is not good

At least they "are good" because they already support the same protocol AlphaGomoku uses,
while LizzieGUI you've mentioned "is not good" because it isn't protocol-compatible with AlphaGomoku,
Protocols can be implemented, but the features you've mentioned are missing, can be implemented either.
You seem to have forgotten about a fact we are speaking about modifying a GUI, or even building from scratch, not about simply using/choosing a GUI. Depends on what is really useful and what is easier to implement.
But if GTP protocol is better for analysis for AG, and easier to implement, then we can go with LizzieGUI.

QPiskvork (...) because of no option for analysis, just for engine tournaments.

I know, it doesn't even support engine tournaments, only engine matches, which I already mention here : #8 (comment)

Besides that, QPiskvork GUI is not nice.

Given a fact it uses the same bitmaps like Piskvork, and looks same like Piskvork, you're basically saying that Piskvork doesn't look nice either, or maybe because the default selected bitmap in QPiskvork is different than in Piskvork, maybe try to change skins, some skins look better than others, also you can always create your own custom bitmaps/skins. For me Q or Piskvork doesn't look neither bad nor good, it's more a matter of choosing or creating a good skin.

[nguyencongminh090]

No, I didn't mean we will make AG to run on LizzieGUI but create a GUI with same function there, still use Gomocup protocol.

I think the best one is to create a new GUI from scratch with a modern style and satisfy those needs.

I'm not saying about reuse a possible GUI. If choosing Piskvork, and make it able to analysis, then it seems need to change a lot of part and GUI, not only add function.

QPiskvork is not nice

I remembered that the pixel image of the board has a low resolution. And duplicate line after each move. the author seems divided each part of pieces.bmp of piskvork by slice only. Piskvork GUI is okay, it's easy to create a bitmap and import to piskvork. But anyway, choosing Piskvork or QPiskvork are same (about function), I still prefer Piskvork.

You can take a look at Piskvork (modified by my friend)

[garry-ut99]

No, I didn't mean we will make AG to run on LizzieGUI but create a GUI with same function there, still use Gomocup protocol.

I think the best one is to create a new GUI from scratch with a modern style and satisfy those needs.

I'm not saying about reuse a possible GUI.

I know that you meant to build from scratch, but when I mentioned about adapting/modifying (not building from scratch), it was just my separate alternative proposition to your proposition.

If choosing Piskvork, and make it able to analysis, then it seems need to change a lot of part and GUI, not only add function.

My reasoning was that actually I was thinking that building from scratch requires more work/time than adapting/modifying something which already exist, like I already said :

Building from scratch is investing much time too, isn't any of them suitable/easy for modifying?

Because I was thinking that buliding a car from scratch requires more work/time than adapting an already existing car to a new engine, or already existing engine to a new car, but I'm not sure about it, so if it turns out that it's easier/faster to build GUI from scratch than to convert/adapt it, then I'm fine with it.

---

QPiskvork is not nice

I remembered that the pixel image of the board has a low resolution. And duplicate line after each move. the author seems divided each part of pieces.bmp of piskvork by slice only.

I didn't notice it for the first time, but I've looked now again and indeed, board and pieces are pixelisated,
then I've noticed that the default grid size in QPiskvork is 36, but HGarden2 skin bitmap's default size in Piskvork is 32, so I have changed grid size from 36 to 32 but still pixelisated, then have changed to 26 and still pixelisated.
It seems bitmap rendering in QPiskvork is broken somehow, I've reported it on QPiskvork bug tracker.

[nguyencongminh090]

I think about time consume problem will depend on the purpose and target of the program. If it require to change a lot of from original then it's better to write a new one from scratch. And anyway, I'm here just to give some suggestion, I can't decide the product because I'm not author so of course I just mention about idea only. I understand your opinion as well, but thinking again and make a small analysis about Yixin and Piskvork. Currently, Yixin is the most suitable and able to develope more. The only problem appears is protocol to connect/ communicate between engine and GUI. Analyze code may help but will cost a time. Another reason is Yixin GUI was too old (about design), some modern application recently such as Lizzie seems nicer (Of course, this is just a small factor that we don't need to be serious). At this time, Yixin still good with it first purpose so keep using is no problem. My ideas about function are above, what is your idea about function that you want to add? (include modify or from scratch)