[crossfire] [PATCH 2/2] Character-specific keybinding files

Mark Wedel mwedel at sonic.net
Mon Nov 4 23:35:14 CST 2013


On 11/ 4/13 05:34 AM, Arvid Brodin wrote:
> On 2013-11-04 07:38, Mark Wedel wrote:
>> On 11/ 3/13 03:03 PM, Kevin Zheng wrote:
>>> On 11/03/2013 13:36, Mark Wedel wrote:
>>>>    Just a question - is there any way to set up 'global' keybindings (eg,
>>>> those that apply to all characters)?
>>>
>>> This does seem useful. One possible idea to throw around is to make the
>>> key bindings window tabbed, one for per-character and one for global. If
>>> there's a conflict, prefer the per-character binding.
>>>
>>> Of course, this is easier said than done.
>>
>>   True on both accounts.  Having per character keybindings take preference over global ones would be the correct approach.  However, in an ideal world, both are visible, so one could easily see the conflict and make adjustments.
>>
>>   Note that it appears this patch introduces a new bug, as posted on the forums:
>>
>> Posted: Sun Nov 03, 2013 6:51 pm
>> Post subject : Compatibility with new character-specific keybindings?
>>      I updated my trunk client to the newest version (r19093), which has the character-specific keybindings as a feature.
>> When I logged into Metalforge with the new client, absolutely no keybindings work (not even the default ones). Any keybindings I try to create go to a (null).keys file and do not persist to another login.
>> When I log into netarbeiter (1.70.0), my keybindings work fine.
>>
>> Does this mean the newest trunk client is incompatible with the 1.12 branch? Or am I doing something wrong?
>> --
>>
>>   I suspect the issue is that metalforge is running old code, which predates the new character login logic.  As such, the client never has a character name of which to load keybindings for (and I haven't looked, but depending on where the load actually happens, perhaps never load them at all.
>
> The names of the characters are returned from the server as a response to
> AccountPlayersCmd (if I understand correctly), then stored in
> character_choose_window until play is started with a character, whose name
> is then stored in cpl.name and is used for loading and saving the keys
> file. If the name of the chosen character is NULL, that would be passed to
> strdup().
>
> No check is made since I assumed that it is not possible to start game play
> without having a list of characters to choose from.
>
> I just tried to login at metalforge and the game is instantly started with
> the character "dwarf the dwarf"... I.e. the whole login process is skipped?
>
> Can anyone describe to me how this works? (I can't test any more now, need
> to get to work...)


  metalforge is running an older version of the server, so yes, all of that is 
skipped, and the server does not support the protocol command for the client to 
get a list of characters available to the player.

  So what you see is how it works - you enter the character name, and then 
password, and that is the login process.

  Now a fair question to ask is whether the client should support old server 
versions or not - IMO, if having support is not hard, it should, but if making 
it work would be really difficult, then probably not.  Although, in that case, 
the client should see that limitation and print a message saying 'server to old 
- use an older client on that server' or the like.



More information about the crossfire mailing list