Get community help for technical problems
NeatNit wrote:All I know is that when I change to hebrew and the program I'm in doesn't support hebrew, it shows this crap.
That's a different issue to do with character encodings - when an incorrect character encoding/set is chosen to convert the raw data into readable characters, this results in a series of mismatching characters and seemingly random garbage appearing on your screen. The most recognizable artefact of this is a plain rectangle which is for an out-of-range character of the current encoding. In slightly less mismatching encodings (such as UTF-8 and ISO-8859-1) only some characters will show up as mangled heaps of pixels (in the case of this example, accents and other pieces of punctuation usually get lost).
In short, it has nothing to do with keyboard layout.
"The ships hung in the sky much the same way that bricks don't."
- Douglas Adams
- Douglas Adams
Kuth wrote:...I was under the same assumption you were Fish, that a US keyboard would use UK settings as...
Uh, I don't think I was under that impression at all. I have 3 set ups for my US keyboard;
US english, because it's an american keyboard.
UK english, so I can type in £ signs if I ever need to, or get at ¬ and ¦...
And US Dvorak, because Dvorak is a nightmare.
Before I set up these additional layouts, just having US english (because I have a US keyboard on this computer, and back when this was posted, I was using a laptop with a UK keyboard), multiwinia has since used en_US.txt, which is why I even have it. When starting it up now, I would have expected Multiwinia to detect which keyboard profile was in use at start up and use that keyboards locale file, but probably never check again. It apparently doesn't do this, and in my scenario, it currently seems to be using en_UK.txt even when it probably shouldn't be.
Basically US and UK keyboards are different in that UK keyboards have 1 extra key (due to a less wide left shift) and a different shaped return key. Beyond that, at least nowerdays, it's just the way the computer interprets the input from the keyboard; my US keyboard in UK layout can quite happily give ú and ó and í etc.
Kuth wrote:Though does this mean the teamspeak is still disabled? Are the only the commands that are changed and the keys re-bound the ones that don't work in their default settings?
As an aside, what's this about, I don't really understand what you mean.
The GoldFish wrote:Basically US and UK keyboards are different in that UK keyboards have 1 extra key (due to a less wide left shift) and a different shaped return key. Beyond that, at least nowerdays, it's just the way the computer interprets the input from the keyboard; my US keyboard in UK layout can quite happily give ú and ó and í etc.
Interestingly, keyboard layouts aren't limited to just one arrangement it seems. Microsoft's own Keyboard Layout Creator has the following shapes of return keys in the options screen:
For some strange reason, it is not possible to adjust the shape of the left shift in this application (it's default short for me, perhaps because of my own keyboard so it might be long on US keyboards) but it seems they differ too, and not just between UK and US layouts.
Supposedly, this is default USI:
And this is default UK:
However, my keyboard is set as USI in Windows but has the key arrangement of a UK keyboard:
And this is not too rare a layout as I've seen it multiple times. The keyboard I'm using by the way is this thing, but as you can see most PR images use the common USI arrangement.
Now I really don't know if there is any logic in all of this, but the fact is that a keyboard layout is usually limited to key assignments, with arrangements not always playing that important a role.
Though does this mean the teamspeak is still disabled? Are the only the commands that are changed and the keys re-bound the ones that don't work in their default settings?
I mean I'm basically asking if the chat keys are disabled now since I've re-defined my key settings. Would I have to define them specifically in en_Us.txt or do they remain unchanged so long as the key binding is not changed in the .txt file?
Uhm, nothing gets disabled. The only time anything got disabled was if you didn't update a 1.0 input_preferences.txt when it got updated in 1.1, which I bang on about in the initial post of this topic. If you use the (generally cleaner) keyboard locales to bind anything to a key that was already bound, then I expect it probably only performs that action, so if you bound moveforwards to z you might not be able to zoom in. Teamspeak is a 3rd party app that I don't see how this has anything to do with... is there some keybind I don't know about? Regardless if there is, find what it would be in input_preferences.txt and rebind it in your keyboards file.
-- The GoldFish - member of former GIT and commander in chief of GALLAHAD. You could have done something, but it's been fixed. The end. Also, play bestgameever!
Who is online
Users browsing this forum: No registered users and 8 guests