[crossfire] [PATCH 2/2] Character-specific keybinding files
Arvid Brodin
arvidb at kth.se
Mon Nov 4 07:34:53 CST 2013
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...)
> I suppose it is somewhat lucky in this case that the client is just not core dumping - this really depends on the implementation of libc and what happens when a null value is passed to *printf function
Yes, it needs to be fixed ASAP.
--
Arvid
More information about the crossfire
mailing list