bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Another editing bug - Cause/Questions/Fix


From: Michael Petch
Subject: Re: [Bug-gnubg] Another editing bug - Cause/Questions/Fix
Date: Thu, 21 Jun 2012 02:39:34 -0600
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

On 2012-06-01 11:28, Timothy Y. Chow wrote:
> I'm not sure if this has been fixed in the newest release, but I'm going 
> to report this anyway.  (I've experience this behavior frequently before, 
> and have even reported it to this list, but until now was having trouble 
> reproducing it.)  I'm running 0.90-mingw 20111003 on a Windows XP box.
> 
> 1. Open up GNUBG (GUI version).
> 
> 2. Click on the Edit button to enter edit mode.
> 
> 3. Paste in the following XG ID:
> 
>     XGID=aa--CaE-B---bA-a---bcbbABA:1:1:1:51:4:4:0:7:10
> 
> 4. It's Black's turn to play (near player).  Click on the little White
>     checker underneath the board so that it's White's turn to play.
> 
> 5. Shift-click and drag Black's checker on his midpoint to his 8pt with
>     the mouse.  White's outfield blot should spontaneously jump to the bar,
>     as if hit.
> 

I finally got around at looking at this. I have a fix that seems to
work, but it has me scratching my head about changes made by Christian
back in 2009.

First off, the root cause of this problem is started when the dice are
reset (cleared). This happens when you change which player is on turn,
as in the example above. In some of the code we set both the dice to -1.
-1 dice causes the move calculator to do very peculiar things (which
applies when dragging in edit mode). One side effect of this bug is that
the hit function attempts to move -1 (backward) from the point of
origin, and any blots it encounters will be placed on the bar. This is
what happens in Timothy's case.

Try Tim's procedure with this position:

GNUBGID: bDcqgFA4n0EAWg:UYnmAEAAIAAE

You'll see that the 3 blots end up on the bar.

The fix for this is to check that the dice are not -1.

Although I have a fix, it brings to light an issue. It appears in the
early days of GNUBG, dice not being set was identified with value of 0
for both dice. In fact, the header files define diceRoll[2] as an
unsigned int, and we are storing -1. The comments in gtkboard.h suggest
the original intent was for dice 0,0 to mean "not set". The -1 values
started appearing in 2009, and I haven't gone through every line of code
to see why that is.

One other oddity is this. When you swap the player on turn, we set the
dice to be "not set" (-1 at this time). This is actually different than
earlier releases of GNUBG (version 15). Swapping who is on turn keeps
the dice intact in older releases. Is this newer behavior intended
(designer intent)? or a bug? And last, should we be using 0 instead of -1?

-- 
Michael Petch
CApp::Sysware Consulting Ltd.
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304





reply via email to

[Prev in Thread] Current Thread [Next in Thread]