Life In 19x19

Bonobo wrote:

HermanHiddema wrote:[..] The way the diagram format works, the colors have to alternate. You cannot have and on the same board. If 1 is black, 2 is white. The top right color choice only changes whether odd move are black, and even moves white, or vice-versa, and therefore all the moves already on the board switch color too.

Forgive the n00b question (I’ve never created diagrams, only enjoyed them)—how does this handle passing?

A pass is not visible on the board, so if you want to indicate a pass, you would do so in the caption, e.g:

Click Here To Show Diagram Code

[go]$$B 2 pass, 3 fills the ko
$$ +--------------
$$ | 1 O O . . . .
$$ | O X O . O . O
$$ | X X O . . O X
$$ | . X X O O . X
$$ | . . X X O . .
$$ | . . . X O . .[/go]

Now additionally, both SL and L19 have ways of generating single stone images in text. L19 has them easily accessible in the smiley list. So you could do something like:

Click Here To Show Diagram Code

[go]$$B pass, defends ko
$$ +--------------
$$ | 1 O O . . . .
$$ | O X O . O . O
$$ | X X O . . O X
$$ | . X X O O . X
$$ | . . X X O . .
$$ | . . . X O . .[/go]

In the future, if I add a feature to generate diagrams from SGF, I may have to add an option to automatically generate captions like this when a move cannot be represented on the board (because it is a pass or is placed where a stone already was). In that case, I'll add an option to choose SL or L19 output format.

Now the underlying question, perhaps, is why colors should alternate. Why not just allow and in the same diagram?

The answer is that the idea behind the diagram format is: One character per intersection. To indicate the moves, the characters 1, 2, 3, etc are used. This is also why you cannot go beyond 10 moves in the diagram (0 is used for 10). Since there is only the one character, there is no way to indicate its color (you would need e.g. B1, W2, B3 for that). SL solves this by specifying, on the first line, the color of the odd moves. That's why the diagrams start with e.g. "$$B" on the first line, the B there indicates: odd moves are black.

If you want other options, like more moves per diagram, black for both odd and even moves, letter labels on stones, etcetera, you could make such diagrams in a plethora of go software (e.g. MultiGo, Drago, etc). Those have an image export option, which you could then host somewhere (e.g. imgur.com or min.us) and include on the forum via img tags. The main downside to doing that is that it is hard for others to respond to your diagrams. With the current diagrams, you can click the "show diagram code" link, copy and paste, make some additions/adjustments and post your answer. With embedded images, you would have to start from scratch.

Kirby wrote:If you don't want to buy an ipad for testing, maybe you can use the ipad dev kit with xcode to test it out with the emulator.

This only seems to be available for OS X.

Regarding the MIT license, that's cool. Thanks for doing that.

Regarding not having an iPad to test or an emulator to use... I don't know what else to do other than to try things out and see if someone else can test it for you. :-p

Kirby wrote:Regarding the MIT license, that's cool. Thanks for doing that.

Regarding not having an iPad to test or an emulator to use... I don't know what else to do other than to try things out and see if someone else can test it for you. :-p

Well the alternative is hoping someone will fork it on github, work out the iPad issue and send me a pull request

Anyway, I will try to keep an eye out for an iPad to test on. Maybe a colleague has one.

HermanHiddema wrote:Future features already planned:
- Change the starting move number
...
- Turn on/off coordinates markers

These would be nice to have, if you have the time.

Major update!

Now with:
- multiple diagrams
- easy custom size diagrams
- draw your own hoshi
- turn on/off coordinate markers
- auto-select output on click
- add a caption to the diagram
- create follow-up diagrams

The last feature, follow-up diagrams, copies the current diagram, removes all markers and labels and turns moves into stones of the proper color. You can also use this feature to easily create variations. Do your setup once, then click "create follow-up diagram" as many times as you need, then add in the moves in each diagram.

Check it out! http://hiddema.nl/diagrammer/

Here is a thought.

Currently, $$Wcm25 means White plays first, use coordinates, and start with move 25. How about something like this?

$$Wcm25n could mean use the small letters a - z for moves after 0.

That would give us 36 moves per diagram, giving up some labels when there are more moves.

How long until Herman realizes he's creating an SGF viewer?

Bill Spight wrote:Here is a thought.

Currently, $$Wcm25 means White plays first, use coordinates, and start with move 25. How about something like this?

$$Wcm25n could mean use the small letters a - z for moves after 0.

That would give us 36 moves per diagram, giving up some labels when there are more moves.

Yeah, I've thought about solutions like this before. 10 moves is often enough, but not always.

The diagram generation (both here and at SL) is done by http://senseis.xmp.net/?GoWiki/SLtxt2PNG which is GPL, so it is easy enough to make a new version.

To keep compatibility between sites, we would have to talk to Arno about this change too, I think.

Another alternative would be to have a completely new format which drops the one character per intersection limitation. The downside to such a solution would be that it would become hard to edit diagram code by hand, so you would always need a tool like mine.

hyperpape wrote:How long until Herman realizes he's creating an SGF viewer?

https://github.com/HermanHiddema/sgfparser/tree/v0.1

To expand on Bill's idea a little, if I were to design a new format with a one character per intersection limit, I would choose something like:

., empty & hoshi
1-9,0,a-z for moves 1-36
#@^% Marked intersections with square, circle, triangle, cross
OPQRS White stones (O = empty, the others have markers)
VWXYZ Black stones (X = empty, the others have markers)
A through N: labels on empty intersections.
?*TU search related things: greyed intersections and half empty/black/white stones

HermanHiddema wrote:To expand on Bill's idea a little, if I were to design a new format with a one character per intersection limit, I would choose something like:

., empty & hoshi
1-9,0,a-z for moves 1-36
#@^% Marked intersections with square, circle, triangle, cross
OPQRS White stones (O = empty, the others have markers)
VWXYZ Black stones (X = empty, the others have markers)
A through N: labels on empty intersections.
?*TU search related things: greyed intersections and half empty/black/white stones

What happens with existing diagram code in L19 and SL, apps like kombilo that generate diagrams, etc.? I am instinctively against hijacking a-z and breaking their existing use. The main problem with the 10-move limit is the trouble to manually create a second diagram (change all the numbers to X's and O's). This could be overcome by having a button in the widget to 'continue' the existing diagram - automatically converting the numbered to unnumbered stones. Personally I think that the usefulness of diagrams declines rapidly as the length of the diagrammed line of play increases.

ez4u wrote:What happens with existing diagram code in L19 and SL, apps like kombilo that generate diagrams, etc.? I am instinctively against hijacking a-z and breaking their existing use.

I completely agree with this. Seems a little dangerous to break already established "standards."

The main problem with the 10-move limit is the trouble to manually create a second diagram (change all the numbers to X's and O's). This could be overcome by having a button in the widget to 'continue' the existing diagram - automatically converting the numbered to unnumbered stones. Personally I think that the usefulness of diagrams declines rapidly as the length of the diagrammed line of play increases.

Luckily Herman already added that "continue" functionality!

schultz wrote:

ez4u wrote:What happens with existing diagram code in L19 and SL, apps like kombilo that generate diagrams, etc.? I am instinctively against hijacking a-z and breaking their existing use.

I completely agree with this. Seems a little dangerous to break already established "standards."

Yes, this is a problem. Bill suggested a flag in the settings on the first line of the diagram, but that would still be vulnerable to mistakes while e.g. copy/pasting part of a diagram.

An alternative would be to claim the unused capital letters. Currently, the following letters have the following meanings:

Click Here To Show Diagram Code

[go]$$Bc1 See coordinate letters to see which capital letter gives what result.
$$+----------------------------+
$$|ABCDEFGHJKLMNOPQRSTUVWXYZ[/go]

(Capital I is also unused, but I left it out to line up the coordinate markers)

so e.g. D through L could be used for 11-19, and N for 20, without breaking backwards compatibility.

HermanHiddema wrote:
so e.g. D through L could be used for 11-19, and N for 20, without breaking backwards compatibility.

I was going to suggest this, but then I thought it would be too complicated. Of course, it is better than not having any means to do 11-20.

Not knowing about the other platforms (SL, kombilo etc), but at least at this forum one could also introduce a new tag alongside go-tag (e.g. hhGo - as in Herman Hiddema ) that would use the new, improved but incompatible format. At your excellent website one could choose which format to create.