When i assign the comm 1 or comm 2 button on my hostas,your program assigns 2 keys,no idea why.
The second key it always assigned was my missile/ dogfight deselect button.
This happens because your DGFT switch is not on center when you record the UHF/VHF push to talk presses…FoxVox sees DGFT override or MRM override as pressed if that 3-way is not centered when you press another button like the radio switch. Ask me how I know 
@Ironman3 said in Training features request:
In my opinion realism has to do with the way you fly and you deal with the sim generally.
I think you are right
For your consideration…
I’m curious why there’s such an aversion to exiting 3D and re-entering in a new flight.
This surely is a better way to provide the kind of realistic training regimen that you are alluding to in the original post. Just make a TE that has the follow on flights in the frag and then if you want the same pilots flying in all those extra seats, make sure they join the game as clients and just hop in and out of the appropriate flights at the right moments to extract the training value that you are after. In all cases, doing that will put your trainees in a jet with more realistic limits in terms of fuel and loadout not to mention avoiding the artificial trip to the “penalty box” to reset. I would imagine that the hop out and back into 3d is considerably faster than the transit time to and from an airborne regeneration zone.
The scenario with jets resetting in a staging area might be “realistic” given limited airframes for real life exercises/training and of course the inability to hot swap seats while the jets are in the air. The sim world we have doesn’t have those restrictions so why not take advantage of that and use the frag to deliver a more realistic training context for pilots than the real air forces can?? Heck the frag can let you pick different jets and loadouts for different mission roles for those follow on flights; better than simply replenishing the jet you have with the same fuel and loadout which might well be role-inappropriate.
I know that for a long time the development team has advised that you should not visit 3D world multiple times in a single game but those days are - we hope - long gone now. There’s been a lot of time and attention lavished on making multiple trips to 3D be both possible and stable.
And of course the other upside in this case is that no new code work is required to deliver that experience to you 
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.
@oldtommyboy so at the risk of laboring the point… I’m not sure what stick device you are using. However, what you want is to set it up so that it does NOT show windows a button press for the center position – i.e. when you look at the game controllers control panel applet for the stick, when the switch is in the middle position you don’t want it showing one of the buttons “on” (brighter red color)…if it does show that in the middle position and your controller programming will not let you stop it doing that…then I think you are just out of luck with the double recording thing…there’d be no way, regardless of what you map in the game key file to that switch position, to have FoxVox not see a button press there as well as whatever else you were actually trying to record.
Generally speaking controllers that always show a button pressed and held regardless are a no-no…I’d argue it’s bad design so I hope you can use a config program or something to not have it do that.
Good luck!
@Ironman3 said in Training features request:
Reentering 3d with a different aircraft can affect datalink and fuel remaining on the new aircraft which the AI was flying with.
I think that’s “old news”, bordering on “fake news” maybe these days
Try it…if you find problems like that we’d like to hear about it. That kind of thing you will find the development team will readily respond to for you.
@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/10263660
This 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.
Oh and I should add: you do NOT want to map a button to the center position of the DGFT switch. Instead use the HOTAS self-cancel setting in the config file and just map the DGFT and MRM switches to the up and down positions. The self-cancel option is exactly for this situation where people want to use all DX button mappings for HOTAS (which every sensible person does to avoid keyboard modifier key mess ups ).
set g_bHotasDgftSelfCancel 1
If you map a button to the center position of the physical switch then it will ALWAYS look like it’s pressed when it’s centered and in fact you will never be able to use the record function in programs like FoxVox without it seeing two buttons pressed at once.
sorry – should have added that above…it’s probably the important part…
@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.
@foxster said in Voice control:
@Boxer @oldtommyboy …the ignore list.
That’s a neat solution to the problem. Once again, good software works around badly designed hardware
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.
@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.
@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.
@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/10263660
This 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.
@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.
@oldtommyboy what you observed makes sense. The key file content is not involved in the business of FoxVox seeing two buttons pressed from your DX devices – that comes from the device hardware and Windows DX device driver. If you can’t change the behavior of the device, via programming software for it, to make it not show use always on buttons for some physical switch throws then I think you are stuck with your workaround or using the ignore list that @foxster put into the FoxVox program for this kind of situation.
@foxster said in Voice control:
@Boxer I’ve left them off of the default library on purpose because I want the software to work fine in its most basic configuration. Start simple then add more complexity as needed.
The assisting phrases will help the speech recognition engine stay locked onto a particular phrase when it matches more words. Something to note is the command names are automatically used as assisting phrases by default so no need to duplicate those. For most scenarios I’ve not needed them by and large but they can make a night and day difference when used with a tricky phrase that needs to support more diversity. The more recognizable words found on a command, the more accurate the recognition. The global dictionary adds those words to all the keys as assisting phrases in the library and that can help as well. Words such as two ship, four ship, f16, and others defined in the dictionary can help.
I guess I’d like to understand the theory of operation for both the global dictionary and the assisting phrases elements. Since there aren’t any examples that I can see it’s a bit hard to discern how one might use them, why and in what kind of forms – I think the “such as” mention above is the most detail I’ve seen so far. Have I missed a video on that topic also?? (very possible of course! )
Are assisting phrases considered at specific points, anchored or looked for in the group and command in particular placement?? Similar question for the global dictionary – how is the recognition code using those in practice??
I recognize I’m straying off the OP topic quite a bit…please tell me if starting a different thread would be better.
@foxster said in Voice control:
@Boxer @oldtommyboy …the ignore list.
That’s a neat solution to the problem. Once again, good software works around badly designed hardware
@oldtommyboy so at the risk of laboring the point… I’m not sure what stick device you are using. However, what you want is to set it up so that it does NOT show windows a button press for the center position – i.e. when you look at the game controllers control panel applet for the stick, when the switch is in the middle position you don’t want it showing one of the buttons “on” (brighter red color)…if it does show that in the middle position and your controller programming will not let you stop it doing that…then I think you are just out of luck with the double recording thing…there’d be no way, regardless of what you map in the game key file to that switch position, to have FoxVox not see a button press there as well as whatever else you were actually trying to record.
Generally speaking controllers that always show a button pressed and held regardless are a no-no…I’d argue it’s bad design so I hope you can use a config program or something to not have it do that.
Good luck!
@foxster – thanks for the pointer. I did see that one. And your version of “realistic” phrases definitely matches mine…wannabe rather than pro at this over here too.
I will as you suggest give it a go. I had a quick look at the basic starting library – I was curious about assisting phrases but I didn’t see any of those on a quick pass…am I just missing them??