Solved Reliable crash due to key layout file
-
I just happily created my keyboard layout file with the alternative launcher. now every time I start the game I get a crash. Here is the stacktrace and debug log output.
Loading this key file in 4.36.1 will crash the game.
https://pastebin.com/5xwyQrL2Crash log:
https://pastebin.com/TCMzHruaAlso it would be really nice if one could upload such text files to the forum.
-
@Falco – that file cause the game code to crash trying to parse the line for SimTogglePaused:
SimTogglePaused -1 0 0xC5 0 0 0 1 "SIM: Sim-Pause - Toggle"
What key did you think you were trying to assign to that callback?? the 0xC5 value is in outer space somewhere, not a key that the code knows about so it’s throwing up it’s hands not knowing what to do by the looks of it.
-
@Boxer
I assigned the pause key. Like the actual key that says pause on it.
In any case, it should behave more reasonable. For example displaying a reasonable error message and then continuing without assigning that key.I think this is related
https://stackoverflow.com/a/38850436/10263660 -
-
@Falco said in Reliable crash due to key layout file:
@Boxer
I assigned the pause key. Like the actual key that says pause on it.
In any case, it should behave more reasonable. For example displaying a reasonable error message and then continuing without assigning that key.I think this is related
https://stackoverflow.com/a/38850436/10263660This is not what you meant I know, but I think my answer would be: yes, it [alternative launcher] should behave more reasonable [sic]…you probably want to let the author of the alternate launcher know that this key is not supported in the game and one might consider it a bug in that tool if it allows assignment of that key
All humor aside, the game UI and the keystroke editor provided with the install do not allow assignment of the BREAK/PAUSE key for callback binding. Therefore, if you stick to what comes with the game to edit key file content, it’s not possible to encounter this error. We have at various times talked about defending the code against “bad data”, hand edit errors or third party tools issues. Some measures are taken in spots, including against some forms of bad data in key files. You are right in that more could be done. However, one has to recognize that there are very many ways to “break” the code with unsupported changes to data file content and defending against all of those is…well, a lot of work.
Suffice it to say, this is probably going to be on the “will not fix” list for the foreseeable future.
With luck, the fact that you kindly pointed it out and we discussed it here will allow anyone running into this issue in future to at least search the forum for help and find the simple work around: "don’t try and map the PAUSE/BREAK key in your key file.
-
@Boxer No. It [BMS] should be more reasonable and not crash with a malformed keys file and instead identify the error to the user instead of dying with an unhandled exception. The fault is on both sides here. Though I shall make a bug report.
The ingame keystroke editor is missing features, such as assigning functions on release and is generally really awful to use (or at least it had been when I last tried it in 4.34), which is why I used the alternative launcher’s keystroke editor to begin with. I’m unaware that bms now ships with a program to do that for you externally.
-
There are some keys that should not be remapped, such as the Q-W-E-R-T-Y keys used for comms and flight management. That list of excluded keys should maybe cover P and Shift+P as well? If so, a short note about this could be put in the technical manual.
-
@Falco said in Reliable crash due to key layout file:
@Boxer No. It [BMS] should be more reasonable and not crash with a malformed keys file and instead identify the error to the user instead of dying with an unhandled exception. The fault is on both sides here. Though I shall make a bug report.
Please note I didn’t say it’s not a problem with the game code, just that this isn’t very high up the list of priorities…so likely not fixed anytime soon. As I say, several protections against malformed key file content are already in place…just not one to protect against “random” numbers in the key code field it seems.
The ingame keystroke editor is missing features, such as assigning functions on release and is generally really awful to use (or at least it had been when I last tried it in 4.34), which is why I used the alternative launcher’s keystroke editor to begin with. I’m unaware that bms now ships with a program to do that for you externally.
Ah, OK I see. That’s fair critique. I put the code for the up/down specific mappings in there with the idea that it would likely only be “expert” users needing that – cockpit builders for example since it’s most useful with mechanical switches that don’t physically manifest as push-to-make momentary switches (i.e. not game controller device buttons). In other words, mostly thinking about users who’d be editing the file by hand with the understanding of the various fields. I didn’t actually know that Alt Launcher supports that – cool!
Fair ask that the tool we provide should perhaps address that. Let me see what I can do about that.
-
@jayb said in Reliable crash due to key layout file:
There are some keys that should not be remapped, such as the Q-W-E-R-T-Y keys used for comms and flight management. That list of excluded keys should maybe cover P and Shift+P as well? If so, a short note about this could be put in the technical manual.
OK there are a couple of things mixed in here so for clarity to everyone reading along.
PAUSE/BREAK does not generate a normal scan code like other keys on a PC keyboard. It’s special that way and the game input code simply doesn’t support using it. Certainly not as something you can remap to a callback. Good idea to be crystal clear about that in the technical manual.
QWERTY keys, unmodified, have very traditionally been used as the entry points to the AI comms menus. In the default key files, these menu entry keys are marked with the “not changeable” flag. So, you can’t typically change it without hand editing the key file.
But, there is nothing that prevents you from remapping those if you want. Provided of course that you are ready for potential consequences; and it’s those potential consequences that informed marking these things as not changeable in the default files. As an example of the type of consequence to be aware of, it may be that if you use a voice control program with a default profile that let’s you “talk” to the AI, it may expect “Q” for the AWACS menu entry and if you change the key file binding for accessing that menu then you may also have to change the settings for the external tool that does voice recognition for you.
-
Yes, don’t assign the “Pause key”. - Phil
posted: Feb 25, 2022, 3:38 PM
Sim-Pause key remap bug?After remapping the Sim-Pause toggle from the “P” key to the “Pause” key, entering Setup causes an immediate CTD. Mapping Sim-Pause toggle back to the “P” key avoids the CTD. Not a big deal once you figure out what caused the crash.
-
@Boxer Well that’s just the issue. Once you figure that out. BMS provides no information. Let me give you an example pseudocode in c++
for (std::string line in lines) { // [process line from key file here] if (invalidKey) throw std::runtime_error("Some unhandled exception that is never caught, resulting in a huge callstack that provides no information."); }
should become
for (std::string line in lines) { try { // [process line from key file here] if (invalidKey) throw std::runtime_error (std::format("Invalid key code {keyCode} on line {lineNum} in {fileName}")); // or use fmt library if not >= c++20 } catch (const std::exception& e) { Dialogue(e.what()).show(); } }
Immediately the problem is solved. The game doesn’t crash and you get the information exactly what is wrong. Exceptions are to be caught early, and never not at all unless it’s really unable to be handled.
Of course I don’t claim to know the codebase, but surely if you throw an exception, then you know something is wrong. Might as well provide the information of WHAT is wrong. The side effect of this approach is also that the key gets not assigned for this particular keystroke, but everything else works.
Speaking of, BMS isn’t open source, is it?
Also I opened an issue https://github.com/chihirobelmo/FalconBMS-Alternative-Launcher/issues/72
-
@Falco pretty sure Boxer knows how to handle errors in C++ (but do any of us, really? :)) but it’s cool I know you’re just trying to illustrate your point.
I suspect the thing BMS tries to do is lookup the scan-code based on the current keyboard layout (or does it always use a US-english standard keybd layout?) in order to give it a friendly presentation in the UI.
@Boxer maybe a more plausible scenario, what if someone in Germany makes a key file that uses 0x56 (the bracket/pipe key next to left-shift) and then tries to share that key file with a US player… or switches his/her keybd layout, etc.
In near term, this is probably all food for discussion on the Alt Launcher issue.
-
A couple of quick follow up notes.
The Documentation already includes supported key codes in charts for the supported locale specific keyboard layouts. See under Docs, Input Devices, Keyboard Layouts for the PDF files that have these charts.
The docs team tell me that one should read this like a white list - they key codes shown are the ones you can map. So things not shown, notably the PAUSE/BREAK key, should be the clue that the game doesn’t support them.
Regarding the supplied Excel based editor tool and the ability to assign callbacks to physical make or break for a given switch and the ability to invoke callbacks with either or both of key up and down semantics: the device tabs for joysticks like Cougar or Warthog do not support that.
However, there is a “DX specifics” tab which can do this. The idea of this tab is that you can construct one or more lines for a specific switch and then paste those lines from that sheet into your key file as required. Yes, that means lines constructed there do not show up in the automated “output” tab so there’s a little more work to do to leverage what’s in the DX specifics sheet but… I was wrong to say that the capability is not supported in the supplied editor tool at all. My apology for the mistake on my part there.
I did add a to-do item for adding more defense in depth to the key file parsing code. This is at best 4.<thirty-next> though so not all that soon.