Solved X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
-
I have both 4.36 and 4.37.1 installed. For the X52 pro, I use the Alternate Launcher to map the inputs, and use the same AL to launch either of the two BMS versions. The pinky configuration is the same in both the instances, but in 4.36 it is working fine and in 4.37 it is not registering the input in 3D. In 4.37, when I use a control mapped to the shifted layer, only the unshifted input is executed. Additionally, the moment I press the pinky button for the shifted layer, it EXPands on the FCR. To solve it, I tried setting the g_nHotasShiftQuickPressTimeLimit value to 400ms (default is 200ms) based in inputs from another thread here, but it seems the value is ignored, and doesn’t solve the issue. I’ve also tried unassigning the shifted layer and then reassigning the keys, but the results were the same. It is notable that within the Alternative Launcher, the shifted layer is recognized correctly every time when tested.
Any ideas how I fix this? 4.37.1 is unplayable because of this.
-
@crazycalvin it sounds like you know what you’re doing so it’s hard to guess what’s going wrong…
if you upload your BMS-Auto.key file to https://pastebin.com/ or dropbox or something, I’ll spend 5 min to take a look.
-
@airtex2019 I’ve pasted the file from BMS 4.37.1 at https://pastebin.com/Rqz6peL7
Thanks for the help
-
@crazycalvin I don’t see any dx-button mappings at all, in that key file. shifted or unshifted…?
-
@airtex2019 very interesting; I did not know about that file, so thanks for pointing in that direction.
Maybe that happened because when I copied the file to pastebin by X52 Pro wasn’t plugged in?
I’ve uploaded the file again (towards the end it has a section for X52) at https://pastebin.com/5h2jXBqe
Alternative Launcher with 4.37:
Alternative Launcher with 4.36:
Comparison of BMS-Auto.key files from 4.36 (left) and 4.37 (right); I’ve tried to capture the main differences in the X52 category. There were also some other differences (for example, 4.37 has the new CMS declarations):
-
@crazycalvin the SimHotasPinkyShift looks right – and same 4.36 vs 4.37
next things to look at … DeviceSorting.txt and falcon*.cfg files
I think you want to see X52 as the first line (and only line?) in DeviceSorting.txt
and look in both ‘falcon bms.cfg’ and ‘falcon bms user.cfg’ for the following keys … I think you want to see
set g_nButtonsPerDevice 128 set g_nHotasPinkyShiftMagnitude 128
-
-
@crazycalvin Just for your information I am facing the same problem with my X52pro Pinky (shifted layer) is not working in 4.37.1 but works perfectly in 4.36.3
I am using my own customized key file in both 36 and 37. I have an older thread regarding the problem, still unsolved. For now 4.37.1 is unplayable
https://forum.falcon-bms.com/topic/24629/problem-with-the-hotas-profile-in-4-37/11 -
@Elec Yep, I had seen your thread and seemed eerily similar, which encouraged me to post here instead of just tinkering like I had been doing for the past few days.
-
@airtex2019 Hey, we seem to be onto something.
In 4.36:
- DeviceSorting.txt has a single line in it
{076206A3-0000-0000-0000-504944564944} “X52 Professional HOTAS” - Both the set declarations you mentioned above are there in each of the cfg files.
In 4.37.1:
- DeviceSorting.txt file exists, but is blank
- set g_nButtonsPerDevice 128 exists in both cfg files
- set g_nHotasPinkyShiftMagnitude 128 does not exist in either of the configuration files
I’m tempted to try and fix this by filling in the blanks in the 4.37.1 files, but if there’s anything else to try (so that this is fixed for good and not a hack that will break with the next update) I’ll be happy to troubleshoot further.
Appreciate the help!
- DeviceSorting.txt has a single line in it
-
DeviceSorting.txt file exists, but is blank
I truly have no idea or explanation for that… have seen and heard a lot of problems, but wasn’t expecting that (I was half expecting you to tell me there were 2 or 3 superfluous lines in there).
-
@airtex2019 My bad, I have an entry (I had to plug in the stick, load up the launcher, and select 4.37 on it and then the entry appeared when I exited the launcher). There’s one entry there.
-
@airtex2019 it seems to be solved. I manually added the set g_nHotasPinkyShiftMagnitude 128 value in both of the cfg files and all’s well. Thank you for the help.
-
-
@crazycalvin glad it’s fixed but once again you leave me perplexed.
the AL code pretty clearly always appends an entry for g_nHotasPinkyShiftMagnitude … I don’t understand what weird things are happening on your system, or why.
-
@airtex2019 I was using AL before it was bundled with BMS; maybe when I switched from the one I was using to the one bundled with BMS something got messed up (probably user error).
-
-
@crazycalvin that’s probably it – officially, copying key/cfg/xml files from older BMS major version isn’t supported.
in practice, it mostly works ok tho… there were no big breaking changes from 4.36 to 4.37.
unless dragging along some weird file-permission issues (eg. if you had 4.36 installed on a different drive than 4.37… or under C:\Users or C:\Program Files somewhere)
but then I’d just expect AL to simply crash or show an error msg… not silently fail to update the cfg file :shrug: oh well
-
@airtex2019 BMS is installed under D:\Program Files (x86) so maybe it had trouble writing to that location initially. I had ruled that out because it was able to make the other key binds just fine.
-
@crazycalvin That is a hugely bad idea for at least several reasons
-
directory permissions / admin elevation (UAC) required for writes
-
antivirus are especially aggressive in monitoring/blocking write activity
-
win64/32 file-system virtualization/redirection … BMS itself is 64-bit only but the Launcher runs in 32-bit dotnet host process, so I can’t even guess whether it should be in “Program Files” or “Program Files (x86)”
any of these could explain why filesystem writes to User/Config directory are silently failing.
short answer is don’t ever install things under Program Files that don’t want to put themselves there. BMS is just not one of those things.
-
-
@airtex2019 I’ll keep this in mind when I set it up next. Great points, and thanks for the help again