Button release not detected after profile switch

[Matroshka]

Recently I've been trying to improve recognition performance (for some reason VA completely fails to correctly recognize wildcards for me 100% of the time, requiring me to provide all "recognizable" prefixes for commands, possibly poor soundcard) by dividing my commands into segments (recipient->sender->command) and then, rather than using the prefix-suffix system, putting recipient selection in one profile and dividing commands into several profiles depending on the recipient selected, then dynamically switching to the correct command profile with "Switch to another profile" based on which recipient was selected. All of this is driving the comm menu system in Falcon BMS, so the structure is made to resemble radio calls. Since BMS 4.34 comm structure separates (by default) all intra-flight comms into VHF net and all calls to external entities to UHF net (both having their own separate PTT buttons). I tried to use that system to further improve performance by dividing the recipient selection profile into 2 separate profiles, and switching to the proper one when the PTT is pressed.

And here's where I ran into a problem. To allow for multiple PTT buttons, rather than using the hotkey options, I used commands - one for each button, triggered on press to start listening and switch to correct recipient selection profile and one one for each button, triggered on release to stop listening, cancel commands and switch back to master profile. These are placed in a separate profile that is included in all other profiles, so that PTT commands are detectable in all of them. The problem is that, apparently, unlike the global hotkeys, the device state used by commands gets forgotten on every profile switch - the release commands don't trigger until a button is released, pressed and released again. This is actually an issue that has implications beyond what I'm doing: for instance, many HOTAS systems like the TM Warthog have 3-way switches, where the middle position produces no input and the upper and lower position provide constant input while pressed - and those are not spring loaded, they stay in place, meaning if anything is assigned to their release and they are out of the middle position when VA is launched, it will bork recognition. Same applies to mode switch on the stick I'm using (X52 pro) - here the mode switch provides constant input in middle position as well, so if I made the commands dependent on what mode I was in, VA would fail to recognize which mode I'm in on start up.

Bottom line is: VA fails to hold device state when profiles switch, reverting to 0 on all inputs regardless of what they actually are rather than polling the device on profile initialization to check current state. This applies not only to commands triggered by button release, but also to manually polling the device with "Device state" condition check - it will return the wrong state (released instead of pressed) until the button is cycled. Is this a bug, or is there a reason why it must work this way? Is there any way around it? I need, at the very least, a way to assign multiple PTT buttons, and global hotkeys don't allow for that.

[Pfeil]

I can confirm releasing a button that was pressed before switching profiles does not trigger a command mapped to that button with the "Shortcut is invoked only when all buttons are released" option enabled.

However, both the joystick state token and the device state check tab correctly reflect the current state of the button on my machine

Using this command for testing:

Code: [Select]

Write [Blue] '{STATE_JOYSTICK2BUTTON:1}' to log
Begin Device State Check :  Joystick 2 Button 1 Is Pressed
    Write [Blue] 'down' to log
Else
    Write [Blue] 'up' to log
End Condition
Log output after switching to the profile with this command in while the joystick button is held down is "1" and "down", which is correct (both when manually executing the command, or triggering it using the "Execute a command each time this profile is loaded" option).

Checked with both a DirectInput and an XInput device, with the latter mapped using the virtual "Gamepad Controller" device

[Matroshka]

OK, I had an error somewhere else in my logic when I was making a workaround and it wasn't displaying the value correctly, indeed, the value is carried correctly, so the device state is correctly maintained when switching profile, the problem is only with invoking 'on release' commands.

That can be used as workaround for now. I set up a command that runs on init for each profile other than the master profile and checks the button state, then forcefully runs the correct button release command. The only problem is that since this command needs to be present in each of those profiles so that it can be ran on init (even if the profile with this command is on included list), so remapping controls would be problematic.