RE: [Bug-gnubg] New union type in moverecord?

[Øystein Johansen]

>===== Original Message From Joern Thyssen <address@hidden> =====
>On Wed, Apr 23, 2003 at 12:09:10PM +0200, Øystein O Johansen wrote
>> Hi,
>>
>> As I went to my hotel room monday night, Achim showed me yet another bug
>> while saving and opening positions.
>
>What bug?

1. Start a new game.
2. when it's your turn to move, ie. your dice are rolled, press "edit" button,
and edit the position.
3. Edit so that one of the players has his/her/its turn before the dice is
rolled.
4. release the edit button to exit edit mode.
5. save the position as sgf
6. When you now open the sgf position file you just saved, you will see the
dice rolled, even though it's one of the players turn to roll the dice, and
the dice appears on the wrong side of the board.

>I'm not particular fond of introducting a new moverecord.

I don't like introducing new records either, but if it can solve problems and
make life easier, I like it. The problem is that I'm not sure if it makes life
easier or worse, so that's why I'm asking for your opinion. After all we must
admit that we have a problem here.

>Most of our problems comes from the fact that we save up to, but *not*
>including, the "interesting" move record, typically a move normal.

Yes, I see.

>We have exactly the same problem when saving partial matches. In this
>case the very last moverecord in the saved match will be a MOVE_SETDICE
>or the opponent's last MOVE_NORMAL. A cube decision hint or chequer
>play hint will *not* be saved for this move.

See!

>A saved position is just a special case of this, i.e., there are just
>5-7 moverecords instead of hundreds, but the same problem exists: the
>last, but interesting, move record is not saved.

See!

>So we also need to save your movesetposition for a match, session or
>game as well. So I think this approach will just introduce new problems.
>i.e., we should save incomplete matches with an trailing
>movesetposition, but the movesetposition need to be popped and replaced
>with a movenormal when the users plays on.

You're right. And then again we will need a lot of implementing of new
functions for the new record type.

>I think I now know how to handle this problem just be splitting each
>moverecord into a pre-apply (e.g., set player on roll)and a post-apply
>part (actually move the move). The pre-aply part is actually done by
>FixMatchState these days, so the "only" changes are that we start saving
>the last moverecord instead of letting it be implied.

Not sure if I understand, but never mind. It sounds like you have a better
idea than me.

>My approach is actually similar to yours except that you have merged a
>number of moverecords into one, whereas I prefer to keep the separate!

Creating a positioninfo struct similar to the gameinfo struct ? The
positioninfo contains setboard, setdice, setcubeval and setcubepos together
with the data usually found in gameinfo?

>I'll look at this and get back to list once it's implemented.

;-)

>Joern

-Øystein