Fuego may work with incorrect Komi after board position change

[herzbube]

Repro steps:

1. Start a new game using the default 7.5 komi.
2. Send GTP command "get_komi". Fuego returns the expected komi value 7.5.
3. Load an .sgf file that contains a different komi value, e.g. komi 0.5, and at least one move.
4. Send GTP command "get_komi". Fuego returns the expected komi value 0.5.
5. Change board position.
6. Send GTP command "get_komi".

Expected: Fuego returns komi value 0.5.
Actual: Fuego returns komi value 7.5.

[herzbube]

When the user starts a new game, Little Go sends the GTP command "clear_board" followed by GTP command "komi 6.5" (and other GTP commands which are irrelevant for this issue).

When the user changes the board position, Little Go sends the GTP command "clear_board", but not the GTP command "komi". The reason why no "komi" command is sent is mentioned in the source code (in file SyncGTPEngineCommand.m) in this comment:

clear_board affects handicap (but not board size and komi)

As it turns out, this comment is wrong! Whenever Fuego receives the "clear_board" command it resets komi to the last value that was explicitly set with the GTP command "komi" (or to the built-in default komi value 6.5, in case no "komi" command was ever sent).

This is no problem for Little Go as long as board position changes are made in a game that was newly started from within Little Go, because in that case Little Go has previously sent the GTP command "komi" and has thus provided Fuego with an explicit komi value. This is probably also where the comment in SyncGTPEngineCommand.m is coming from.

The problem begins when Little Go instructs Fuego to load an .sgf file by sending it the GTP command "loadsgf". In that case Fuego dutifully works with whatever komi value is stored in the .sgf file, until the next time when it receives the GTP command "clear_board" - which happens when the user changes the board position. Since Little Go does not follow up the "clear_board" command with the "komi" command, Fuego forgets about the komi value from the .sgf file.

[herzbube]

Incidentally, the problem completely "disappears" if after loading the .sgf file the app is stopped and then completely relaunched via the ApplicationDelegate method application:didFinishLaunchingWithOptions:().

The reason is that during app relaunch a NewGameCommand is executed which does send the GTP command "komi", and the command uses the correct komi value because it takes the value from the GoGame object that was unarchived via NSCoding during app relaunch.

[herzbube]

This bug has two detrimental effects:

• An .sgf file that is saved has the wrong komi value in it.
• Fuego is likely to play wrong moves. For instance, towards the end of the game Fuego might start to pass because it thinks it is winning, or it might resign because it thinks it is losing. The probability of misplays increases when there is a large difference in komi values.

The solution, obviously, is that SyncGTPEngineCommand must send the GTP command "komi".