legobmw99
commented
7 years ago I can't recreate this in my test environment. Can you think of anything that might be affect this? You mentioned a nonstandard keyboard layout?
Closed Iiridayn closed 7 years ago
legobmw99
commented
7 years ago I can't recreate this in my test environment. Can you think of anything that might be affect this? You mentioned a nonstandard keyboard layout?
Iiridayn
commented
7 years ago I'm using an Ergodox with the original Ben Blazak style firmware - so the scan codes should be pretty normal regardless of physical key assigned. I'm running openjdk8 in Arch Linux, and have a moderately large quantity of other mods installed; might be interference from one of them. Any thoughts about potential culprits? I can try taking them out, but it'd be a slow binary search to try to nail it down that way. I could also try another key, something to the right perhaps, fewer conflicts that way, and see if an alphabet letter triggers it. What else do you think might cause it?
legobmw99
commented
7 years ago The cause of it is fairly obvious in the crash log, it just doesn't make any sense. Basically, the Keyboard functionality in the engine assigns each key a code, 0-255.
For some reason, your \ key is returning a code of 348, which is too big and the game crashes.
Normally, \ would be key 43
Now, this is interesting to me, because it appears the character you included in your original issue \ is not the same character produced by my backslash button, \. This makes me suspect your keyboard's firmware is using the wrong character for that key, and the character it is using it not supported by the LWJGL Keyboard api
legobmw99
commented
7 years ago A bit more digging makes it seem like your character is U+FE68 'SMALL REVERSE SOLIDUS', rather than U+005C 'REVERSE SOLIDUS'
Iiridayn
commented
7 years ago Either way I'll test it - you have a link I can use or a simple app I can compile to test my Java scancodes? I have the same keyboard and firmware configuration here in the office, though it's attached to a Windows OS.
However, if nothing else the code shouldn't crash from unexpected input :).
legobmw99
commented
7 years ago There isn't a utility that I can find, but the issue would be larger than just Java, so something like this Javascript tester should work. The standard Javascript keycode for a backslash is 220, and if my theory is right you won't receive that as a response
Iiridayn
commented
7 years ago Got 220 - not surprising, since the keyboard works fine with everything else :).
legobmw99
commented
7 years ago Well, in that case, there is no conceivable reason the mod should be crashing. I would try the same thing when you get back to your other setup, but if it is all normal I don't know why you would have a crash while I wouldn't
Iiridayn
commented
7 years ago Might be the different Java/OS - unless you are also using openjdk8 on Arch Linux. Might also be some mod which grabs the keycode and modifies it when testing it, if treated as a reference (in which case you still shouldn't crash, but that mod would have much more to fix). I've shot myself in the foot enough times (once in particular springs to mind) modifying what I didn't realize was a reference :/.
legobmw99
commented
7 years ago The different java versions wouldn't make a difference, the crash is in LWJGL, which is tied to your minecraft installation and will always be the same version as my own. It's possible it's a negative interaction with another mod, but key codes are passed around as ints, so it likely is not a reference issue.
I can't change the LWJGL methods, so the best I could do is error check the key codes to make sure they are less than 255, but the method in question must return something, so the best case solution on my end would result in the key not working at all, just quietly doing nothing instead of crashing (which I once again can't even replicate). That is certainly better, but won't allow you to use the key you want
Iiridayn
commented
7 years ago I agree - the documentation for that method does explicitly state that it returns an Integer - not a byte (whatever an 8 bit datatype is in Java) - so checking for an out of bound and ignoring if wrong is still needed. I'd hold off closing this until I can test some letter keys in minecraft and binary search the mods to track down the cause.
Iiridayn
commented
7 years ago Actually - for all I know your change could work. Mind slinging me a jar, or is it pretty simple to compile? I've had trouble getting iChun's mods compiling, so "once bitten", etc.
legobmw99
commented
7 years ago The only change made was switching to a method that already checked to see if the code was between 0 and 255, it will stop crashes but would not allow a key outside the normal range to actually do anything.
Compiling is pretty easy, standard gradle build should do it, if you have a recent-enough JDK installed
Iiridayn
commented
7 years ago Can confirm that key works fine with Baubles and other mods, but other keys work fine with the allomancy mod... Sigh. Will try the build.
Iiridayn
commented
7 years ago Can confirm reproducible client side crash is gone with commit, though the menu sorta starts sliding out still. I suspect there are multiple keycodes generating somehow - but doesn't matter nearly as much as a crash, this is recoverable, user just picks another binding and doesn't file a report :). :+1:
Assigned burn key to
\(convenient on my keyboard) - works fine as misting, crashes client as mistborn.