Re: CF: losing Run/Fire in 0.95.1

[Maciej Kalisiak <mac@cs.utoronto.ca>]

Mark Wedel writes:
 >  It appears you are using the gtk client.  When reporting bugs in the
 > client, please include what version of the client (gtk or standard x11) you
 > are using, since a large portion of what the client does is unique is this
 > regard.

Right, will do.

>  The above suggests that the gtk client is loosing information someplace.
 > However, the above messages suggests that the gtk client is missing the
 > state transitions.

Yeah, I was a bit hasty in my look at the code; now that I am a bit
more awake ( :) I think it's the client. See bottom of message for
some stuff I failed to mention previously, which points the finger at
the keybindings code (I think).

>  I would try using the X11 client and see if that works.  If you don't see
> the problem there, it is definately a client issue and not the server.

Sounds like its worth the try. Right now I'm trying to find a way to
reproduce the bug 100% of the time, so I can verify if a patch works,
or the x11 client for that matter.

 >  The server does maintain some idea of run and fire status - however, the
 > client provides this information (client sees that the shift key has
 > been hit, and then tells the server to turn fire on.  When it sees the
 > shift key released, it then tells the client to turn fire off.  Likewise
 > for control/run.)  So the server is only as accurate as the information the
 > client provides.  If the player hits shift, the client sends that fire
 > is on, and the player releases the shift key but the client doesn't notice
 > (and thus doesn't tell the server that fire is off), the server will go
 > on with the fire on since that is the last it was told.
 > 
 >  That said - I do know of ways to confuse even the X11 client - if you press
 > the shift/control key while in the window and move the pointer out of the
 > window and then release the key, the client won't see the release (since
 > it is no longer in focus).  Likewise, if you press control out of the window
 > and enter the window and release it, the client then sees a release with
 > no press (not as big a deal).

Yes, that's true, but the client easily recovers from such
tomfoolery. :) I just realized that I failed to mention a couple more
pieces of crucial data:

1) When I lose the Fire/Run, it seems it is something to do with the
key bindings. In the info window of the client (where you get all the
in-game text output), when I press Ctrl and Shift after the loss, I
get a message along the lines that "L_Control key not bound", etc.! (I
guess this pretty much alters the whole problem :), much like if I
pressed Alt...

2) The way I sort of correct the situation is to hobble to the nearest 
"bed to reality", 'a', "play again", and I'm back in business. Perhaps 
the key bindings are reset, which would fix the problem.

-- 
                                                         Maciej Kalisiak
"Linux. Where do you want to go                      mac@dgp.utoronto.ca
tomorrow?"                                         mac@elecom97.mail.net
                                               www.eecg.utoronto.ca/~mac
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]