CLONE - Re-open MC-630 (Keyboard binding bug); it was prematurely closed.

Let's give this another shot:

Please explain IN DETAIL what you mean by:

However, Minecraft handles it like:
1234567890-=
QWEPYFGCRL[]\ AOEUIDHTNS'
ZQJKXBMWVZ

Because when I test it, the chat works as it should and the keybinds are on the correct keys eventhough the textual representation in the configwindow is wrong.
As I've explained in the other thread, there is no way in LWJGL to obtain the charactercode for a keycode when it is not being pressed and thus loading a binding configuration 'goes wrong' because it displays the raw keycode locations (KEY_Q is always KEY_Q eventhough it has charactercode ';' on OSX. As LWJGL is the only player who has this mapping there is no way for Mojang to figure out the proper character for display.

You are claiming that your keyboard map has two Q,Z,E and W's ? How did you check this? Where did things show up double?

I've had lengthy discussions with the LWJGL people and their opinion is basically that the Mojang developers are retards and that LWJGL (demonstrably) works correcly; it's not just used properly; hence my suggestions about the changes.

Please tell me with which developer of LWJGL you've been talking, over which medium (email/irc/?) and show me a log of the chat. That would probably give us some more useful information than you are providing.

TL;DR:

Again, I cannot replicate the problem, I do not have duplicate keys in my mapping, I'm testing this on a 15" Retina macbook running 10.8.2 with setting my keyboard mapping to 'Dvorak'

Also feel free to not be so aggressive, if a problem doesn't get solved there are good reasons for it. Right now the reasons are that you are providing unreproducable information (and a horrifying attitude). Tails closed the ticket perhaps a tiny bit fast but you've never actually responded to what I said, I advise you to do so and rant a bit less.

Grum: Try binding for instance "both E's" (on QWERTY E and D / Dvorak . and E), which are the forward and backward keys for me in all games. Both become backwards keys. Same for any other duplicate. They show up in red in the configuration panel and only one of them work in the game. In the in-game chat, otoh, all characters work normally, it's just the game controls themselves that don't work properly.

For the people using keyboards with no direct number keys, it's reported the 1234567890 hotkeys don't work and it's a related issue, which was closed as a duplicate of MC-630. I don't remember the number of that ticket from the back of my head.

I'm on the exact same setup as you, a Retina MacBook Pro and 10.8.2. No mods installed etc, and running the latest minecraft (1.4.7 last time I checked).

As for the irc chat with the LWJGL people, I did not save the transcript, but the online Java Applet demos using key bindings worked, which indicates something in LWJGL usage, not LWJGL itself is wrong.

Also, it wasn't like this always. In Alpha versions of minecraft, they keys worked properly. I documented in which version the change happened back in the wiki bug tracker, but I guess that information is lost now.

I don't know if that helps in this context:

German keyboard layout is

asdfghjklöä#

For entering commands I have to press the # key (in US layout there is the / key there)
The / on German keyboard is Shift-7 - when pressed, goes of course to sneaking mode and selects 7th slot of hotbar.
Whe the chat line is open, pressing the # key gives (as expected) # and pressing Shift-7 gives /

In the Options -> Controls command key is set to "SLASH"

As for searching the time when this bug was introduced, these were minecraft versions that had some experimental leaning left/right keybindings, iirc, which were later removed from the game. These keys also conflicted and were hardcoded (no settings entries). The same versions also introduced for the first time the bug of keys becoming completely unresponsive or stuck, see: MC-483

Found the related report of the numbers bug, which occurs at least on the Czech keyboard: MC-62

Kumasasa's point about the german keyboard layout mistake with slash applies to e.g. finnish keyboard layout, too. In finnish keyboard the slash is also as shift-7, but to actually start the text input, we have to press *-key, which is at the same location as that # on german layout, or / in US layout.

That is, to open chat, the game apparently obeys a predefined keycode (which typically is the same for the same key location on every keyboard layout) instead of the produced character.

However, it is interesting that once the chat is open, the keys do produce correct characters (per my Finnish layout) into the chat line - pressing shift-7 produces /, pressing * produces *, etc.

In controls, the 'Command' is apparently bound to key "SLASH". I can not even try to bind it to shift-7 to see what happens, as it will immediately bind it with the shift-key only 😛

I've attached a screenshot with me moving the keys from 'qweasd' one to the right; the keys show the Qwerty names but they are bound properly.

Grum: Try binding for instance "both E's" (on QWERTY E and D / Dvorak . and E), which are the forward and backward keys for me in all games. Both become backwards keys. Same for any other duplicate. They show up in red in the configuration panel and only one of them work in the game. In the in-game chat, otoh, all characters work normally, it's just the game controls themselves that don't work properly.

Works here, one shows up as 'E' the other as '.' under both US Qwerty and Dvorak. It doesn't show up red, it doesn't register a duplicate key, in chat they are identical.

I'm on the exact same setup as you, a Retina MacBook Pro and 10.8.2. No mods installed etc, and running the latest minecraft (1.4.7 last time I checked).

Which is what makes it so strange, it works fine here, i do not get duplicates when pressing 'E' and '.' in Dvorak mode, the chat works fine. The only 'issue' is that the displayname of the keys are the QWERTY locations, which is again something only LWJGL can fix.

As for the irc chat with the LWJGL people, I did not save the transcript, but the online Java Applet demos using key bindings worked, which indicates something in LWJGL usage, not LWJGL itself is wrong.

Who did you end up talking with on irc? Was it in the public channel? (then I can find logs)

Also any testing you have done was against a completely different version of LWJGL.

That is, to open chat, the game apparently obeys a predefined keycode (which typically is the same for the same key location on every keyboard layout) instead of the produced character.

This is because you have to bind against a keycode not a charactercode because otherwise here is no way of asking LWJGL if the key is down (as you can only ask it by keycode).

The same versions also introduced for the first time the bug of keys becoming completely unresponsive or stuck, see: MC-483

Stuck keys is 100% LWJGL.

Also, it wasn't like this always. In Alpha versions of minecraft, they keys worked properly. I documented in which version the change happened back in the wiki bug tracker, but I guess that information is lost now.

There is no version-history back until then, but if you know the version that 'broke' it we could decompile ancient versions and diff them.

As with any bug, if I cannot replicate it there is no way to fix it.

What about MC-62? It is the exactly same issue, it should be reproducible rather easily. You have to get yourself Linux, though.

On my win7, when switching the keyboard layout to Dvorak, the controls settings shows correct Dvorak names for each key. Using the movement key assignment used above, I got "PERIOD" for forward, "O" for left etc, as expected and correct when using Dvorak layout.

Thus, the config window visual (key naming) issue might not exist on windows 7.

The only improvement I could think of on the code level for windows 7 would be to add character code to KeyBinding as a primary means to differentiate a key when a keyboard event is checked, and only if the character is undefined (e.g. value 0), compare the keyCode (for special keys). This isn't as obvious as it sounds, though. E.g. if the default key for command would be defined as KeyBinding("key.command", '/', 53), Finnish users would not be able to produce that '/' since it needs shift-7 (or well, with full keyboard one could use numpad division key, but that is just a lucky workaround). So in this case the default binding should be left without character, as KeyBinding("key.command", (char) 0, 53), thus forcing the user to find the correct key (as we do now anyway), or to rebind it (possibly binding it to the pair '*' 53, i.e. the *-key at the same location as US /.

Since it is near impossible for the devs to know every possible layout and thus ensure that a setting with predefined character would be usable for everyone, all the default settings would need to be left at keycodes-only, and let users redefine them as they see fit.

The addition of the check for matching character first would allow correct labels in the settings GUI for non-US layouts. That is, if character is defined and can be shown (i.e. not 1..32 or such), show that, and only if that won't work, show something like "keycode: xx". (Typically, the keycodes left to be shown should have almost always the same meaning on every layout.)

Same keys, minecraft 1.4.7, OS X 10.8.2, MacBook Retina, Dvorak layout. Not sure about circumflex, but I picked the key one row under A. The command is the slash key, which is also a Z. The forward is the dot (QWERTY-E) and backward is E (QWERTY-D).

And yes, I'm 100% sure it's vanilla minecraft and the LWJGL version bundled with it. Grum: Are you sure your LWJGL is the one shipped with minecraft?

Some keys are also impossible to bind even on QWERTY. For instance, I'd prefer the Command to be the key on the right of the left shift, which is ` on Dvorak and exists on US-QWERTY on the left of the 1 -key. It's simply listed as NONE. Same for the keycode for the § key, which is where US-QWERTY's ` -key is. There are probably others, but IMO this demonstates it's not just Dvorak layouts where key bindings are broken, and broken in the same way as listed in the description of this ticket, just NONE and NONE on the leftmost keys on the top and bottom row in addition to that.

At least on win7 platform, even if the keybinding shows "NONE", the key still works. I tried that with the (finnish < ) key right of left shift. The NONE apparently just means that the name of the key is not defined.

The proposed change/fix above of using the character instead of keycode (when available) would solve this part of the issue.

The ` (grave) key on Windows 7 works on both QWERTY and DVORAK layout for me. And yes, I am using the LWJGL bundled with Minecraft as I have never manually updated it. I will test OS X when possible.
As for the left-most bottom row key (fn), that key is hardwired in the MBP to not output anything, and cannot be detected by normal software like Java.

On another note, Minecraft was able to map my DVORAK layout perfectly fine with the expected results:
`1234567890[]
',.PYFGCRL/=\ AOEUIDHTNS-
;QJKXBMWVZ

Markku: yes, the NONE -keys apparently work. However, the duplicate ones don't. They also don't work when forced into the config file. I don't care about what's displayed as long as the keys work.

Martin: Good to hear.
Grum: 200% sure everything is vanilla here. Nothing about Java has been touched; that's on system defaults. I renamed the ~/Library/Application Support/minecraft directory too, and removed "/Applications/Minecraft.app". Then re-downloaded and had it re-install. Still, exactly the same issue.

Also, created a new user account, same issue. Tested on another mac, same issue.

Juha-Jarmo: after analyzing the relevant keyboard input code in the decompiled sources, I can say that Minecraft is not doing any kind of keyboard mapping (futile or otherwise), and it is using key codes for almost everything, including configuration and handling of bindable keys. So at least that part of the bug description is invalid. (The text input in chat also uses characters mapped by underlying systems, whether that be LWJGL or OS/drivers).

So, with the caveat of not being able to debug/trace the issue directly (I don't have a mac to begin with), I can not see a reason why two different keys would end up having the same keycode in the settings (or produce the same effect in the game), unless the underlying system produces the same keycode for different keys. At that point, Minecraft code can not do anything about it.

On Win7, I was able to get two keybindings to have the same "name" (and thus keycode) only by switching different layout active while setting the key for different actions. This is probably not the issue you're having...
... but I noticed that the problem you're having seems to relate only to keys that are special characters in Dvorak layout; perhaps some underlying system has a setting about special character keys and that one messes things up in that funky way. Sort of "if not a letter character, fall back to default layout"-rule somewhere along the way. I did not notice anything like that in Minecraft's code.

Markku: meanwhile I've been troubleshooting everything from installing and launching with Java 1.7 instead of the standard 1.6, running in 32bit mode, using latest stable and latest nightly lwjgl, etc. No effect on the issue, and mc is still the only app/game to do this. I also spent a fair while at browsing the lwjgl source, and nothing to be found there either, not at least on a glance. Meanwhile, the Java applets have become completely unsupported on this system, even Firefox has disabled Java completely now.

Ah, that's actually OS X's problem. A Java exploit was found and so Java has been disabled by Apple.
http://appleinsider.com/articles/13/01/11/zero-day-flaw-prompts-apple-to-block-java-7-from-os-x
Oracle is working on a fix:
http://appleinsider.com/articles/13/01/12/oracles-fix-for-zero-day-java-flaw-to-be-available-shortly

And yes, I'm 100% sure it's vanilla minecraft and the LWJGL version bundled with it. Grum: Are you sure your LWJGL is the one shipped with minecraft?

Actually, I am not 200% sure, I did update to 1.4.7 which normally brings in the lwjgl fresh too. After checking it seems it runs my modified 2.8.5 ... I should put that in a nice place somewhere =)

Erm, so yeah, the keyboardmap is completely messed up with Dvorak and 2.4.2+osx, yay able to replicate the problem!

To temporarily mend your problem, download the LWJGL osx alpha branch from: http://lwjgl.org/forum/index.php/topic,4711.msg26004.html#msg26004 and override the files in your Minecraft installation

You should get a bit more consistent experience eventhough the 'display value' in the binding window is still wrong.

Also, we cannot update LWJGL right now, there is no release that works on all OSs. 2.8.5 is broken on win7, fixed in the repo. anything > 2.6.x is broken on osx + java7. We're waiting for the osx-java7 branch to mature after which LWJGL can release 2.8.6/2.9.0 which we will push out for Minecraft as well, this might happen as late as 1.6 though.

Grum: Is the launcher unable to give different LWJGL versions for different Operating Systems?

@Grum: Beeing able to rebind the hotbar keys (1-9) and the shift-inventory-key (which is also used for crouch by default) would help a lot for users of different layouts.

Also I just updated LWJGL to 2.8.5 and the shift key still gets stuck after the first time I press it. The weird thing is that pressing F11 fixes it till I press shift again. (I'm using the NEO-Layout on Linux Mint 64bit) (Beeing able to rebind shift-inventory-key would atleast allow me to use another key that doesn't get stuck until it's fixed.)

Edit: Nice that you found one problem! 🙂

Grum: Ok, so apparently it takes a "horrible attitude" to fix one. Anyhow, good to finally have even a temporary solution and able to play the game without falling from heights or into lava etc because the key bindings are broken. As for the display value, I wouldn't care even if it was just showing hexadecimal values.

Martin: As for Java applets in the web browser, no it's not just Apple disabling it in Safari, it's Firefox and Chrome etc also disabling it in their browsers. Should be done on other platforms too, Java has been ridden with (cross-platform) 0-day exploits for quite a while already, and browser Java Applets were practically dead anyhow. Good riddance, I'd say. However, that's entirely offtopic and should be discussed elsewhere.

Grum: Ok, so apparently it takes a "horrible attitude" to fix one. Anyhow, good to finally have even a temporary solution and able to play the game without falling from heights or into lava etc because the key bindings are broken. As for the display value, I wouldn't care even if it was just showing hexadecimal values.

NOPE; Try that horrible attitude again and I'll get your ass banned of JIRA. I'm not joking, be respectful, even with the shit you threw my way that is what I did.
You can be persistant without having a horrible attitude.

I still believe that Tails perhaps closed the ticket too early, but in retrospect, as I said then, this is LWJGL and not Minecraft so all in all Tails did the right thing.

Grum: Is the launcher unable to give different LWJGL versions for different Operating Systems?

The Launcher is highly un-capable of almost everything, we'll fix this but it'll likely be around after 1.5 (see how vague I am? no pinning me down on this later ;D)

Grum: Then why not do it already? Why not ban all bug reporters, they're just annoying whining about bugs and stuff, right? Minecraft would be so much better without bug reports! It works so fine for you with your tweaked out dependencies that it doesn't matter what shit you distribute?

Especially early adopters should be banned, they have been whining about the same bugs for years! What good did they ever do to the game, right?

Minecraft - Reporting bugs is a privilege.

Sarcasm noted, but indeed it is. Reporting bugs has always been a privilege, not a right. The developer is not a slave forced to modify the game on the user's whim. You purchased a game, not the developer, nor any rights to report bugs and expect a fix within a short timespan.

Martin: Two years or so is a short timespan? And yes, in the commercial software world, the developer is responsible for their product. Just like an automobile maker would be responsible for fixing a car they sold with faulty brake pedals. Even more so, if they did a recall (update), where they broke it.

To me, this just sounds like Mojang is exploiting the attitude towards free open-source software and applying it to closed, commercial software.

The bug reporters are doing Mojang a favor here, not the other way around. The favor is finding and reporting bugs that would be a lost sale otherwise. Normally, software companies would need to hire their own testers. Remember that.

Are you here to report a bug, or are you here to complain about the unfairness of the world?

EDIT:
Indeed we are doing a favor - because we love Minecraft. We want to make it a better game for everyone. But raging about it is not likely to fix any bugs.

You do not give to expect something in return.

I'm here waiting-for-the-promised-ban doing my best at reminding everyone what this attitude is about, since you brought it up. This bug is still in all shipping units of Minecraft, so it's good to remind of it sometimes.
In soviet Mojang the customer must respect you.

Also, just piss me off a little bit more and my attitude of disappointment in minecraft (which I'd played more and recommended more if bugs like these were resolved in a timely manner) turns into hate towards Mojang, their developers and maybe even the game itself. It's your choice. I'm expecting an apology.

Juha-Jarmo Heinonen: It never helps to bitch about and insult developers, because that makes it more unlikely that they'll fix it as fast as possible. Just image you were working in a company and a costumer goes mad because he has a problem - would you immediately fix that?

I don't, because I'm not the slave of some guy, just because he bought our product.

Grum: Will we be able to rebind the inventory-shift-key and the hotbar-keys (1-9)? It would help a lot.

Mods: The bug is now confirmed, so you may want to change that in the bug-report.

Josh, the ability rebind more actions would be a feature request... Or if you think it is at least partially a bug, it should have its own issue, not handled as a comment in an already long chain of comments.

However, considering how badly the ("official" yet not really) forums work for feature requests...

Yeah, that's what I was thinking. Also this is no bug, it's problematic to not being able to rebind these actions. (Beside that I think that a bugtracker also should include a way to create, vote and mark feature requests.)

The only problem, of course, is that it'll be flooded with so many requests that Mojang will need 50x more mods in the bugtracker.

Josh: That's actually their problem. If they wish to ship a broken product, it's up to them. Doing that would just be very unprofessional and demonstrates their lack of skill, but as we see, these guys are total amateurs. Remember, if this was open source, it would be a different situation. These guys get paid for what they do, it's just not a hobby they do for free, like open source is usually about. However, they bitch about an open-source framework they decided to use, like that would be an excuse.

Also, just piss me off a little bit more and my attitude of disappointment in minecraft (which I'd played more and recommended more if bugs like these were resolved in a timely manner) turns into hate towards Mojang, their developers and maybe even the game itself. It's your choice. I'm expecting an apology.

Josh: That's actually their problem. If they wish to ship a broken product, it's up to them. Doing that would just be very unprofessional and demonstrates their lack of skill, but as we see, these guys are total amateurs. Remember, if this was open source, it would be a different situation. These guys get paid for what they do, it's just not a hobby they do for free, like open source is usually about. However, they bitch about an open-source framework they decided to use, like that would be an excuse.

/mojang cloak of niceness

Are you seriously saying that I have to apologize to you because you've behaved like a ranting lunatic and meanwhile I've managed to read past all of that and still try and figure out the problem even though your attitude does not warrant that AT ALL?

We've (as Mojang) have been pouring in money, time and resources into fixing LWJGL for 7 months now, I've personally spend 2-3 weeks of my spare time trying to help them out with their git migration and initial osx testing/fixing. LWJGL having bugs has nothing to do with Mojang employees having a lack of skills, we've even tried to remedy them wherever possible. Where the hell do you get the notion that we'd EVER bitch about LWJGL?

You've been bitching around in multiple threads, been badmouthing us wherever you went, all because you do not feel heard and there are two super trivial workarounds for your problem (update lwjgl or for a tiny moment, swap to qwerty).

If anyone is supposed to get an apology it would be me for taking all that unprovoked shit you've been pushing out.

Also, learn to use the damned edit button already, gawd.

[ mojang cloak of niceness ]

I'm really happy that this problem is now resolved, I'll close the ticket as this will automagically resolve itself in the future when LWJGL can be updated.

This issue will fix itself in the future when we can update LWJGL. For now try updating yourself to the latest (or second latest version) and OSX users can try: http://lwjgl.org/forum/index.php/topic,4711.msg26004.html#msg26004 .

I agree, this issue should be reopened as it has yet to be resolved by the default installation. Is there a way for this issue to be put on "hold" until the problem is fixed in the default download from Mojang?

Adam: What did you expect, some professionalism? No, these guys seem to be total newbies at issue tracking. For every bug reported, there are plenty of unreported bugs. For every bug reporter, there are hundreds or thousands of people who don't bother. How are they going to fix this issue by themselves? Especially as the mojang-lwjgl attitude is blaming each other back and forth, which has been my experience of this matter.
These guys should treat bug reports with some respect, instead of going trigger-happy prematurely closing everything. I guess this issue has to be cloned by someone yet again. I don't have permission to do that, so it's up to someone else. Anyhow, I'm pissed off now, so yeah. Definitely not going to recommend to anyone, also going to shut down my the server which many people enjoyed and will recommend one of the clones instead.

@Adam Baker

I agree, this issue should be reopened as it has yet to be resolved by the default installation. Is there a way for this issue to be put on "hold" until the problem is fixed in the default download from Mojang?

Right now not an option but I agree that would be nice, if it would have been an option I would have resolved it that way.

Why was my bug-report (MC-7475) closed? It's obviously not a problem with LWJGL, because updating it did not help.
This bug-report shouldn't be closed and set to 'resolved', because it is not resolved.

Why do you want to set it to resolved, when it's clearly not fixed? The problem is still there.
It's very disappointing to the bug-reporter (who spend his own time creating the bug-report) when his bug-report is closed before it is actually fixed.

It IS a LWJGL bug, we do NO specialcase handling of anything of anysorts in Minecraft, nor will we ever, the underlying library should do it's work, we just poll keystates from it, if that thing never reports 'up' when it should be, there is nothing we can do.

If updating LWJGL doesn't help it means that the current LWJGL still has a problem, the problem should probably be told to the LWJGL people :/

I have no idea what a 'NEO' layout is but after a quick google it seems like 'yet another' remapping, again LWJGL's domain.

You can try using a 'nightly' build of LWJGL, there are some serious issues in the 2.8.5 (you could try 2.8.4) that are fixed in the repository right now, but they cannot release it as the OSX branch is still under development.

You can find the nightlies at: http://www.newdawnsoftware.com/jenkins/view/LWJGL/

Grum, I would like to hug you for your wonderful verbal smackdown there.

Juha: As Grum said, there are two EASY workarounds for the problem, which I detailed in your last bug, and Grum detailed in his post. Please remember, Juha, that there are actual people on the other end of these names and user handles, some of whom would have every right to make it so your account doesn't exist anymore.

The reason it's closed is because as Grum said, once LWJGL gets their act together, the problem will automagically fix itself. In the meantime, I'm happy to switch back and forth between DVORAK and QWERTY. I have been doing so for over a year, and enjoying myself thoroughly. Meanwhile, you have been not playing because of this bug, and instead of using a simple workaround so you can play it and enjoy yourself, you spend time on the internet moping, blaming others, and acting in an immature and loud-mouthed manner. My only conclusion to this is that you like being miserable.

Please, I'm asking you as one human being to another: stop complaining, use the workarounds, and find some fun in your life, Godsdammit. It'll be worked out in the end.

Grum: Yeah, the NEO-layout is a special layout for the german language (fits much better) and has a very nice layout especially for programmers. QWERTY was made to be inefficient. (It was made the way it is because typewriters got stuck if you pressed adjacent letters. Even the original inventor wanted to change the layout. Anyway, a lot of people are just to lazy to readjust)

Why didn't you report the bug to the LWJGL people? The weird thing is that it is temporarily fixed, when pressing F11. So I assumed it was a bug in Minecraft.
Thanks for the links to the nightlies and your answer 🙂