Forced move bug

[jonesyjt]

Hey TusconAZ,

I was playing a very, very back backgame with 9 checkers in my opponents house (covering three of his points) and one on the bar. After my roll, it moved as if it were a forced move, when it was not.  It would be nice to be allowed to disable this feature and move myself even if it is forced.  Also, I would like to be allowed to disable the "pause for double" even in a crawford match.

[don]

You must have your automove toggle set to on, jonesey.

help toggle-automove

NAME
  toggle-automove

VALUES
  YES: forced moves are done automatically.
  NO:  You have to move yourself.

DEFAULT
  NO

SEE ALSO
  move

Personally, I've never seen automove make a mistake, and I'd like to see an example of when it has.

Regarding ["pause for double" even in a crawford match.], all you have to do is toggle double.

help toggle-double

NAME
  toggle-double

VALUES
   YES: You will be asked if you want to double.
   NO:  You won't be asked if you want to double.

  If set to NO the server will roll for you even if you
  are allowed to double.

DEFAULT
  YES
  This toggle is reset to YES every time a new game is started
  or reloaded.

SEE ALSO
  double, roll, toggle-autoroll

FIBS sets the doubling cube off in Crawfords and one-pointers, but you can turn it on again, like if you want to slow down a game with a bot so you can see what's happening.  This is an excellent time to point out that FIBS has comprehensive help files that are ignored by most GUIs.

At this point you might want to ask FIBS,

help toggle

NAME
  toggle - display or change the value of toggles

SYNOPSIS
  toggle
  toggle <option> [<option>...]

DESCRIPTION
  'toggle <option>' toggles the status of <option>.
  'toggle' without any option gives you a list of currently
  available options and their status.
  You can type 'to' instead of 'toggle' and also use any unique
  prefix for the option, eg 'to gr' for 'toggle greedy'.

  Valid options are:

  allowpip            autoboard           autodouble
  autoroll            automove            bell
  crawford            double              greedy
  moreboards          moves               notify
  ratings             rawboard            ready (or just 'r')
  report              silent              telnet
  wrap

  Type 'help toggle-<option>' to find out what <option> means.
  Example: To find out what the 'bell' toggle means type:
  help toggle-bell

SEE ALSO
  toggle-<option> for all <option>s given above.

'hope this helps!  Oh, and you might want to save your options.  See FIBS help files!

--
don

[jonesyjt]

OK, I didn't see automove in the help list, so i thought this was a 3dfibs thing, not part of the server.  And for "pause for double", it always goes back off in a crawford game.  I thought "always going back off" was a 3dfibs thing.

[don]

You're not the only one, jonesy, which perfectly makes my point that FIBS clients, wonderful as they are, could be made to interface better with FIBS:

• Clients can easily point to FIBS' in-depth online help;
• There's frequently confusion about how to send a command directly to FIBS;
• Some clients emulate FIBS commands internally, but differently from FIBS (FIBS is not going to change so clients should act like FIBS for the benefit of, and from the perspective of other FIBS users.).

--
don

[burper]

So when is your improved design coming out? Is there a beta version we can try?

[don]

Hey burper, ole_salt, aristoF, CantBuyAThrill, nutcracker, thefog, whatever other IDs you may have on FIBS.

In reply to your

So when is your improved design coming out? Is there a beta version we can try?

I can only admit that I've had two versions of a Graphic User Interface (GUI) for FIBS that I've ever shared for comments or testing -- The first I used for about 10 years on FIBS, the second I'm working on, and  I freely confess that I've yet to come up with a GUI that I'd release to the general public.  I admire all of the programmers who have come up with complete programs to interface with FIBS.  I have not come up with anything for release.

I'm not sure if you understand computer programming, but I can tell you that there are two factors that are worth measuring, length of a program and I/O (input/output), that relate to difficulty of programming.  As the length of a program increases, so does it complexity by at least an order of magnitude.  Same same for I/O.  My point here is simply that nobody can do it all alone, perfectly.  I don't know if you've noticed, but there are programmers who use FIBSboard for suggestions for their clients.  There's a whole section of 'em!

Anyway, I've checked out most clients except for MacFIBS.  I've also watched users of all clients on FIBS, and I think my suggestions as a programmer are worth more than snide remarks.  I am making suggestions based on experience.  You seem to have a problem with my suggestion that:  No matter what a client does for its user, it should be transparent to other users.  In fact, this is obvious to me, but might be made clear by the following from http://http://www.fibs.com/fibs_interface.html#tell:

Tell

When you send the command:

    tell name message

If the recipient meets all of the following criteria:

   1. Is online.
   2. Is not yourself.
   3. Has not gagged you.
   4. You have not gagged them.

then, you get back a CLIP You Say line:

    16 name message

If the person you are trying to send a message to is not currently logged in or doesn't exist, instead you get the message:

    ** There is no one called name

If the person you are trying to send a message to has gagged you, you get back the message:

    ** name won't listen to you.

If you try to send a message to someone you have gagged yourself, you get the message:

    ** You can't talk if you won't listen.

If you try the tell command with yourself as the recipient you get back:

    You say to yourself: message

Note that there is some feedback expected from the FIBS protocol:

If the person you are trying to send a message to has gagged you, you get back the message:

    ** name won't listen to you.

Therefore I think that clients should respond to the rest of FIBS with the same, instead of

If the recipient meets all of the following criteria:

   1. Is online.
   2. Is not yourself.
   3. Has not gagged you.
   4. You have not gagged them.

then, you get back a CLIP You Say line:

    16 name message

This is a case where expected feedback to other users, not necessarily using the same GUI, get different results.  There are others.

For general purposes, I have no problem with this, but I hope you can see it could impede completion of, say, a tournament.  In fact, there is at least one user who thinks, using JavaFIBS, that any match communications between competitors should be referred to the TD.  In a tournament situation, I think communication should be clear between players, and therefore I think that GUIs should strive to emulate FIBS.

--
don

[socksey]

I'm still trying to figure out why I keep getting in Javafibs, system messages that answer queries i have not made about various players.  Any ideas on this?

socksey



"Sometimes I wish I had never met you. Because then I could go to sleep at night not knowing there was someone like you out there." - Anonymous

[burper]

i can't read all that meandering drivel don.
all i can suggest is that you demand your money back.
if you like, you can complain to repbot about the authors and smite their karma here on fibsboard.

[Hardy_whv]

I'm still trying to figure out why I keep getting in Javafibs, system messages that answer queries i have not made about various players.  Any ideas on this?

Hmm, I think you mean the queries that are made for the members of your friends list. To update this list (exp, rating, last login) after logging in JavaFIBS is sending who-messages to FIBS for every entry in your friends list. But that should be done within some minutes after login. After that there are no JavaFIBS generated queries any more.

Hardy 

[socksey]

I think maybe you are right.     Thank you!   

socksey



"Most of us go to our grave with our music still inside of us." ââ,¬â€œ Anonymous

[don]

It's this simple, burper...

i can't read all that meandering drivel don.

I have two suggestions to make to GUI programmers:

• Provide better interfacing with FIBS' commands and FIBS' help so that GUI users can better use all of FIBS' capabilities and functions.  This was jonesy's problem at the beginning of this thread.


• No matter the features of your GUI, it should behave to other users as if it were FIBS.  If you program a FIBS function into your GUI, it should make no difference in behavior (input/output) to other FIBSters who are not using your GUI.

--
don

[spielberg]

Sorry to digress from the thread but:

don - please note burper is a fine programmer himself and I suspect that, as often, you've not recognised teasing. I hope I'm underestimating you there - your summary of two rather obvious guidelines for programmers (viz. do not repeat work already done; stick to standards of communication between different interfaces to the same environment) may well be  intended to tease burper by telling him something he's sure to know.

Steve / spielberg

PS whatever happened to zoeboy?

[don]

This thread was started by a user who was confused about the actions of his Graphic User Interface (GUI) versus FIBS commands and capabilities.  Here's an interesting example on the same subject in which a GUI could improve on FIBS documentation....

Today I heard an experienced and frustrated FIBster shout that FIBS only keeps one invite active at a time, that an invite to a second user cancels the first invite,  The gist of the shout was that a user should wait a few seconds before issuing another invite.  (As a rule of thumb, I try to allow enough time for a "who is user" and a "tell RepBot ask user" before I issue another invite.)  Though I thought that most knew this, I also thought it was included in FIBS' documentation.  It turns out I was wrong.

From FIBS' help invite:

DESCRIPTION
  The 'invite' command is used to ask other players if they want to play
  with you. You can only use this command if you are ready to play (see
  'toggle ready'), the other player is ready to play and is not already
  playing with someone else. See help on 'who' to find out whom you can
  invite. There are three ways to invite other players (see above)

  1. you want to start a <number> point match with <name>
  2. you want to start a match of unlimited length with <name>
  3. you want to resume a saved match with <player>

The first two of the above discard a saved game if <player> accepts the
invitation, but <player> is told that there is a saved match.
Invitations for matches longer than 9 points are limited to players whose
experience is high enough to appear in the rating list. This was
necessary because some new players cheated themselves into the rating list.

SEE ALSO
  join, toggle, toggle-ready, who

Obviously FIBS "help invite" does not cover this, so I also checked out the excellent FIBS Client Protocol (CLIP) at http://www.fibs.com/fibs_interface.html and found no mention of this well known behavior.  I think clients should be aware of the significance or rather potential futility of multiple invites, but it does not seem to be documented anywhere.  None of the links to CLIP feedback seem to work, and this is a quirk that GUIs could use to improve their usefulness to users, particularly new users..  A minor point here, and a minor frustration, but FIBS would work better if users knew of this little detail of behavior.  GUIs could provide the info.

--
don

[socksey]

I made a programmable button in my javafibs for that very problem.  Whenever a newbie invites me, and I try to accept, but instead, get the regrettable message that tells me newbie hasn't invited me, I click my button which displays in shouts:

"attention impatient newbies!  if you don't give someone time to respond to an invite, your next invite will cancel out the first.  remamber that we might be checking out your rep, so please give us time to respond.  ))"

The reason I made a button for this is because it happens so very frequently to me.   

You're right, don, it would be much nicer if this were explained or incorporated where it should be.     I'm sure veteran Fibbers get tired of my (almost spam) messages in shouts.      

socksey



"A person should not promise to give a child something and then not give it, because in that way the child learns to lie." - Babylonian Talmud