Ice’s Falcon BMS Profile Updated for BMS 4.35
-
For the experienced Helios user of course the use of a second keyfile is redundant. However I still feel fully justified in using a setup in which Helios already points to its own keyfile. The reason being that this was intended to be as simple an install as possible and judging by the countless number of PMs I’ve received just saying great, thanks and that after following the Setup Guide it worked perfectly first time, it must have been the correct decision. They aren’t interested in swapping keyboard keys etc. they just want to install it with the least possible hassle and just use it. The only thing for them to do was to copy their HOTAS profile to the end of the supplied keyfile, which for most people is easier than trying to insert the other way around, and point BMS to the new keyfile.
-
Then maybe all the users that contacted me on various Discords are just the other way round. Most of them where where Alternative Launcher users which just can’t follow you procedure by the book
3. Depending on which HOTAS profile you intend to use copy the relevant keyfile from the
Setup \FalconBMS Keyfiles folders to the Falcon BMS 4.35\User\Config\ folder.
4. Load and save the chosen keyfile in Falcon BMS 4.35 Setup.This is just not gonna work for any users with Alternative Launcher.
-
Then maybe all the users that contacted me on various Discords are just the other way round. Most of them where where Alternative Launcher users which just can’t follow you procedure by the book
This is just not gonna work for any users with Alternative Launcher.Alright, so next time the instructions will recommend to not use Alternative Launcher.
-
Very user friendly, indeed.
I’m moderating the help section in one of the largest BMS Discord communities with over 1500 Members. AL gets more and more the Tool be used with BMS especially because of it’s capability for HOTAS setup and bindings.
So I would say you’d recommed 40% of new user of this profile to basically try to figure out themselves how deal. -
Very user friendly, indeed.
I’m moderating the help section in one of the largest BMS Discord communities with over 1500 Members. AL gets more and more the Tool be used with BMS especially because of it’s capability for HOTAS setup and bindings.
So I would say you’d recommed 40% of new user of this profile to basically try to figure out themselves how deal.If users are using the Alternative Launcher for it’s HOTAS and Bindings then I’d hazard a guess that they are not exactly inexperienced and that the majority are quite capable of figuring it out for themselves and wouldn’t even need to read the Setup Guide.
But then edit the Setup Guide to recommend not to use the AL but include alternative instructions in case they need to use it, problem solved.
-
Very user friendly, indeed.
I’m moderating the help section in one of the largest BMS Discord communities with over 1500 Members. AL gets more and more the Tool be used with BMS especially because of it’s capability for HOTAS setup and bindings.
So I would say you’d recommed 40% of new user of this profile to basically try to figure out themselves how deal.Honestly I think the easier answer here is if using Alternate Launcher rename one of the chosen “provided” HOTAS key files to BMS - FUll.key and put in in the BMS user config directory, boom! problem solved. Then they can tweak the the HOTAS section to their hearts content.
-
If users are using the Alternative Launcher for it’s HOTAS and Bindings then I’d hazard a guess that they are not exactly inexperienced and that the majority are quite capable of figuring it out for themselves and wouldn’t even need to read the Setup Guide.
But then edit the Setup Guide to recommend not to use the AL but include alternative instructions in case they need to use it, problem solved.
I’d say exactkly the other way round. AL addresses the unexperienced users/ newcomers/ DCS switchers as it simplifies the setup and Binding of an HOTAS / keybinds.
-
Honestly I think the easier answer here is if using Alternate Launcher rename one of the chosen “provided” HOTAS key files to BMS - FUll.key and put in in the BMS user config directory, boom! problem solved. Then they can tweak the the HOTAS section to their hearts content.
Boom you deleted all your HOTAS DX bindings and you start up reconfiguring your HOTAS again. Guys maybe think back how much effort you have put into configuring your own HOTAS.
The most likely use case is a user already has a HOTAS configured to his liking and then might think of going the touchscreen Helios way not the other way round.
But I leave that for now, I already have my “setup guide” made and will provide that to the users that ask me personally for help
-
Boom you deleted all your HOTAS DX bindings and you start up reconfiguring your HOTAS again. Guys maybe think back how much effort you have put into configuring your own HOTAS.
Are you actually suggesting that anyone who has spent time configuring their HOTAS DX bindings hasn’t created a backup? If you spend that amount of time and effort then you absolutely would create a backup, if only in case of a hardware failure. Even if you haven’t, the Windows “Restore Previous Versions” would probably get back your keyfile excluding of course a hardware failure.
Anyway, I think that’s a good idea from wheelchock, it just needs the caveat that you should create a backup copy of the full key file before replacing it. Then just extract the DX section from the backup keyfile and paste it onto the end of the new keyfile.
But I leave that for now, I already have my “setup guide” made and will provide that to the users that ask me personally for help
That’s your prerogative entirely.
-
If I’ve previously configured my hotas using AL, but the delete the settings AL will re-add my previous settings from Setup.v100.<device><{guid}>.xml,so loading a “new” BMS-full key file into AL should be an issue. Not sure is this changes anything cos I’m one confused moderately advanced user.
I tried to create a symlink of bms-full in bin/KeyFile, but the result are inconclusive (I.e. not sure I restarted helios control centre)</device>
-
If I’ve previously configured my hotas using AL, but the delete the settings AL will re-add my previous settings from Setup.v100.<device><{guid}>.xml,so loading a “new” BMS-full key file into AL should be an issue. Not sure is this changes anything cos I’m one confused moderately advanced user.
I tried to create a symlink of bms-full in bin/KeyFile, but the result are inconclusive (I.e. not sure I restarted helios control centre)</device>
I’m not surprised that you are now somewhat confused.
After editing the BMS-Full keyfile as required then open up the Helios Profile Editor and point the profile to the BMS-Full keyfile you have just edited. In this case you no longer require the C:\Bin\KeyFile:
-
I’m not surprised that you are now somewhat confused.
After editing the BMS-Full keyfile as required then open up the Helios Profile Editor and point the profile to the BMS-Full keyfile you have just edited. In this case you no longer require the C:\Bin\KeyFile:
I think this comment in the @oakdesign’s post (#119) somewhat cleared up my confusion:
So a user new to Helios will most likely have most callbacks used in Helios profiles not set up as keyboard users they will have for most switches have a single callback toggle callbacks instead of multi state callbacks.
So in order to get the profile to work in any case they have to integrate key file/callbacks into the key file that is loaded in BMS.It made me aware that all things are not equal when it comes to implementing a switch for example in BMS and Helios. In my opinion, this distinction should be called out in the setup, i.e. make it obvious which callbacks are the most important to have in your profile for Helios to work - I think the issue (for me at least) was not knowing why a wholesale copy and paste is necessary - if it is at all. I guess it would be ideal if AL could integrate with Helios and show touch style bindings…
-
It made me aware that all things are not equal when it comes to implementing a switch for example in BMS and Helios. In my opinion, this distinction should be called out in the setup, i.e. make it obvious which callbacks are the most important to have in your profile for Helios to work - I think the issue (for me at least) was not knowing why a wholesale copy and paste is necessary - if it is at all. I guess it would be ideal if AL could integrate with Helios and show touch style bindings…
There over 200, probably nearer 300, callbacks in the profile so documenting all of those would be difficult to say the least which is why a complete wholesale copy and paste is necessary. In fact I would estimate that something like 90% of the available keyboard keys are used by the profile. There can be up to 8 separate functions assigned to each keyboard key so for the keyboard letters and numbers alone you have 36 x 8 = 288 possibilities. Then you have the function keys, the numeric keypad, arrow keys etc. all of which have been used to some extent in the profile.
If you try pasting in individual keys you will almost certainly finish up with duplicate keys, i.e. the same key combination assigned to more than one callback.
In fact, if you check out the “BMS - Ice’s Helios Profile Keyboard Layout.pdf” file included with the setup you’ll see all of the keys that are assigned to callbacks. Almost all of those callbacks are used by the profile.
-
There over 200, probably nearer 300, callbacks in the profile so documenting all of those would be difficult to say the least which is why a complete wholesale copy and paste is necessary. In fact I would estimate that something like 90% of the available keyboard keys are used by the profile. There can be up to 8 separate functions assigned to each keyboard key so for the keyboard letters and numbers alone you have 36 x 8 = 288 possibilities. Then you have the function keys, the numeric keypad, arrow keys etc. all of which have been used to some extent in the profile.
If you try pasting in individual keys you will almost certainly finish up with duplicate keys, i.e. the same key combination assigned to more than one callback.
In fact, if you check out the “BMS - Ice’s Helios Profile Keyboard Layout.pdf” file included with the setup you’ll see all of the keys that are assigned to callbacks. Almost all of those callbacks are used by the profile.
Well, it’s certainly a conundrum.
Now I have an issue. I should still be able to click a switch with my mouse in BMS and have the corresponding switch change in Helios right. I run everything (incl. Helios keypress receiver) as admin.
-
Only switches that are bi directional. So have an input from Falcon Interface bound.
Example of one would be the gear handle. Most switches are uni directional. So if you switch then outside Helios like clicking in pit Helios would not recognizeThe keypress receiver is not needed at all if Helios and BMS run on the same computer. Keypress Receiver is only needed used in a network environment where you run Helios on a different computer.
In a network environment you would need additional tools like lightnings Shared Memory Mirror to get BMS data over the network back to a networked HeliosGesendet von meinem SM-G930F mit Tapatalk
-
The key press receiver is if you are running helios remotely from the pc were bms or dcs is running. Also bms does not emmit what switch was flipped. Some profile builders can infer the state of. Switch based on some other value. How Helios interfaces with BMS is very different than how it interfaces with DCS
If you have questions regarding how helios interfaces with bms then ask over in discord channel https://discord.gg/UDZqNAaV not
Sent from my iPhone using Tapatalk
-
Just went with another user through setting up the profile on his new touchscreen. On his first flight he realized that the keyind for Eject has changed and that there is no touch representation of the Ejection handle in the profile.
Maybe something to consider for a future version
Added this to my running version
-
I was thinking the profile needs a switch for the RPM gauge - to switch between GE and PW, simpler than the Aux Comm/IFF panel I imagine (took a look at doing it, but the LUA script baulked me).
Sent from my Phone 2 using Tapatalk
-
I was thinking the profile needs a switch for the RPM gauge - to switch between GE and PW, simpler than the Aux Comm/IFF panel I imagine (took a look at doing it, but the LUA script baulked me).
Sent from my Phone 2 using Tapatalk
Not that hard to do.
1. you need a backround for the gauge that goes to 100%. Could be extracted/cut out of a cockpit texture dds.
2. Just copy past the GE gauge rename it and switch the bckground image.
3. The Lua is not that complicated it just calculates the value in degree the needle rotates if you look on the gauge you’ll notice that the amount of needle rotation between 0 and 70% rpm is greater in degree per rpm than between 70% and 110% for a PW engine would be brety similar just it 0-60% and 60-100%. For another tool (MFDE) I was already looking if the engine GE or PW could be automatically be determinded from SharedMemory so by using the Falcon input interface- would make it possible to switch between the 2 gauges automatically, but havent’t found a propper solution jet. But manually switching with a button just add it like the the switch betten AUX and IFF -
I was thinking the profile needs a switch for the RPM gauge - to switch between GE and PW, simpler than the Aux Comm/IFF panel I imagine (took a look at doing it, but the LUA script baulked me).
The RPM gauge is already on a panel so copy the complete panel. Set the second panel to hidden and create a full size transparent button on each panel to hide its own panel and show the other panel. So now a tap on the RPM gauge will switch between the two gauges. On the second panel change the gauge image, the lua code and the gauge needle rotation range.
The current lua code is:
if TriggerValue < 70 then return TriggerValue * 50/70 else return ((TriggerValue - 70) * 50/30) + 50 end
The code you would need on the second panel would be something like this:
if TriggerValue < 60 then return TriggerValue * 50/60 else return ((TriggerValue - 60) * 50/40) + 50 end
But you would then have to establish the correct value for the midpoint (scale changeover point) of the actual gauge dial image, on the current gauge image it just happens to be approximately 50%, hence the values of 50 in the lua code. The next update will include a more accurate version with two changeover points instead of one.
Then in the gauge needle settings change the rotation range maximum value until the needle points to the maximum value on the gauge dial.