Get stuck in boardsize 9 or 13

[HackYardo]

• New boardsize 27, 29 work fine except switch from 19 with openbook on.
• And 9, 13 get stuck.

[aki65]

Yes, indeed, that's a bug that crept in with the new board sizes. I will fix it. Thanks for reporting.

[aki65]

I have fixed this in version 1.17.0 (just released)

[HackYardo]

Thank you very much! 👍 👍 👍 Off topic: How does BadukAI jump between two positions? Step along the sgf game tree? It takes a bit time to jump, perhaps BadukAI can memory positions so that:

instead of: current position -> step alone sgf game tree (moves' history) -> target position
use: current position -> positions' history -> target position

or via gtp engine: current position -> send sgf game tree to engine -> get target position by showboard command # every bots' showboard outputs are different, it would be a disaster 😱

[aki65]

Yes, BadukAI steps along the game tree (because that's the simplest way for some tasks, for example keeping track of prisoners). But it's indeed quite inefficient, so there is definitely room for optimization along the lines you suggest. I will work on this ...

[aki65]

Optimization is now included in version 1.18

[HackYardo]

• AWESOME!

• How could it be? Step along a positions' tree structure or save/load positions' history? I know many Go GUIs use tree structure to jump between two positions.

• However, if I do it, I will use a third way: write a sgf -> send the sgf to GTP engine via loadsgf -> return a position via showboard. I'm not a pro in coding, so I choose the special third way. Will this way work at your first glance?

[aki65]

I let the GUI step through the tree structure as before, as it makes things easy and it didn't prove computationally expensive.

The time-consuming part was transmitting each single move to the engine via GTP (which requires an acknowledge for every single move). So I don't do this anymore. Instead, when the target position has been reached, the GUI (which is keeping track of all moves), constructs an sgf with the linear sequence from start to the current position and sends it to the engine via "loadsgf" (just as you propose ... returning the position via "showboard" is not even necessary, because the GUI knows the position anyway ... at least in BadukAI).

[HackYardo]

Oh, perhaps I understand your sentences. A GTP engine has to synchronize current position with a GUI, e.g. KataGo synchronizes with Sabaki.

• Sabaki sends many play/undo commands to KataGo to implement this, the same as how BadukAI ever does.
• Now, BadukAI send one loadsgf command to KataGo to implement this.

Isn't it?

• Here, the paradigm is: GTP engine follows GUI.
• While in VastGo, a Go GUI I code, it is: GUI follows GTP engine. The reason why I use the special paradigm is: KataGo has already implemented many Go rulesets, it is a bit redundant to implement Go rules again.
• And in such way, VastGo only needs to record vertex and captures in every turn.

The last question I want to ask: Is it possible to implement a SGF generator without tree structure? (In a Go game, every node is a data, while in tree structure every node is a sub structure, so it is weird to use tree structure...)

[aki65]

Yes.

If the data per node includes links to possible successor nodes, then you can always "interpret" the node as a subtree (by following the links recursively) if you need to.