Problem using (understanding?) SubShift function

[EDL]

I recently purchased:
Gladiator NXT EVO SCG Premium OTA (Left)
Gladiator NXT EVO SCG Premium (Right)

Both sticks came with firmware 2.122
I am using VKBDevCfg(v0.92.51)

My plan was to assign the center button of each HAT switch a different SubSwitch function number.
That way the other keys of that same HAT could have multiple functions without affecting any other buttons.
The other HATs could use their own SubShift or not as needed.
This would leave the global SHIFT keys (#1 & #2) for truly "Global" changes.

I am able to assign the SubShift without any problems.
A programmed LED indicates the state change takes place as expected.

The problem comes when I try to use the "ButtonS" type for the other buttons (Up, Down, Left, Right).
Using HAT A3 (the middle one) as an example:
Center button Physical layer #14 gets the SubShift #1 function, set as Alternate so it latches.
The "Down" button Physical layer #21 gets set as "ButtonS".
By default the V.Button Drop Down Menu has "22" assigned (one more than the original button)
#22 is another one of the HAT's buttons however (A3-Up), so I changed it to #41 (a free location).
As soon as I make this change, the cell identifier changes to "BM #1" instead of staying "BS 1"
If you leave and then re-enter the Button Mapping Wizard for cell #21 it is now described as "Modal Switch controlled Button".
If you use the "Set" action to write this configuration to the stick, and then use the "Test" page to watch what happens:
Light #8 (A3-Down) turns on for a normal press (as expected).
When the SubShift is activated (press and release A3-Center) Light #8 still lights instead of #45 when the "Down" button is pressed.

The manual I have (controller2_17En.pdf) has no mention of "Modal Switch controlled Button" or the BM #n identifier.
It does show a "Type" Drop Down Menu in the "ButtonS" page of the Button Mapping Wizard.
According to the manual this allows "Single" or "Multi", so you can have one (or more) SubShifts controlling the button.
My system using VKBDevCfg(v0.92.51) the current version available, does not present ButtonS options like the manual does.

I have this same problem on both sticks (left and right).
I also tried doing this with VKBDevCfg(v0.92.57) and firmware v2.12B with the same results.

Is there a more current manual that describes v0.92.51 or later versions of the VKBDevCfg program?
Is my thinking of how SubShifts "should" work at fault?
Is it possible to re-map the "shifted" destination?

Thanks for any help you can provide for this matter.

I haven't found anything on the web to suggest anyone else is having this problem.

[fallout9]

Tried to replicate and can confirm the issue. Thanks for reporting about it, will forward this to the developer.

[EDL]

Thanks for the quick reply and confirmation.
Looking forward to doing more with these fantastic sticks.

[genko]

Has there been any update to this issue?

I too am stuck and unable to effectively make any use of the entire subShift feature.

The application automatically changes any ButtonS type to a ButtonM type that I am unable to find any documentation on in what manuals and guides I've been able to secure in english.

[genko]

Good news!

I have somehow managed to figure out and get working the MODE switch feature using the new (and slightly bugged) Button M + Modal Switch Boolean. (VKBDevCfg v0.29.51 - Njoy32 fw v2.12.0)

The issue it seems we're all having is with Button S automatically changing to Button M once either subShift # or V Button # are changed.

I did the following to successfully get this to work the way I'd wanted (a button on the SEM changing it's logical output based on the position of the mode switch) by setting things up as follows:

First - Create the boolean (values I entered from top to bottom and left to right):
- Change "OFF" to "Modal Switch"
- Set number to "1" (Note- It goes up to 4, but this number is not referring to which position the switch is in, it is referring to the entire mode switch itself and allows you to use 4 different "switches" as a modal switch... in the SEM's case, I suppose that means you could use the Flaps/Landing gear as modal switches depending on the detents you decide to use)
- Set first layer to physical (to select which physical button you want to use)
- Set But N: In my case I used physical button 53 as that is my physical button for position 1 on the "MODE" rotating switch. Another note here, I believe you want to set this to your "starting position."
- Set the second layer to virtual (this is what translates your physical button to logical button)
- Set But N: In my case I used virtual button 53 which connected physical 53 to logical button 53
- Set N Pos: In my case I used 4 such that the number of controlled positions ("N Pos") is 4... The mode switch on the SEM has positions 1, 2, 3 and 4. Such that we've set 53 as our logical starting position, this boolean will then set 54, 55, and 56 as the 3 remaining controlled positions.
- Check the box which enables "Neutral Position" -- what this does is set the starting position as a "neutral position" which prevents position 1 from being a "modifier." In short, when the mode switch is in the "1" position nothing is being modified. You are in your "base" configuration until you rotate to position 2 and 3 and 4 which will act as modifiers on your base configuration.

Second - Configure the buttons:
- For my setup I elected to set physical buttons 53, 54, 55 and 56 (my mode switch's 1-4 positions) to have No Function (Button Type "NoF") as I personally don't want my changing of the mode to signal any button presses to whatever game/application I'm running.
- Now select the physical button you want modified by the modal switch and set it's type to "ButtonM"
- Set MSw # to whatever number you used as your "Modal Switch" number when creating the boolean
-- You'll notice that when you set this value to the number of your modal switch (MSw#), your virtual section shows 8 virtual buttons
- Set V. Button to whatever available virtual button you'd like to use as your *first* modified button, I used 65.
- Now you'll notice that in the bottom section of the button mapping wizard you have the button mapped to its unmodified virtual button followed by 7 sequential virtual buttons. Since the mode switch only has 4 positions you'll only ever activate the unmodified virtual button in mode 1 (since we used that as a "neutral position" when creating the boolean) and then the next 3 virtual buttons with each respective mode switch position. Mode switch position 2 would activate virtual button 65 (your first modified or "shifted" button) and then position 3 would activate virtual button 66 and position 4, 67! Since we won't use the remaining 4 I set their logical buttons to have no function to free them up for use elsewhere.

I'm not sure why it adds 8 total virtual buttons and can't figure out how to limit it only to the 4 I need, however, so if anyone figures that out I'd love to hear about it!

Hopefully you can follow along and get it working yourselves.

I'll try to answer questions if possible lol.


Update: I was able to reduce the number of virtual buttons consumed by the ButtonM button by changing the N Pos value in the boolean to 2, but then only mode switch positions 3 and 4 don't do anything... not sure why/how all the virtual buttons are generated by the boolean.

[fallout9]

That was fast ) Thanks for sharing!

[genko]

lol well it wasn't as fast as it seemed... lots and lots of searching and reading!

It wasn't until I found a few nuggets of information via this forum and the developer's personal web page that I was able to somewhat piece it together by trial and error, hopefully I save someone else the many hours I spent on it.

[Ron61]

I will duplicate here the previously created instruction.
We make Modal Switch, multiply B1, B2, B3 on SEM, for example, - yes, any buttons or encoders
1. in booleans, we configure the switch itself, I have it on physical 53-56, we skip the first (53) and do it with 54, since the default buttons B1 (43), B2 (44), etc. will work in the first position. We indicate the switch number (1) and the number of positions (3), taking into account the above.

2. in the buttons, turn off (No Function) the physical lines (1-4) occupied by the switch so that the logical buttons do not glow and this frees the corresponding logical lines that we can use - why should the good disappear?

We set up B1 (43), the machine puts the next line (44) in the V.Button setting, but it is already occupied by the next B2 (44), so we put the mouse cursor on the white field (red cross) and call the virtual layer with the left double click, in which we select the first free button in the row (89), the rest will automatically line up behind it.

3. We set up B2 with the difference that we use the free buttons that are left from the switch (53-55), we can not do this, but use the initial 92.
4. We can configure the indication of the enabled mode (on the FSM-GA module), but for this you need to turn off the constant backlight by moving the jumper inside the module.

p.s. exactly according to the same algorithm, out of two physical encoders (with central buttons) on the GA, eight (+ 6 virtual ones) turned out.

[Coyote21_vkb]

I'm also having this issue on my older Gladiator NXT XT2 v2.14A and VKBDevCfg-C v0.92.79

Unfortunately, I'm too dumb to understand the two "solutions" already suggested, but I'm not running anything near as sophisticated. I mainly just use my HOTAS for a couple of space sim games (X4, Elite Dangerous, etc).

And it seems from my reading of the solutions that they are more "finding a complicated way to achieve the same result" than a fix for the original issue.

I think I'll just wait a bit and hope for a new, fixed version of VKBDevCfg.