|
History
| Log In
|
|
|
|
|
|
[
Permlink
| « Hide
]
Silver Csak - 09/Apr/08 09:45 PM
I dont think SJ should mess with the systems thst are in place and hamper the C:SI methods that are in place now. We appreciate performancr breakthrughs but to hamper the sword play with the dash problem is unwarranted,,, thankyou,,,Silver Csak
Silver: isn't that comment supposed to be on VWR-6232?
Wow this would make it possible to get the snap shot to disk short cut to work on my keyboards, there is some problem with he dead keys combination on the swedish keyboard layout and that short cut.
Rather than adding fixed options for the interface (such as the 5 radio buttons for Start Run and another 5 for Stop Run), why not just allow the user to specify which keys to be pressed to perform that function, and to specify whether the keys should be held or simply pressed to toggle. This would make it possible for people (like a friend of mine) with non-standard keyboard configurations (Dvorak in his case) to remap their keyboards to the same locational configuration as the standard QWERTY configuration, if they so chose.
You mean something like this?
Start Run = [Key...|v] [Control-R] Clicking on the selected box would capture a keystroke or combo. The pull-down would include: None, Key..., Double-key..., Key release, Click..., Click-and-hold..., and so on. Full key mapping in the UI would be very useful. It's something lots of games have done for years, from what I've seen usually with a clickable box that then just capures the next keypress, as you say.
Not a big gamer so I don't have much hanging around to look at, but would be worth a review of how other products provide this interface to see what works best. I am against this, the Alt/Ctrl-Alt/Shift-Ctrl-Alt key combinations to control the camera is one of the most powerful interface "standards" in SL, in fact it is so natural after you have learnt it that you find yourself doing it in webpages and excel spreadsheets.
To offer an override will (1) make this section of the code more complex (2) cause people to not learn keyboard toggles for camera (3) increase support load (4) confuse new players you are training / add in extra steps No one is suggesting that standard be changed? If anything this is about protecting it, so that we are able to retain the mappings we are used to if and when they change, as has happened with VWR-6232.
This issue has implications way beyond the reasons Argent originally proposed it. It is about adding choice where needed and would be a big step forward for accessibility. Anecdotally SL has a high proportion of disabled users who benefit from it greatly, and that is something to be celebrated and expanded if possible by making it adaptable to their individual needs. Not everyone is physically able to press a key along with three modifier keys simultaneously for example. 1) A layer of abstraction to assign key mappings from one place might actually make the code more manageable, and possibly provide useful hooks for controlling the client with alternate interface devices. In tandem with the new analog joystick support, this could be expanded allow them to assign spare joystick buttons to whatever controls they prefer, voice PTT, build controls or whatever suits their personal use of SL. 2) What leads you to think they would choose to reinvent the wheel without good reason, rather than learn the existing controls? By that logic we should remove the camera and movement control floaters too because they encourage people to not use the keyboard controls. 3 & 4) That is certainly important, but there is no reason a new user need ever see this, unless they have a problem using the standard control setup for reason of disability, non-standard key layout or whatever, in which case they are likely to go looking for it in the preferences. If absolutely necessary it can be accessed through the Advanced menu to prevent confusion. It would also provide a single place of reference to go and see what key does what, which would never be out of date unlike static documentation on the Wiki etc which relies on people going and updating it manually whenever something is changed or introduced. On the rare occasions I play games the first thing I usually do is to open the keymapping options if possible to just see what they are. I'm not sure that I understand why you think I'm proposing eliminating the existing camera controls, Sean. Can you explain what I wrote that led you to this supposition? I will endeavor to clarify things for you if you offer me the opportunity.
I changed the title from "Allow full user control of command keys" to "Implement User Definable input mapping" to reflect that this involves a much wider potential than merely "command" keys. If the OP is offended by that please change it back with my apologies.
With the long over due addition of joystick input, this should be addressed intelligently...once and for all...IMO. I'm also going to try linking this in with joystick issues, and the "Usability" Meta Issue. User definable key input has been a common game feature at least since early '90s DOS games. With 5fps *sim* times commonplace, the extra nano-second *client* resource this feature will eat up is so negligible. Scancodes are difficult to "explain" in a GUI, so yes most use a "push this button" and then capture the next incoming scancode. This simplifies modifier keys (Shift/Ctrl/Alt), instantly solves localization, instantly solves accessibility, but makes combos such as double-tap impossible. :-/ Personally, with a full keyboard available, I think double-tap is an acceptable casualty. Push-to-Talk already has a definable key?!?
I've never used voice chat, but the prefs page has an ability to set a user defined key for Push-to-Talk. It's the push-a-button and capture the next keycode type. So this already exists. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Implement User Definable input mapping
