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

[Joern Thyssen]

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?

> I really think there's a dead dog
> burried here which gives us problems, bugs and limitations. Half asleep I
> suggest for Achim that this may be solved with a new union type in the
> moverecord. Do you think this is  a good idea? I think it may solve some of
> the problems we have right now.
> 
> Here's my suggestion for structure:
> 
> I have not done any testing or even thought about how to implement this
> structure into function like saving positions and AddMoveRecord and
> analysing positions. Analyse position will probably be a new menu option
> with this structure. I guess it will solve some of the problems we have
> today (and create some other problems ;-) )

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

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

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. 

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.

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.

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.

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!

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

Joern

> 
> Just think about it. Smart or not? Is the structure complete?
> 
> -Øystein
> 
> 
> -------------------------------------------------------------------
> The information contained in this message may be CONFIDENTIAL and is
> intended for the addressee only. Any unauthorised use, dissemination of the
> information or copying of this message is prohibited. If you are not the
> addressee, please notify the sender immediately by return e-mail and delete
> this message.
> Thank you.
> 
> 
> 
> 
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-gnubg