ASCII Diagram to show labels and stone numbers

[d-korni]

At the moment, the ASCII diagram only contains symbols on the stones or intersections.

Looking at "/src/modules/board.js" (line: 313), there is the label option set with same data as the plain stones. Would it be possible to have the labels and stone numbers appear in the ASCII diagram?

Perhaps this could be with a one letter identifier for color ( b (lack) / w (hite) / p (lain) ) and the next characters representing the label (a letter) or the numbers (single or more digits).

Obviously, this would skew the diagram, and it would either have to be an alternative copy option, or force different spacing.

[yishn]

The ASCII diagram is mainly for Sensei's Library and should be compatible with it. Here's the wiki page on the diagram syntax.

[d-korni]

Thanks for the info, I didn't know that. This looks great and has a way to account for the stone numbering. Am I missing something, or are some features yet to be implemented?

[yishn]

The ASCII board generated by Sabaki is a representation of the board you see in Sabaki. To have numbers, you’d have to add numbers to the board in Sabaki yourself.

[d-korni]

Well, indeed I wasn't expecting it to have numbers before the user adds them. But based on what you said and the link you provided, it seems to be missing some information.

See the example below. SGF file contains all number-label information (not letter-labels), as shown in Sabaki (see attached image). Yet the ASCII output does not follow the convention of the link. Unless you meant to say that the user should add the additional information regarding the labels and numbers.

Sabaki Configuration:

SGF Output: ( ;GM[1]FF[4]CA[UTF-8]AP[Sabaki:0.34.0]KM[6.5]SZ[19]DT[2018-06-01] ;B[fd] ;W[fe] ;B[gd] ;W[ge] ;B[hd] ;W[he] ;B[id] ;W[ie] ;B[jd] ;W[je] ;B[kd] ;W[ke]MA[fd][fe]TR[gd][ge]SQ[hd][he]CR[id][ie]LB[jd:A][je:B][kd:1][ke:2] ;B[ed] ;W[ee]MA[fd][fe]TR[gd][ge]SQ[hd][he]CR[id][ie]LB[jd:A][je:B][kd:1][ke:2] )

ASCII Output: $$ $$ +---------------------------------------+ $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . , X Z Y # B X X . . . . , . . . | $$ | . . . . O P Q @ W O O . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . , . . . . . , . . . . . , . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . , . . . . . , . . . . . , . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ | . . . . . . . . . . . . . . . . . . . | $$ +---------------------------------------+

[yishn]

Ah, you're right! Sorry for the misinformation. The thing is, numbers in ASCII diagrams have to be on alternate stone colours, e.g. if 1 is on a black stone, 2 has to be on a white stone, etc... Sabaki doesn't have this limitation (you can even have a number on an empty field), that's why Sabaki does not support numbers.

[yishn]

Yeah, we probably should allow automatic stone numbering then, but in an SGF file you can have two successive moves made by black or white. How can we handle such a case?

[d-korni]

No problem. At least, we managed to understand each other. : )

Yes, this is a tricky point, which would require additional definitions on how the ASCII format is generated.

The easiest way perhaps would be to leave this as a limitation for when exporting to ASCII format, i.e. requiring that the numbers are consecutive on alternating moves between black/white. Of course, users could play a move at say 1-1 point and number it, to indicate a move away from play. This wouldn't be nice, but may serve the purpose.

A better alternative, would be that if there are consecutive numbers on same color stone, then the actual ASCII export would skip a number. Say B1 W2 B3 B4 W5... In the ASCII format this would come up as B1 W2 B3 B5 W6, ommiting W4. This is possible and would be understood by the other software too.

Generally, I don't think I have seen any other software achieving this at the moment and reading at Senseis Library, there is nothing specific on this account. What I have tried so far seems to just fail in the occasion you are referring, and simply translating the numbers for different colors.

What I see as the important part is to include the numbering (from 1 to max 10), indicate if numbering starts from black or white and also from what number the counting starts from. To this extent it will all be compatible with SL format.

[d-korni]

Also, numbers on empty fields could be converted to letters instead.

This is more conventional, where numbers are usually on the stones and letters on the field. You also get letters for groups of stones, but again, there is so much we can do.

[yishn]

Sounds good. But to avoid confusion, we should probably ignore numbers on empty fields, because we support letters on empty fields already.

[d-korni]

Fair enough. To be honest, the people using the ASCII export would most likely already know the limitations of this format, so they would know what Sabaki options to use. So what you are suggesting is just what we need.

I wish I could help you out coding this, but I only have some lazy Python skills, so not much I can do.