Page 1 of 1

Strange way of handling suicide moves

PostPosted: Tue Oct 18, 2011 1:19 pm
by BartTM
The applet allows suicide, but does not remove stones when it happens.
This leads to bizarre situations as stones can become invulnerable, even though they have no liberties at all.
See the comments on problem for instance.

I think the applet should either forbid suicide or remove all stones involved.
I'd prefer the latter, as the problem author can block it if if is not wanted (esp. when the ruleset of that problem forbids it).

(we can also adopt this way of handling suicide as the defining factor for our own new GoProblems ruleset and convince the world that this is the way to do it.
It also brings surprising new insights in the game: a group with one eye can live now, because when the last outside liberty is taken you fill in that eye yourself; the resulting lump of stones has no free spot to play on and is therefore safe. Maybe games will end without a single liberty on the board. The one who takes the last liberty may well be declared the winner. No more jigo!? :D )

Re: Strange way of handling suicide moves

PostPosted: Wed Nov 02, 2011 2:41 pm
by BartTM
For a brief moment I thought I had found a way to remove stones.
There is a way to add stones or change the color of stones somewhere in a variation by using the graphical editor. I use it f.i. to swap sides for counterplay in a 'no can do' scenario.
Navigate to the node that you want to edit, click the Stone placement icon and place or swap a stone. Click stone placement again (it swaps to play mode by itself when not in the root), do the next stone, etc.

What I found is that when you shift-click on top of a White stone in placement mode, that stone disappears. For a Black stone first cjhange it to White, then do the same again. It is true magic.
Even if you plough through the other nodes of the problem tree and come back to this node, the stones you have removed will redisappear (that word won't have a high count rate in Google) boosting my belief we're on to something.
But when viewing the SGF code to find out what code is responsible for this behaviour, there seems to be niothing there. And reparsing the generated code without changes makes the disappearing moves undisappear (count that one!).
In other words, although the graphical editor (sort of) supports the removal of stones internally it does not back it with SGF code.
Such a pity as the SGF format does contain stone removal codes, but they are neither generated by the editor nor recognized by this site's go applet.

I truly wonder how the editor manages removing stones as indicated... and why it is not supported by the applet.