AI Analysis Bug - move 4 missing

Hi, i don`t know if i missed something but i think the AI omitted move 4 with this variation…

It looks like 4 was at 10 (it was captured by move 7). It’s not so easy to visualise captured stones after new moves on the same location. Do you have a suggestion to improve this?


Ah, yes… of course :sweat_smile: thank you!

Mhmm, what about a solution where two numbers are displayed with a " / "

Like 4/10 … or some indication like red color, and if you hover over it, there is a pup-up?

I think it’s hard to fit, especially when there are multiple replacements like in a ko fight.

In printed diagrams, they usually put replacement notes at the bottom of the diagram or to the side, like here.

1 Like

I think I’ve suggested it at least once, possibly more times, that earlier numbers should appear on the board before later numbers as a priority.

What you’ll find is that when you get to play move 10 in this case is that once it’s on the board it changes it’s number to move 4.

This feels like a bug and I can’t see a way that it’s more useful.


hey I have a similar issue but the stone can’t have been captured because I only played the first 3. interestingly it is also stone 4 which is missing. Clicking on any other marked location breaks out of the sequence.

My guess is that move 4 is a pass :smiley:

In diagrams this is usually shown with a note such as

4 = pass

Passes are thankfully less common than captures/repeated moves!


Oh! That’s so whack, I had no idea! Thank you so much!

1 Like

The weird thing is that when the AI wants to pass on a 19x19 board it’ll (recommend to) play at Q19, but there’s no such point on smaller boards that I’ve noticed.

It’s a bit weird for the ai to pass though while there’s still dame? I think you’re right though that pass will keep the sequence active.

That’s quite odd and arbitrary point. Do you have an example of a game where it does that?

I guess the engine might have some other distinct way to indicate a pass recommendation, but it’s just a presentation issue with indicating that in the GUI?

Recommending Q19 sounds horrible, what if it’s killing yourself? :sweat_smile:

And why Q19 in particular?

The passing in this case doesn’t lose any points since there is an even number of dame left, but it’s still strange. KataGo has several options to change how it plays at the end of the game (whether to remove dead stones from the board before passing for instance), maybe something there could be tweaked to remove this slightly confusing pass? (although I guess this is a PV reported from KataGo, not an actually played out sequence, so it might not follow the same settings)


That’s quite strange. The game is Japanese rules, so black actually playing there would lose a point of territory. I doubt that KataGo actually means to suggest playing at Q19 (unless there is a weird bug with KataGo), but rather there is a bug with the GUI presenting KataGo’s analysis.

1 Like

Yeah, just to show an example with live analysis, if I take a recently finished the game and fill in the dame:

Playing on top of your existing stone loses 0.2 points :smiley:


Technically, attempting an illegal move should indicate a resignation, dropping win rate to 0%


Yes, this is OGS’s bug.

My guess is that OGS’s code attempts to implement the parsing of two different move encodings using the same code at the same time:

  • GTP move encodings and which KataGo’s analysis engine also conforms to. This is the move encoding for the standard protocol for live Go engines, Go Text Protocol (which as an aside, was not forward-looking in a few different ways that make it unfortunate that it became the standard protocol). These moves look like “D3”, “Q16”,… and where the letter coordinate is mandated by the protocol to skip the letter I. Pass is defined to be the string “pass”, and A1 is the lower left corner of the board.
  • SGF move encodings. This is the encoding mandated for SGF files. These moves look like “dc”, “pp”,… where both coordinates use letters, and are mandated not to skip the letter “i”. Pass is defined to be the empty string “” or the string “tt” for boards < 19x19 as a special case, and “aa” is the upper-left corner of the board.

I’m guessing OGS’s code, by trying to parse both of these coordinate systems within the same function, when it receives “pass” from KataGo, it reads the first two letters and ignores the remaining letters, decides that this must be an SGF move encoding “pa” instead of a GTP move like the rest of KataGo’s output, and “pa” in SGF corresponds to Q19 in GTP.


I have another issue to add to this. This time, move 8 is missing, it does not appear that there is any stone that was captured and I think it does not make sense to be a pass with so much undecided territory? Any idea what it could be here? (or is it a pass anyway?)

Nevermind, I found move 8 hiding under move 12