May 25, 20224 yr Hey lorby! Finding that when using streamdeck pluigin, I often run into an issue where the streamdeck takes a few "extra presses" to actually work. Guenseli makes some great profiles for different MSFS aircraft, and even he notes in the release notes of his profiles that "You have to press some buttons twice on the StreamDeck initially before they will work. Don't know why. Once it is done, they work every time." Is there any way that either the plugin or AAO can "initialize" the state of the buttons in a profile to prevent this? It's quite annoying when you (for example) you turn strobes on for takeoff, only to find that you didn't because you have to press everything twice the first time. Thanks for any insight!
May 25, 20224 yr Commercial Member Hello, Are you saying that the action is not displaying the correct state until you press it (twice)?? Can't say that I've seen that one before. This sounds more like a problem in the action itself, like two different "syntaxes" for the same variable could cause this. AAO is case sensitive, so this can happen easily. But I would need specific information = what action accessing which variable and event is requiring a double action. I have no opinion about the cause, let alone a "fix" at the moment. To be fair, the plugin had this problem a long time ago. This should not happen anymore. As for an initialization - no, that is not really possible. AAO doesn't know about the plugin nor does it care. The SD plugin is just another "thing" accessing the WebAPI in AAO. But if there is a specific type of action or event that causes problems, I can look into it. Edited May 25, 20224 yr by Lorby_SI LORBY-SI
May 25, 20224 yr Author Quote Are you saying that the action is not displaying the correct state until you press it (twice)?? Can't say that I've seen that one before. This sounds more like a problem in the action itself, like two different "syntaxes" for the same variable could cause this. AAO is case sensitive, so this can happen easily. But I would need specific information = what action accessing which variable and event is requiring a double action. I have no opinion about the cause, let alone a "fix" at the moment. To be fair, the plugin had this problem a long time ago. This should not happen anymore. As for an initialization - no, that is not really possible. AAO doesn't know about the plugin nor does it care. The SD plugin is just another "thing" accessing the WebAPI in AAO. But if there is a specific type of action or event that causes problems, I can look into it. For example, this preset uses various types of the AAO button types, the most obvious ones for an example I guess would be Toggle and Slider guage. Example 1 APU Master ON Streamdeck AAO Button type: Toggle Sends "1" for ON state for a variable called "FENIX_A3XX-ELEC_APU_Master_TOGGLE" But as described in my OP, most of the time when you load into the flight, you have to press that button twice for it to actually turn on the APU. This is not a fenix A320 issue because it holds true for default aircraft in MSFS too. Example 2: Nosewheel light switch Streamdeck AAO Button type: Slider guage Sends K: value to FENIX_A3XX-LIGHT_EXT_Nose_TOGGLE which alternates between OFF, TAXI, TAKEOFF Same as the first example, you have to press that button twice for it to actually start switching the switch. I'll see if I can get the creator of the streamdeck presets to weigh in here too if they are willing/if it is helpful. Edited May 25, 20224 yr by jstnj
May 25, 20224 yr Commercial Member 1 hour ago, jstnj said: I'll see if I can get the creator of the streamdeck presets to weigh in here too if they are willing/if it is helpful. I'm already in contact with "Guensli", he is also a tester for AAO. From the looks of it, this happens with SD actions that trigger scripts with LVars in them, that are not read anywhere else. This can lead to a race condition in AAO the first time the script is fired, where the script is dismissed because it takes the sim interface too long to return the LVars' value. This seems to depend on how powerful the computer is too, because it doesn't happen to me every time (but often enough). I will see if I can do something about that. In any case, it would be better to run these scripts (=that practically remain "inside" the sim) with the (SIMPROC) command. Every LVar that you don't need anywhere else should stay in the sim. Otherwise it is constantly and needlessly read by the interface all the time. Edited May 25, 20224 yr by Lorby_SI LORBY-SI
May 25, 20224 yr Author 15 minutes ago, Lorby_SI said: This seems to depend on how powerful the computer is too, because it doesn't happen to me every time (but often enough). I will see if I can do something about that. Thanks for looking into it. For what it's worth, I have a Ryzen 5900X, 64GB ram, and I experience this pretty much every time.
Archived
This topic is now archived and is closed to further replies.