@airtex2019 I’ll keep this in mind when I set it up next. Great points, and thanks for the help again
Latest posts made by crazycalvin
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
@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.
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
@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).
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
@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.
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
@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.
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
@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
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
@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.
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
@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):
-
RE: X52 Pro Pinky (shifted layer) not working in 4.37.1; works fine in 4.36 and AL shows correct input in both
@airtex2019 I’ve pasted the file from BMS 4.37.1 at https://pastebin.com/Rqz6peL7
Thanks for the help
-
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.