Sabaki
Sabaki copied to clipboard
Unable to remove stones from a node
Suppose you want to create an SGF with a starting position and some variations. You setup the starting position in Edit Mode and then enter the main variation. While you are entering the main variation, you notice that you made some mistakes in the initial position. So you jump back to the root node which defines the initial position and switch to Edit Mode again to add or remove some stones. But Sabaki does not apply your corrections to the root node. Instead it creates a new child node. So your corrections are not visible in the main variation. This means that the Stone Tool behaves differently than the other tools of the Edit Mode because those do not create a new child node.
In my opion this is a bug. Sabaki should allow the user to change the initial position of an SGF file. I understand the reasoning for the current implementation. If a user changes the board position after a move of a variation later moves might not be valid moves. I would suggest that a user should be asked if they want to apply the Stone Tool to the current node or if they want to create a child node based on the current node.
+1. I encountered this issue today, and I agree with MaralWa's analysis.
I found a limited workaround: cut the main variation, apply the changes to the initial position in the root node, and paste the variation back. But that will only work with one main variation.
This is not a bug, it's just as you explained:
I understand the reasoning for the current implementation. If a user changes the board position after a move of a variation later moves might not be valid moves.
This mirrors the same behavior from various other SGF editors. As a workaround, as @goodger mentioned, you can cut the variation from the first move, leaving only the root node, then use the stone tool to edit the root node, then paste your variation again. With cut/paste you can fix all kind of blunders.
Hi yishn, which various SGF editors are you talking about? CGoban on my MacBook, SmartGo Kifu and EasyGo do exactly follow my expactions. I still consider the way Sabaki handles subsequent editing of an initial position a bug or atleast extremely inconvenient and counterintuitive. Ciao Maral
Last time I checked, CGoban should behave the same way as Sabaki? I'm also fairly sure GoGui behaves the same way, as it served as inspiration for this project.
CGoban does allow the starting position to be modified even after moves have been played. (I'm not familiar with GoGui.)
An editor should be a tool that gets out of the way, and allows the author to quickly & easily do what they need to do. In other ways, Sabaki is far superior to CGoban as an SGF editor. It would be great if Sabaki were superior in every way. (Thank you for a great application!)
CGoban's approach here is "the user knows what they are doing", whereas Sabaki's seems more "that could potentially be dangerous, so we won't be allowing that". IMO CGoban's approach is correct.
Here's a scenario where this approach is far superior. We set up a position, and add some moves (first variation). We then add some other moves in a second variation rooted at the starting position. We add in a third variation, also rooted at the starting position. Then we realize that we forgot a stone in the initial setup (e.g., a ladder breaker). To correct this, we would have to edit the starting position and make the changes, which creates a new "real starting position" variation. Then we'd have to cut each variation and paste it to the new "real" branch. Finally we'd "flatten" the tree. That's a lot of frustrating (and non-obvious!) work to make what should be a simple change. I suspect that many users encountering this scenario would give up and switch to another SGF editor.
So, please reconsider!
I also find I have to do a lot of mucking around in Sabaki to make certain additions in the game tree, similar to what @goodger describes. It is unintuitive, confusing, and unsatisfactory. @goodger's suggestions are desirable. In all other ways Sabaki is great! Thanks again @yishn!
The more common scenario is when the user reviews a game and wants to explore a variation in an alternate "what if" scenario. Then they can remove/add stones as they fit (What if that ladder breaker was there? What if there was no weak group around?) without completely destroying the whole game.
But I agree your use cases are also valid. Maybe we can add a "fix mode" for the stone tool so that modifying stones will not create a new variation, activated by holding a Ctrl or similar.