Greetings,

You don't need to use the high number first, you can click and drag and so use either number first for your bear-in.

As for the bear-off, yes, it does require you to use both dice, what you need to do is again, click and drag.

Hi,

I understand from developers on the cocoafibs sourceforge project that they may be looking to resume development there.

You may find fixes and workarounds for these and other bugs in http://stepfibs.sf.net which is based off of the cocoafibs code.  Unfortunately the stepfibs tree does not build on OSX at the moment and I am still (I would guess) weeks away from a version that builds on both gnustep and OSX/Cocoa, although that is my main focus of development at the moment.

I am am more than happy to help you, or anyone else, fix these and other bugs in cocoafibs.  I don't have access to an Intel Mac, so someone who can test is fairly critical, and I not interested in publishing and supporting binaries of cocoafibs at this stage of the development of stepfibs, so you'd need to be happy building your own (which is almost as easy as falling off of a log, and something I'd happily help with).

The behaviour at bear-off is bizarre, but can mostly be worked around by using the drag-and-drop. There is a bug in the undo stack which can combine very nastily with this.  In the worst case you can politely explain to your opponent that you have hit a bug and need to leave and resume.

I'm surprised to hear that the gag bug manifests on intel.  I had the same problem on gnustep, and I thought it was a problem in NSKeyedArchiver (which the very nice GNUstep people have fixed), when I went to check this I had trouble replicating the original bug.  you can see my comments, and a simple workaround, here: http://stepfibs.svn.sourceforge.net/viewvc/stepfibs/stepfibs/trunk/StepFibsAppController.m?r1=33&r2=36&pathrev=36.
Perhaps this report does explain something though:  cocoafibs has been around on mac for a long time.  last year I was asked about new clients doing this and I explained that cocoafibs could do this in certain circumstances (based on my porting experience), so perhaps this one only manifests on Cocoa on Intel.  I will see if I can raise the cocoafibs guys to work on this and get a binary out, since this is a particularly nasty bug.

Thinking about it   sounds a lot like undo stack breakage that can happen when there is NSKeyArchiver breakage.  You might find both of these bugs would go away if you rebuilt with the lastest xcode, since its hard to believe breakage there would have lasted so long.

Regards,
Paddy

I use one of the new Intel Macs--it seems like that could be part of the problem.  The drag and drop suggestion doesn't usually work.  Unchecking "high dice first" in preferences sometimes works, but often you have to logout first and come back in.

I just noticed the blind and gag problem today for the first time too.  Bizarre.

Thanks to all of the programmers for taking this into consideration, and for any fixes they can provide.

Update: I find the problem is reduced, although not totally eliminated, if I check the "Highest Dice First" option.

There are still instances where I cannot make the move I want, however.  For these, I have learned to resort to the terminal commands.

http://www.cybercom.net/~damish/backgammon/mike_quinn/cmds.htm#move

All a bit fiddly, but fortunately it means that FIBS is playable!

SL

That's not the same bug.  Arguably, it's not a bug at all - it's just CocoaFIBS (or FIBS itself, or both) rigidly enforcing the rules of backgammon: "if you can move both dice, then you must". 

Just make sure that toggle automove is on, then FIBS will automagically bear off your last checker.