Re: [Bug-gnubg] How to save the results of a 2-ply hint?

[Joern Thyssen]

On Mon, Mar 31, 2003 at 12:31:36PM +0200, Øystein O Johansen wrote
> 
> > Another question: How do I save the results of a hint
> > (not rollout) for a given position?
> 
> Good question! I really think the only way is to use "Analyse Move" instead
> of "Hint". The analysis are saved in the sgf file, hint data is not saved.
> I made some thoughts about this and the solution I suggest is that the hint
> window was added a button to transfer the hint result to the analysis. The
> button could simply be labeled "Copy to analysis" or "Transfer to analysis"
> or something similar. Is this a good idea?

gnubg already copies the hint-analysis (and tutor analysis) to the match
records *after* you make the move. You *cannot* do it during the move
because the correct move record hasn't been created yet!

The problem is that the current record is not created until you *finish*
a move. For example, rolling the dice produces a MOVE_SETDICE record,
but a move analysis is saved in a MOVE_NORMAL record. The latter is not
created until you finish the move. Similar for cube decisions: the cube
decision is stored in a MOVE_NORMAL (for no-double) or in a MOVE_DOUBLE
record, but the record is not created until you've finished your move.

It is the same problem that makes it difficult to save the analysis for
SGF position files: a save operation is a sequence of MOVE_GAMEINFO,
MOVE_SETBOARD, MOVE_SETCUBEVALUE, ..., and MOVE_SETDICE move records.
This sequence builds the board with the correct position and with the
dice rolled.  However, the analysis is missing, since it's stored in the
MOVE_NORMAL that would come right after the MOVE_SETDICE. If we did add
the MOVE_NORMAL after the MOVE_SETDICE, then the position shown after
loading the position would be wrong, as it would show the board after
the move with the opponent no roll.

In order to fix this we have to do some re-designing of the internals of
gnubg. For example, divide each move record into a two parts: one that
is applied before showing the board and another part that is applied to
finish the move. However, there is problems with this idea as well...

There is some really ugly code lying around in gnubg due to this
(FixMatchState is one of them). 

Maybe Gary has some comments on how to solve this?!

Joern