From davidnicholashurst at gmail.com Fri Nov 1 01:39:03 2013 From: davidnicholashurst at gmail.com (David Hurst) Date: Fri, 1 Nov 2013 17:39:03 +1100 Subject: [crossfire] Development Objectives. Message-ID: Hi Team, You may have noticed that I have been furiously updating the content in the wiki (http://wiki.metalforge.net/doku.php). I have added a new section called "the sworn book of scorn" which is designed to be a reasonably detailed account of the way crossfire works without being a spoiler. I hope to make it useful to both new players and old players alike. Things like dumps from the archetypes would be useful but might crossover into spoilers so I haven't prioritised them. Aspects of game player that are described by code seem sensible items in this section. If anyone would like to help me read and interpret the code, I'd love some help! Come say hi on the IRC channel. What i'm actually writing about is that whilst working on this documentation I have 'stumbled' on the dev sections of the wiki. What a mess! Given that the Monk was my creation I have decided to go down a similar path to improving crossfire and develop a new class and at the same time improve the skill missle_weapons. The new class is currently slated as 'rangers' which are loosely outlined here: http://wiki.metalforge.net/doku.php/dev_todo:cf2.0:classes. Is this where such progress should be documented? I wasn't certain, so I tidied up the Dev front page a little.. however a lot of the pages seem to have been superseded and I can't make head nor tail of which is which. Perhaps it is timely to remap the direction of the game? I'm happy to assist in anyway to merge, fix, delete, update any pages that should be. In, particular one area of Dev interests me which is the Cf2.0 documents (which seem to start here: http://wiki.metalforge.net/doku.php/dev_todo:cf2.0) A lot of the ideas in here are absolutely fantastic and I would love to see them in game. Some of them seem quite straight forward whilst others seem very complicated. Is much progress happening towards these? Sorry for the long winded email Saru -------------- next part -------------- An HTML attachment was scrubbed... URL: From arvidb at kth.se Sat Nov 2 11:04:11 2013 From: arvidb at kth.se (Arvid Brodin) Date: Sat, 02 Nov 2013 17:04:11 +0100 Subject: [crossfire] [RFC 2/3] Misc keybinding fixes and changes In-Reply-To: References: <526EF0F2.7000208@kth.se> <5271978D.8000701@gmail.com> <5271AD05.1070804@kth.se> <5272E69B.9030000@gmail.com> Message-ID: <5275227B.8020308@kth.se> On 2013-11-01 04:54, David Hurst wrote: > I'd be of the view, if it isn't reducing a functionality but > re-implementing it in a more useful way (be it more flexible, faster, > or any other good reason) then it has my support. This could better be described as removing an arcane feature to simplify the code and to make room for other improvements in the future. (Do you use the feature of rebinding the Run, Shift, Alt or Meta keys?) > Perhaps another perspective is that if you change it, and things > don't work out, it is a lot easier to backtrack and try and different > approach, than it is to have abandoned the idea before anyone got to > play with it and never know what we were missing in the first place > :). > > I would mention that at the moment windows users are really limited > to the jxclient, so do try and make a change that can be implemented > on both the gtk and jxclient. That's something of a tall order. :) It's a lot of work learning how _one_ client works; learning two clients and then trying do do only changes that benefit both (and doesn't break any) of them could be very limiting. (Is the Windows compatibility broken on the gtk client?) Are there any code dependencies between jxclient and the gtk client? I noticed the gtk client code is split between the folders common/ and gtk-v2/. I found references to something called the x11 client in the code, and I assumed that that was an old client that had since been removed. It was apparently called cfclient, later renamed crossfire-client-x11. If this has been removed, perhaps it would be a good idea to merge the common/ folder into the gtk-v2/ folder? (BTW, I've been working exclusively on the code in https://svn.code.sf.net/p/crossfire/code/client/trunk) -- Arvid From arvidb at kth.se Sat Nov 2 18:21:41 2013 From: arvidb at kth.se (Arvid Brodin) Date: Sun, 03 Nov 2013 00:21:41 +0100 Subject: [crossfire] [PATCH 0/2] Work on keys.c and the keybinding system Message-ID: <52758905.9020005@kth.se> I have generated a new set of patches without the removal of the functionality to re-bind key modifiers, and with some minor improvements. Otherwise, they are the same as before. These apply on top of current svn repository (rev 19089). I think we should still remove the functionality that allows one to rebind the modifier keys, for two reasons: * It doesn't seem to work. Try it out on rev 19089 - the bind is successful (when you press the bound key the corresponding "Run"/ "Shift" indicator lights up), but as soon as you press a direction key, the Run/Fire modifier is lost, and you only get a normal direction press. * Patch #2 introduces character-specific keys files. It would be nice to take the opportunity to change the format of that file in the same go, to correspond with the Ctrl and Shift keys (so "C" for Ctrl, instead of todays "R" for run, etc). -- Arvid From arvidb at kth.se Sat Nov 2 18:24:04 2013 From: arvidb at kth.se (Arvid Brodin) Date: Sun, 03 Nov 2013 00:24:04 +0100 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes Message-ID: <52758994.1060905@kth.se> * Show all keybindings (incl default ones) in both 'unbind' and the keybindings dialog. (Should reduce confusion for new users.) * Add "Any" key modifier type; New "Any" button in keybindings dialog. This lets the user choose between having a key work regardless of modifier (Run, Alt, etc) key states, or to use the same key with different modifiers for different bindings. How this worked before ("All"/"Normal") was pretty unclear, even in the code comments. (New feature/bug fix.) * Consistent use of hash helper functions (keybind_insert(), keybind_remove(), etc). This should make the code more maintainable and reduce the risk of bugs. * Better usage texts (among other things they used '[' which was interpreted as a style tag, making parts of the usage text go missing). (Bug fix.) * Bind only lowercase keys - we handle Shift state separately. (Bug fix.) * Rehash keybind entry on key dialog update (fixes bug where keybinding with modified keyval would become unusable until restart). (Bug fix.) * Removed -afmnr flags from 'bind' - instead use only "press the key combo you want" when you bind the key. This is to simplify the keybind without removing any real functionality. -- Arvid -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keybinding-multiple-changes.patch Type: text/x-patch Size: 57671 bytes Desc: not available URL: From arvidb at kth.se Sat Nov 2 18:31:43 2013 From: arvidb at kth.se (Arvid Brodin) Date: Sun, 03 Nov 2013 00:31:43 +0100 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files Message-ID: <52758B5F.5030608@kth.se> Today, keybindings are saved as ~/.crossfire/keys. That means you cannot have different key bindings for each character. This patch changes that so that keybindings are saved as ~/.crossfire/.keys. So if your character is named Leopold, the keybindings are saved to ~/.crossfire/Leopold.keys. When play is entered with a character, the client tries to load keybindings in the following order: ~/.crossfire/.keys ~/.crossfire/keys /def_keys If none of the files are found, it instead uses the default built- in keybindings. -- Arvid -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Added-player-character-specific-keybinding-files.patch Type: text/x-patch Size: 11818 bytes Desc: not available URL: From kevinz5000 at gmail.com Sat Nov 2 22:14:50 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 02 Nov 2013 22:14:50 -0500 Subject: [crossfire] [RFC 2/3] Misc keybinding fixes and changes In-Reply-To: <5275227B.8020308@kth.se> References: <526EF0F2.7000208@kth.se> <5271978D.8000701@gmail.com> <5271AD05.1070804@kth.se> <5272E69B.9030000@gmail.com> <5275227B.8020308@kth.se> Message-ID: <5275BFAA.1040206@gmail.com> On 11/02/2013 11:04, Arvid Brodin wrote: > That's something of a tall order. :) It's a lot of work learning how > _one_ client works; learning two clients and then trying do do only > changes that benefit both (and doesn't break any) of them could be > very limiting. (Is the Windows compatibility broken on the gtk client?) Maintaining the Windows port of the GTKv2 client is difficult. Nicholas tried to build a Windows version from trunk, with limited success. > Are there any code dependencies between jxclient and the gtk client? No, not that I am aware of. > I noticed the gtk client code is split between the folders common/ > and gtk-v2/. I found references to something called the x11 client > in the code, and I assumed that that was an old client that had since > been removed. It was apparently called cfclient, later renamed > crossfire-client-x11. If this has been removed, perhaps it would be a > good idea to merge the common/ folder into the gtk-v2/ folder? You've probably noticed that the sources in common/ are built into a shared library. The intention was to share some code between the several different versions of the client (X11, SDL, OpenGL, GTKv1, GTKv2). Now, it seems a little unnecessary (unless someone decides to bring back another client). Thanks, Kevin Zheng From kevinz5000 at gmail.com Sat Nov 2 22:41:07 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 02 Nov 2013 22:41:07 -0500 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <52758994.1060905@kth.se> References: <52758994.1060905@kth.se> Message-ID: <5275C5D3.1020109@gmail.com> Committed in r19090. To the best of my knowledge, Crossfire doesn't have a formal patch review process. By the time everyone reviews it, bit rot will have already set in. Best to commit it now and fix issues later if needed. On 11/02/2013 18:24, Arvid Brodin wrote: > * Show all keybindings (incl default ones) in both 'unbind' and the keybindings > dialog. (Should reduce confusion for new users.) I almost want to say that I miss the old behavior. If feasible, I'd really like to see a "show non-default bindings only" checkbox. Cheers, Kevin Zheng From arvidb at kth.se Sun Nov 3 08:50:21 2013 From: arvidb at kth.se (Arvid Brodin) Date: Sun, 03 Nov 2013 15:50:21 +0100 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <5275C5D3.1020109@gmail.com> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> Message-ID: <527662AD.2050702@kth.se> On 2013-11-03 04:41, Kevin Zheng wrote: > Committed in r19090. > > To the best of my knowledge, Crossfire doesn't have a formal patch > review process. By the time everyone reviews it, bit rot will have > already set in. Best to commit it now and fix issues later if needed. Ok. > On 11/02/2013 18:24, Arvid Brodin wrote: >> * Show all keybindings (incl default ones) in both 'unbind' and the keybindings >> dialog. (Should reduce confusion for new users.) > > I almost want to say that I miss the old behavior. If feasible, I'd > really like to see a "show non-default bindings only" checkbox. I see what you mean - suddenly there's a lot of "noise" in the keybindings dialog. What I did was to remove all bindings that I don't use, and it feels OK now. Perhaps that'll work for you as well? If you try it and still hate it, tell me and I'll see what I can do. :) I will also submit a cleaned-up version of the common/def-keys file. There are some obvious clean-ups and some "maybe": - 3 bindings of 'a' to "apply" (to handle different shift state and modifier states). Replace with a single binding of 'a' with "Any" flag. - 2 of 'e' to examine (shift state). Replace with single binding of 'e'. - What's the difference between the "take" and the "pickup" commands? (',', '@') - How often do we get new players who use Sun Type 4 Keyboards? Perhaps these could go? (17 bindings.) - Is there a difference between "rotateshoottype -" and "rotateshoottype -1"? Also needs modifier flags cleanup (A/N/NF). These I don't really know about: - I've never seen the "Nethack-Style" key layout before. Also, they don't seem to work in conjunction with the Fire modifier (only N and R). Does the fact that that bug has never been fixed mean they aren't used at all, perhaps? Or do people just fix that when they start to play? - Arrow keys... I *really* like the feature of command history and the prevkey/ nextkey that is available. But these are not bound by default, so perhaps they aren't used as much as they could be. On the other hand, using the arrow keys for this (and not for north/south etc) requires an immidiate help text whenever a new character is started, to explain how to move. -- Arvid From kevinz5000 at gmail.com Sun Nov 3 09:37:42 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 03 Nov 2013 09:37:42 -0600 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files In-Reply-To: <52758B5F.5030608@kth.se> References: <52758B5F.5030608@kth.se> Message-ID: <52766DC6.4000107@gmail.com> On 11/02/2013 18:31, Arvid Brodin wrote: > Today, keybindings are saved as ~/.crossfire/keys. That means you > cannot have different key bindings for each character. > > This patch changes that so that keybindings are saved as > ~/.crossfire/.keys. So if your character is named > Leopold, the keybindings are saved to ~/.crossfire/Leopold.keys. Committed in r19091, with minor changes, for much of the same reasons as the last patch. Thanks! Note that some of your existing key bindings may break after updating to the latest version, due to the previous patch. Thanks, Kevin Zheng From kevinz5000 at gmail.com Sun Nov 3 09:39:48 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 03 Nov 2013 09:39:48 -0600 Subject: [crossfire] [PATCH 0/2] Work on keys.c and the keybinding system In-Reply-To: <52758905.9020005@kth.se> References: <52758905.9020005@kth.se> Message-ID: <52766E44.6050106@gmail.com> On 11/02/2013 18:21, Arvid Brodin wrote: > I think we should still remove the functionality that allows one > to rebind the modifier keys, for two reasons: > > * It doesn't seem to work. Try it out on rev 19089 - the bind is > successful (when you press the bound key the corresponding "Run"/ > "Shift" indicator lights up), but as soon as you press a direction > key, the Run/Fire modifier is lost, and you only get a normal > direction press. This seems like a very compelling reason to me. I vote that we go ahead and make the change. > * Patch #2 introduces character-specific keys files. It would be > nice to take the opportunity to change the format of that file > in the same go, to correspond with the Ctrl and Shift keys (so > "C" for Ctrl, instead of todays "R" for run, etc). Yes, this change makes sense if control keys can't be rebound. Thanks, Kevin Zheng From kevinz5000 at gmail.com Sun Nov 3 09:50:44 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 03 Nov 2013 09:50:44 -0600 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <527662AD.2050702@kth.se> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> <527662AD.2050702@kth.se> Message-ID: <527670D4.6050701@gmail.com> On 11/03/2013 08:50, Arvid Brodin wrote: > I see what you mean - suddenly there's a lot of "noise" in the keybindings > dialog. What I did was to remove all bindings that I don't use, and it feels > OK now. Perhaps that'll work for you as well? If you try it and still hate > it, tell me and I'll see what I can do. :) It's not too bad. Since most of my personal key bindings are applied with the ALT key, I can just sort the list by modifier. > I will also submit a cleaned-up version of the common/def-keys file. There > are some obvious clean-ups and some "maybe": > > - 3 bindings of 'a' to "apply" (to handle different shift state and modifier > states). Replace with a single binding of 'a' with "Any" flag. In hindsight, there are some issues with setting the directional keys with the "Any" flag. I usually bind ALT-B to 'cast burning hands', but it conflicts with the 'Any' definition of a NetHack-style direction key. Perhaps the 'Normal' checkbox should come back? > - 2 of 'e' to examine (shift state). Replace with single binding of 'e'. There should just be one examine command, "examine." I think it should be bound to normal and CTRL. > - What's the difference between the "take" and the "pickup" commands? (',', > '@') The 'pickup' binding should probably go. In NetHack, '@' toggles auto-pickup, but Crossfire's 'pickup' command requires an argument. Perhaps it was left over from a long time ago. > - How often do we get new players who use Sun Type 4 Keyboards? Perhaps these > could go? (17 bindings.) Admittedly, not that often. Binaries aren't even being built for modern Sun machines (with normal keyboards). > - Is there a difference between "rotateshoottype -" and "rotateshoottype -1"? > Also needs modifier flags cleanup (A/N/NF). Not exactly sure, they *seem* to do the same :p > These I don't really know about: > > - I've never seen the "Nethack-Style" key layout before. Also, they don't seem > to work in conjunction with the Fire modifier (only N and R). Does the fact > that that bug has never been fixed mean they aren't used at all, perhaps? Or > do people just fix that when they start to play? I've always used NetHack style keys, and they've been working fine all the time. After the update some interesting things are happening, which I'm working on investigating. > - Arrow keys... I *really* like the feature of command history and the prevkey/ > nextkey that is available. But these are not bound by default, so perhaps they > aren't used as much as they could be. On the other hand, using the arrow keys > for this (and not for north/south etc) requires an immidiate help text whenever > a new character is started, to explain how to move. Thing with Crossfire is that we don't have a "pop-up-on-your-screen" tutorial at the beginning. And if players start by using the arrow keys (based on intuition), they probably won't discover the other ways to move, either. Thanks, Kevin Zheng From arvidb at kth.se Sun Nov 3 11:15:59 2013 From: arvidb at kth.se (Arvid Brodin) Date: Sun, 03 Nov 2013 18:15:59 +0100 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <527670D4.6050701@gmail.com> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> <527662AD.2050702@kth.se> <527670D4.6050701@gmail.com> Message-ID: <527684CF.9010301@kth.se> On 2013-11-03 16:50, Kevin Zheng wrote: > On 11/03/2013 08:50, Arvid Brodin wrote: [] >> - 3 bindings of 'a' to "apply" (to handle different shift state and modifier >> states). Replace with a single binding of 'a' with "Any" flag. > > In hindsight, there are some issues with setting the directional keys > with the "Any" flag. I usually bind ALT-B to 'cast burning hands', but > it conflicts with the 'Any' definition of a NetHack-style direction key. > Perhaps the 'Normal' checkbox should come back? It does conflict. Before, you were allowed to enter conflicting keybindings, and now, you are not. The order the keybinds were made mattered before. Look at parse_key() in the old code. They find several matches: first_match, then tries to find a perfect match (keyentry), then proceeds to completely ignore the keyentry match... You can solve this easily enough. You should create separate bindings for all of the direction keys with no modifers, with Run modifiers, and with Fire modifiers. Then you can also bind Alt + 'b' to cast burning hands. This might seem a bit complicated, but it has two IMO large pros: * We can skip special handling of the Run and Fire modifiers in the future. Instead of giving Shift and Control special meanings if used in conjunction with a direction key, the user simply creates bindings for 'east', 'run east', 'fire east' etc. These can be set up so that they work exactly like today. * It is transparent to the end user - he/she can see exactly what happens. No hidden special treatment of the Shift and Control keys. I really need to take a good look at the def-keys file though... >> - I've never seen the "Nethack-Style" key layout before. Also, they don't seem >> to work in conjunction with the Fire modifier (only N and R). Does the fact >> that that bug has never been fixed mean they aren't used at all, perhaps? Or >> do people just fix that when they start to play? > > I've always used NetHack style keys, and they've been working fine all > the time. After the update some interesting things are happening, which > I'm working on investigating. I think this is a problem with my code. The default Nethack-style bindings look like this (from common/def-keys): b 1 NR southwest h 1 NR west j 1 NR south k 1 NR north l 1 NR east n 1 NR southeast u 1 NR northeast y 1 NR northwest Logically that means they should work if no modifier keys are pressed, or with Run pressed. (Are you saying they work with Fire pressed as well?) Anyway, this needs to be expressed with two keybindings in my code: one with no modifiers (called "None" in the keybindings dialog), and one with the "Run" modifier. My code ignores the 'N' here since it means "no flags" and only looks at the 'R' - which of course breaks things. I will figure out a solution. >> - 2 of 'e' to examine (shift state). Replace with single binding of 'e'. > > There should just be one examine command, "examine." I think it should > be bound to normal and CTRL. It looks like this today: e 1 RF examine E 1 RF examine I.e. it is bound to Run and Fire (and not Normal). And the double bind is used since 'e' and 'E' have different key codes. My code converts all key codes to lowercase, since shift state is treated separately anyway. >> - Arrow keys... I *really* like the feature of command history and the prevkey/ >> nextkey that is available. But these are not bound by default, so perhaps they >> aren't used as much as they could be. On the other hand, using the arrow keys >> for this (and not for north/south etc) requires an immidiate help text whenever >> a new character is started, to explain how to move. > > Thing with Crossfire is that we don't have a "pop-up-on-your-screen" > tutorial at the beginning. And if players start by using the arrow keys > (based on intuition), they probably won't discover the other ways to > move, either. You don't think a text in the message pane would be enough? Hmm, maybe not... -- Arvid From arvidb at kth.se Sun Nov 3 12:18:27 2013 From: arvidb at kth.se (Arvid Brodin) Date: Sun, 03 Nov 2013 19:18:27 +0100 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <527684CF.9010301@kth.se> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> <527662AD.2050702@kth.se> <527670D4.6050701@gmail.com> <527684CF.9010301@kth.se> Message-ID: <52769373.2020707@kth.se> On 2013-11-03 18:15, Arvid Brodin wrote: > On 2013-11-03 16:50, Kevin Zheng wrote: >> On 11/03/2013 08:50, Arvid Brodin wrote: > > [] > >>> - 3 bindings of 'a' to "apply" (to handle different shift state and modifier >>> states). Replace with a single binding of 'a' with "Any" flag. >> >> In hindsight, there are some issues with setting the directional keys >> with the "Any" flag. I usually bind ALT-B to 'cast burning hands', but >> it conflicts with the 'Any' definition of a NetHack-style direction key. >> Perhaps the 'Normal' checkbox should come back? > > It does conflict. Before, you were allowed to enter conflicting keybindings, > and now, you are not. The order the keybinds were made mattered before. Look > at parse_key() in the old code. They find several matches: first_match, then > tries to find a perfect match (keyentry), then proceeds to completely ignore > the keyentry match... > I took another look at this code and the keyentry isn't ignoread at all. The code actually searches through the bindings to find a "perfect" match - if no such match is found, it selects the first match found that matches any of the key modifier flags set. -- Arvid From mwedel at sonic.net Sun Nov 3 13:29:30 2013 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Nov 2013 11:29:30 -0800 Subject: [crossfire] [RFC 2/3] Misc keybinding fixes and changes In-Reply-To: <5275BFAA.1040206@gmail.com> References: <526EF0F2.7000208@kth.se> <5271978D.8000701@gmail.com> <5271AD05.1070804@kth.se> <5272E69B.9030000@gmail.com> <5275227B.8020308@kth.se> <5275BFAA.1040206@gmail.com> Message-ID: <5276A41A.6050302@sonic.net> On 11/ 2/13 08:14 PM, Kevin Zheng wrote: > On 11/02/2013 11:04, Arvid Brodin wrote: >> I noticed the gtk client code is split between the folders common/ >> and gtk-v2/. I found references to something called the x11 client >> in the code, and I assumed that that was an old client that had since >> been removed. It was apparently called cfclient, later renamed >> crossfire-client-x11. If this has been removed, perhaps it would be a >> good idea to merge the common/ folder into the gtk-v2/ folder? > > You've probably noticed that the sources in common/ are built into a > shared library. The intention was to share some code between the several > different versions of the client (X11, SDL, OpenGL, GTKv1, GTKv2). Now, > it seems a little unnecessary (unless someone decides to bring back > another client). But to me, there is very little reason to merge them - the common area vs the specific graphic area are pretty well abstracted apart. And while right now there might only be one graphics client that uses it, if they get merged, that pretty much would mean that would always be the case. In terms of history, early version of the client only had X11 client support - the fact it was separated made it possible to have different GUI clients at different times (gtkv1 vs gtkv2, and I think there was a gnome client at some point). Now whether there will ever be new graphics system ever added the the C client (vs java), who knows, but off the top of my head, I could think of several platforms where a native GUI client could be written, and who knows what changes may show up even on the unix desktops which might bring forth a new client with new toolkit. If there are specific issues or problems trying to be addressed by merging them together, that would be good to hear (and perhaps could be fixed without a merge). But just merging them for the sake of merging may not be good long term. From mwedel at sonic.net Sun Nov 3 13:36:46 2013 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Nov 2013 11:36:46 -0800 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files In-Reply-To: <52758B5F.5030608@kth.se> References: <52758B5F.5030608@kth.se> Message-ID: <5276A5CE.7030700@sonic.net> On 11/ 2/13 04:31 PM, Arvid Brodin wrote: > Today, keybindings are saved as ~/.crossfire/keys. That means you > cannot have different key bindings for each character. > > This patch changes that so that keybindings are saved as > ~/.crossfire/.keys. So if your character is named > Leopold, the keybindings are saved to ~/.crossfire/Leopold.keys. > > When play is entered with a character, the client tries to load > keybindings in the following order: > > ~/.crossfire/.keys > ~/.crossfire/keys > /def_keys > > If none of the files are found, it instead uses the default built- > in keybindings. Just a question - is there any way to set up 'global' keybindings (eg, those that apply to all characters)? From my reading above, which may not be correct, it suggests that once it finds a matching keys file, it won't go to the next one (so if you have a foobar.keys file, it will load that and won't load anything you have set up in keys). I'm not sure how prevalent it is, but I know for myself that I have some keybindings that would apply to all characters, and it would be a bit of a pain to re-enter them each time a new character is created (now I suppose this can be done as a manual process of having a template file that I manually copy over as I make new characters) That said, certainly have per character keys file is also a good thing, since a lot of things are per character. My only thought here is that it loads up ~/.crossfire/keys regardless, but values in .keys override any settings there, and in the bind window, have an option for the keybinding which is something like 'global (all character)' option. From mwedel at sonic.net Sun Nov 3 13:56:39 2013 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Nov 2013 11:56:39 -0800 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <527662AD.2050702@kth.se> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> <527662AD.2050702@kth.se> Message-ID: <5276AA77.20104@sonic.net> On 11/ 3/13 06:50 AM, Arvid Brodin wrote: > > - How often do we get new players who use Sun Type 4 Keyboards? Perhaps these > could go? (17 bindings.) Some of those still can apply for later sun keyboards (using a type 7 here). Since later keyboards are USB, they work fine on PCs also. I suspect the F ones can certainly go. The KP_ seem to depend on if numlock is on or off, so in theory can go, but at same time, I suspect would apply to non sun keyboards if numlock is off. That said, hitting numlock is not hard, although perhaps a warning in the client could be added (Your numlock key is off - movement via the keypad will not work until you turn it on) type of thing. I believe there is some way to get that status with gtk. > These I don't really know about: > > - I've never seen the "Nethack-Style" key layout before. Also, they don't seem > to work in conjunction with the Fire modifier (only N and R). Does the fact > that that bug has never been fixed mean they aren't used at all, perhaps? Or > do people just fix that when they start to play? Not specific to that, but I suspect people playing on laptops/notebooks lack the numeric keypad, and just using the 4 direction keys is limiting (there are probably circumstances where you really need to move or fire diagonally) > > - Arrow keys... I *really* like the feature of command history and the prevkey/ > nextkey that is available. But these are not bound by default, so perhaps they > aren't used as much as they could be. On the other hand, using the arrow keys > for this (and not for north/south etc) requires an immidiate help text whenever > a new character is started, to explain how to move. I suspect some of that is command history is a more recent feature and keybinding was never added for it (there are probably lots of commands which could use keybindings but are lacking them) Certainly help text could be updated. I wonder if they could be bound to page up/page down by default (for keyboards that have that - see notebook issue above) - this way, they will still apply in keybindings for all users, so people could rebind them to other keys as they see fit. From arvidb at kth.se Sun Nov 3 14:40:18 2013 From: arvidb at kth.se (Arvid Brodin) Date: Sun, 03 Nov 2013 21:40:18 +0100 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files In-Reply-To: <5276A5CE.7030700@sonic.net> References: <52758B5F.5030608@kth.se> <5276A5CE.7030700@sonic.net> Message-ID: <5276B4B2.6060102@kth.se> On 2013-11-03 20:36, Mark Wedel wrote: > On 11/ 2/13 04:31 PM, Arvid Brodin wrote: >> Today, keybindings are saved as ~/.crossfire/keys. That means you >> cannot have different key bindings for each character. >> >> This patch changes that so that keybindings are saved as >> ~/.crossfire/.keys. So if your character is named >> Leopold, the keybindings are saved to ~/.crossfire/Leopold.keys. >> >> When play is entered with a character, the client tries to load >> keybindings in the following order: >> >> ~/.crossfire/.keys >> ~/.crossfire/keys >> /def_keys >> >> If none of the files are found, it instead uses the default built- >> in keybindings. > > Just a question - is there any way to set up 'global' keybindings (eg, those that apply to all characters)? > > From my reading above, which may not be correct, it suggests that once it finds a matching keys file, it won't go to the next one (so if you have a foobar.keys file, it will load that and won't load anything you have set up in keys). > > I'm not sure how prevalent it is, but I know for myself that I have some keybindings that would apply to all characters, and it would be a bit of a pain to re-enter them each time a new character is created (now I suppose this can be done as a manual process of having a template file that I manually copy over as I make new characters) When you start play with a new character, the /def_keys would be loaded, or ~/.crossfire/keys if you have such a file. So you won't start without any keybindings. I have not added a way to configure "global" keys for all characters. How would you handle the case where a new or modified global key binding conflicts with a character-specific binding (also see below)? Also, I've not added an in-game way to say "use the current key bindings for all new characters". This could be done manually by copying a character's .keys file to ~/.crossfire/keys, though. > > That said, certainly have per character keys file is also a good thing, since a lot of things are per character. > > My only thought here is that it loads up ~/.crossfire/keys regardless, but values in .keys override any settings there, and in the bind window, have an option for the keybinding which is something like 'global (all character)' option. One would have to figure out how the override should be done. Say you have Kevin Zheng's case where the direction keys are "Any" - i.e. they should work regardless of modifier state. Then add binding for Alt-'b' which conflicts with the Any binding for 'b' - should we then make the direction key 'b' work with any modifier state (None, Ctrl, Shift, Meta, Ctrl+Shift, Ctrl+Alt, Shift+Alt, Ctrl+Shift+Alt, Meta+...) except Alt-'b'? Or should the direction key 'b' be overridden completely? -- Arvid From kevinz5000 at gmail.com Sun Nov 3 17:03:06 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 03 Nov 2013 17:03:06 -0600 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files In-Reply-To: <5276A5CE.7030700@sonic.net> References: <52758B5F.5030608@kth.se> <5276A5CE.7030700@sonic.net> Message-ID: <5276D62A.1030105@gmail.com> 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. Thanks, Kevin Zheng From mwedel at sonic.net Mon Nov 4 00:38:11 2013 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Nov 2013 22:38:11 -0800 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files In-Reply-To: <5276D62A.1030105@gmail.com> References: <52758B5F.5030608@kth.se> <5276A5CE.7030700@sonic.net> <5276D62A.1030105@gmail.com> Message-ID: <527740D3.3000201@sonic.net> 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. 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 From arvidb at kth.se Mon Nov 4 07:34:53 2013 From: arvidb at kth.se (Arvid Brodin) Date: Mon, 04 Nov 2013 14:34:53 +0100 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files In-Reply-To: <527740D3.3000201@sonic.net> References: <52758B5F.5030608@kth.se> <5276A5CE.7030700@sonic.net> <5276D62A.1030105@gmail.com> <527740D3.3000201@sonic.net> Message-ID: <5277A27D.4060007@kth.se> 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 From arvidb at kth.se Mon Nov 4 17:41:27 2013 From: arvidb at kth.se (Arvid Brodin) Date: Tue, 05 Nov 2013 00:41:27 +0100 Subject: [crossfire] [PATCH] Fix keybinding bug when connected to server-1.12 Message-ID: <527830A7.2060801@kth.se> As the subject says. The patch should apply to client trunk rev 19091. The fix is in three parts: * If no character name is given (is NULL), don't load or save character-specific keys file. * Load key bindings directly on startup, when name is NULL. * If playing on a server with a login process, set the character name and load key bindings again. Also, please do not modify the patches when applying them since it messes up any patches that I have queued. If something should be changed, tell me what and I'll generate a new one. Thanks, Arvid -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-keybinding-bug-when-connected-to-server-1.12.patch Type: text/x-patch Size: 4511 bytes Desc: not available URL: From kevinz5000 at gmail.com Mon Nov 4 18:24:43 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 04 Nov 2013 18:24:43 -0600 Subject: [crossfire] [PATCH] Fix keybinding bug when connected to server-1.12 In-Reply-To: <527830A7.2060801@kth.se> References: <527830A7.2060801@kth.se> Message-ID: <52783ACB.90305@gmail.com> On 11/04/2013 17:41, Arvid Brodin wrote: > As the subject says. > > The patch should apply to client trunk rev 19091. Committed in r19094, thanks! > Also, please do not modify the patches when applying them since > it messes up any patches that I have queued. If something should > be changed, tell me what and I'll generate a new one. Point taken. Thanks, Kevin Zheng From kevinz5000 at gmail.com Mon Nov 4 18:41:30 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 04 Nov 2013 18:41:30 -0600 Subject: [crossfire] Use of svn:externals in client code on SVN Message-ID: <52783EBA.6030105@gmail.com> Hi there, Crossfire currently uses svn:externals to sync protocol definition headers between the server and GTKv2 client. While this has its merits, overall I believe it is confusing, cumbersome, and harmful. >From the SVN Book [1]: "An externals definition is a mapping of a local directory to the URL?and ideally a particular revision?of a versioned directory. In Subversion, you declare externals definitions in groups using the svn:externals property." My guess is that the original intention of using them was to ensure that the client protocol headers would always remain in sync with those in the server. However, here are some issues: - The svn:externals property must still be modified manually - Copy/paste/merge is faster, less confusing, and works outside of SVN - Client sources locked to server, JXClient proves unnecessary Further, there are several disadvantages to using them as well: - It only works with SVN - hinders future migration (if ever) - Confusing for people not familiar with SVN - Slow, try running `svn up` from the root and wait - Breaks `git svn`, which pacifies the impatient Git users I propose that we go back to manually tracking the protocol headers between the client and server. They are not updated that often, anyways, and still need updating with the use of svn:externals. We can continue using svn:externals in /latest, etc. [1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html Thanks, Kevin Zheng From mwedel at sonic.net Mon Nov 4 23:35:14 2013 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Nov 2013 21:35:14 -0800 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files In-Reply-To: <5277A27D.4060007@kth.se> References: <52758B5F.5030608@kth.se> <5276A5CE.7030700@sonic.net> <5276D62A.1030105@gmail.com> <527740D3.3000201@sonic.net> <5277A27D.4060007@kth.se> Message-ID: <52788392.40003@sonic.net> 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. From mwedel at sonic.net Tue Nov 5 00:00:07 2013 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Nov 2013 22:00:07 -0800 Subject: [crossfire] Use of svn:externals in client code on SVN In-Reply-To: <52783EBA.6030105@gmail.com> References: <52783EBA.6030105@gmail.com> Message-ID: <52788967.3030506@sonic.net> On 11/ 4/13 04:41 PM, Kevin Zheng wrote: > Hi there, > > Crossfire currently uses svn:externals to sync protocol definition > headers between the server and GTKv2 client. While this has its merits, > overall I believe it is confusing, cumbersome, and harmful. > > From the SVN Book [1]: "An externals definition is a mapping of a local > directory to the URL?and ideally a particular revision?of a versioned > directory. In Subversion, you declare externals definitions in groups > using the svn:externals property." > > My guess is that the original intention of using them was to ensure that > the client protocol headers would always remain in sync with those in > the server. However, here are some issues: > > - The svn:externals property must still be modified manually > - Copy/paste/merge is faster, less confusing, and works outside of SVN > - Client sources locked to server, JXClient proves unnecessary > > Further, there are several disadvantages to using them as well: > > - It only works with SVN - hinders future migration (if ever) > - Confusing for people not familiar with SVN > - Slow, try running `svn up` from the root and wait > - Breaks `git svn`, which pacifies the impatient Git users > > I propose that we go back to manually tracking the protocol headers > between the client and server. They are not updated that often, anyways, > and still need updating with the use of svn:externals. We can continue > using svn:externals in /latest, etc. > > [1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html That is fine by me. And before the externals was set up, my method of sync wast just a cp from one directory to the other. From kevinz5000 at gmail.com Wed Nov 6 18:06:22 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Wed, 06 Nov 2013 18:06:22 -0600 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <5276AA77.20104@sonic.net> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> <527662AD.2050702@kth.se> <5276AA77.20104@sonic.net> Message-ID: <527AD97E.5010204@gmail.com> On 11/03/2013 13:56, Mark Wedel wrote: > The KP_ seem to depend on if numlock is on or off, so in theory > can go, but at same time, I suspect would apply to non sun keyboards if > numlock is off. That said, hitting numlock is not hard, although > perhaps a warning in the client could be added (Your numlock key is off > - movement via the keypad will not work until you turn it on) type of > thing. I believe there is some way to get that status with gtk. In my opinion, the client should only accept the arrow keys when the number lock is off. That said, I don't see a reason to change this now since it really isn't broken. > Not specific to that, but I suspect people playing on laptops/notebooks > lack the numeric keypad, and just using the 4 direction keys is limiting > (there are probably circumstances where you really need to move or fire > diagonally) I'm a regular user of the NetHack-style layout. It was working before the new patches were introduced; somehow it seems to be in conflict with the arrow keys. I'll be looking at how to fix it. > I suspect some of that is command history is a more recent feature and > keybinding was never added for it (there are probably lots of commands > which could use keybindings but are lacking them) But new users will probably find arrow keys more intuitive. There should be a way to spoon-feed new users key commands without annoying experienced players. Thanks, Kevin Zheng From kevinz5000 at gmail.com Wed Nov 6 18:11:10 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Wed, 06 Nov 2013 18:11:10 -0600 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <527684CF.9010301@kth.se> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> <527662AD.2050702@kth.se> <527670D4.6050701@gmail.com> <527684CF.9010301@kth.se> Message-ID: <527ADA9E.9000704@gmail.com> On 11/03/2013 11:15, Arvid Brodin wrote: > I think this is a problem with my code. > The default Nethack-style bindings look like this (from common/def-keys): > > Logically that means they should work if no modifier keys are pressed, or with > Run pressed. (Are you saying they work with Fire pressed as well?) I've cleared out my old key bindings and have the client running from defaults. The NetHack style keys don't work in "normal" mode, but do when CTRL is pressed. > Anyway, this needs to be expressed with two keybindings in my code: one with no > modifiers (called "None" in the keybindings dialog), and one with the "Run" > modifier. My code ignores the 'N' here since it means "no flags" and only looks > at the 'R' - which of course breaks things. I will figure out a solution. I'll try to break them down into two bindings for each command. But this seems cumbersome and bloated, and deserves to be fixed. Thanks, Kevin Zheng From kevinz5000 at gmail.com Wed Nov 6 18:18:04 2013 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Wed, 06 Nov 2013 18:18:04 -0600 Subject: [crossfire] [PATCH 2/2] Character-specific keybinding files In-Reply-To: <52788392.40003@sonic.net> References: <52758B5F.5030608@kth.se> <5276A5CE.7030700@sonic.net> <5276D62A.1030105@gmail.com> <527740D3.3000201@sonic.net> <5277A27D.4060007@kth.se> <52788392.40003@sonic.net> Message-ID: <527ADC3C.3080800@gmail.com> On 11/04/2013 23:35, Mark Wedel wrote: > 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. Considering the small group of players we have, in my opinion it's worth providing backwards compatibility. Metalforge and Invidious have been the "de facto" public servers, and I imagine that many players have invested significant time on both. Thanks, Kevin Zheng From arvidb at kth.se Thu Nov 14 18:03:44 2013 From: arvidb at kth.se (Arvid Brodin) Date: Fri, 15 Nov 2013 01:03:44 +0100 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <527ADA9E.9000704@gmail.com> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> <527662AD.2050702@kth.se> <527670D4.6050701@gmail.com> <527684CF.9010301@kth.se> <527ADA9E.9000704@gmail.com> Message-ID: <528564E0.9020902@kth.se> On 2013-11-07 01:11, Kevin Zheng wrote: > On 11/03/2013 11:15, Arvid Brodin wrote: >> Anyway, this needs to be expressed with two keybindings in my code: one with no >> modifiers (called "None" in the keybindings dialog), and one with the "Run" >> modifier. My code ignores the 'N' here since it means "no flags" and only looks >> at the 'R' - which of course breaks things. I will figure out a solution. > > I'll try to break them down into two bindings for each command. But this > seems cumbersome and bloated, and deserves to be fixed. I've been thinking about this a bit. Hitherto, we've presented all keys equally to the user (direction keys look no different than other keys in the interface). But we've treated them differently internally, using the run and fire "hacks" - so even though they appear no different than other keys to the user, they actually work differently in combination with the modifier keys. This has also caused the "Run" and "Fire" modifiers to be mixed in with the Ctrl and Shift modifiers for other keys. Confusing is the word, I think. My patches aim to treat all keys in the same way internally - no "hacks". This also means the user does not get the benefits of the "special internal tratment" that was given before. Cumbersome seems like a fitting description. Perhaps what we should do is the exact opposite of what's been done before: give the direction keys special treatment in the _interface_, but not in the code. That could mean adding a new part to the Keybindings dialog, where you bind the keys for "North", "South", etc, and also select the modifier keys to use for Run and Fire. Internally, the three needed bindings per key could then be created automatically. Of course, we would have to agree about the default set of direction keys... ;) -- Arvid From leaf at real-time.com Thu Nov 14 18:36:49 2013 From: leaf at real-time.com (Rick Tanner) Date: Thu, 14 Nov 2013 18:36:49 -0600 Subject: [crossfire] [PATCH 1/2] Keybindings: multiple changes In-Reply-To: <528564E0.9020902@kth.se> References: <52758994.1060905@kth.se> <5275C5D3.1020109@gmail.com> <527662AD.2050702@kth.se> <527670D4.6050701@gmail.com> <527684CF.9010301@kth.se> <527ADA9E.9000704@gmail.com> <528564E0.9020902@kth.se> Message-ID: <52856CA1.3000808@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/14/13 6:03 PM, Arvid Brodin wrote: > > Of course, we would have to agree about the default set of > direction keys... ;) It's been my observation that the first thing a new player does when they want to move their character - is to use the arrow keys. So, I think the arrow keys need to remain available for movement. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFShWyhhHyvgBp+vH4RAu/xAKDdUAhI4hLe89RNAIk4o/zjCpM3HgCgsDzp DvtdJtUuzCXaiBn3k+jMm94= =C+JF -----END PGP SIGNATURE-----