[crossfire] Key repeat and keybindings

[Mark Wedel]

>> The protocol has improved since those were put in.  The client should be
>> able to better watch the number of acknowledge commands and send or not
>> send commands as appropriate.  Note per my previous mail, the next
>> enhancement that would be nice would be for the server to look at all
>> commands, and in addition to having priority, there could be something like
>> 'cancel are north commands', such that when the key is released, that is
>> sent to the server and the server does just that.  That said, even this
>> gets tricky - you don't want to cancel the a single command that was sent,
>> which might mean the client has to know if multiple commands have been
>> sent, and which ones.
>
> If the client waits for the acknowledgements before sending the repeat, isn't
> there a risk that we handicap players with a high network latency? If the
> acks are sent from the server immediately upon reception of the command,
> perhaps this wouldn't be so bad in most cases. If the ack is sent after the
> command has been executed, it would be a big problem.

  This is what the 'command window' property controls (comc/ncom protocol commands)

  Basically, the client won't send another command to the server if more the X 
commands are outstanding (have not been processed).  The problem here is just as 
discussed for other issues - the client is not smart in what command 
should/should not be sent (that apply healing potion may be a bad one not to send)

  The default for the command window is 10 IIRC, which means that the client can 
have sent up to 10 outstanding commands to the server.  In general, that number 
is too high, but can be easily set in the client.

  Note that this command acknowledge did not exist for a while in the protocol - 
the run_on/fire_on predate the existence of that feature.

>
>
>> This reduces the server having to remember more state.
>>
>> In terms of what commands should repeat and what should not, this could
>> probably be an option in the keybind menu, eg, 'repeat?' which notes if the
>> command should be repeated or not.  Probably also allow it in the
>> keybindings itself, because for some commands, there may be desire to
>> repeat them in certain circumstances and not other (apply immediately comes
>> to mind in certain cases, like eating a lot of low value food, but not in
>> others, like using exits)
>
> This is a great idea! It would also solve the problem with deciding whether
> to cancel a queue of commands or not - only on releasing the key of a
> repeating command should a "reset queue" command be sent to the server.

  And more specifically, rather than clear the entire queue, it would be 'clear 
the queue of the command that was just repeating'.  You could have a very real 
case of a character moving in some direction and the player hitting another key 
to do something without releasing the movement key (if fire_on is removed, it 
could be something like holding down the up arrow, so north is getting repeated, 
and then player sees a monster, hits shift so arrow is fired, and then releases 
the up arrow (player is waiting for monster to approach) - in that case, you 
don't want to lose that the player fired north.


>> I'd certainly say it is worth it to post it or upload it to sourceforge on
>> the tracker.
>
> Which is the preferred method? I'm used to sending patches inline in emails;
> the sourceforge tracker is new to me.

  If you think the patch is ready for inclusion (vs say demonstration code), 
then I think the tracker is the right place.  It should be pretty simple - it 
just lets you upload a file after you create the item to track.

  This is especially good if the patch is long, as sending it to the entire list 
may be a bit much, yet at the same time, more than one person may want to look 
at it.