Lorby_SI

Maybe your firewall is intefering? Letting the data pass one way only? To be on the safe side, you should create firewall rules that allow all traffice through the TCP port that you have configured for the WebAPI - in both directions, incoming and outgoing. Creating a rule for the AAO app itself is the wrong way to go, that won't work. Sorry, my bad, but this was B.S. When you are seeing data on the StreamDeck, then the WebAPI and the connection are both fully functional. The SD plugin is sending requests to AAO and gets the data in the response. So the API is working both ways. You are certain that the buttons on your SD are working? No others plugins that could interfere? The easiest way to check would be using an empty profile and creating a single AAO "Button" Action on it. This should be picked up in AAO when you open the "Add Button" dialog (same as with a joystick or button box, but it would show "WebAPI" as the source).

Sounds strange, never heard of that before, sorry. The only situation where this does happen is when the profiles call scripts and the user forgot to import the script package(s) into AAO...

That assumption is wrong. The checkmark does not indicate that something is "active". It is just local to this dialog, the checkboxes are there for selecting the addons that you want to change the web address/port for with the buttons below the list. It is disabled when you run the StreamDeck software, because in this state, AAO cannot change the Web Address in the plugin's config file (=the buttons wouldn't do anything) Please explain a bit more what you mean by that. What does "writing back" mean, what do you expect to happen when you do what exactly? When the WebAPI works one way, it works the other way too - this is one single mechanism.

I would still use my autoscript. Since the battery LVar apparently has 10 as the "ON" value, the script would look like this: (L:VC_Battery_SW_VAL, Number) (L:MyBatRef) != if{ (L:VC_Battery_SW_VAL, Number) 10 == if{ (EXECBAT:C:\myfile.bat) } (L:VC_Battery_SW_VAL, Number) (>L:MyBatRef) }This script will always start the batch file every time the Battery switch goes from OFF to ON. It will also start the batch file when you connect AAO after you've already switched to "ON", because that is the state that it is looking for. Initially, both LVars are 0, so the script won't fire. When you click the battery switch ON, the LVar changes to 10 and the if is executed. And since you only want to start the batch when the battery is turned on, the script checks for the value "10". There are probably a dozen other ways to script this, and there are alternatives too. You could create a CONVERSATION type script file and start this when you start your flight. In such a file you can make the logic wait for certain things to happen, then proceed with doing other stuff. AAO users are implementing thier own first officer and/or flight attendant with this technique. In this case, the line that waits for the battery switch would look like this: (...some code...) [(L:VC_Battery_SW_VAL, Number) 10 ==] (EXECBAT:C:\myfile.bat) (...more code...) That CONVERSATION you start at the beginning of your flight (via Autoscript), and it will wait for the battery switch.

As I wrote above, you cannot catch the "click", that is not possible with LVars. You can only react to the animation LVar changing its value (=observing the result of the click - that is not the same). Please specify what "the first click" actually means. Do you mean every change of the switch = both ON and OFF direction? Or only "ON" because you always start in cold and dark mode?

I'm sorry, but I have no idea what you are doing there. Why aren't you just using my script? Lose the // comments. They are bad form and only slow down processing for no purpose. You know what your own script is doing, you don't need a comment to tell you. (L:MyVarBat) is AAO internal, it doesn't have a unit. Lose the ", Number" (L:MyVarBat) MUST always have the same value as the (L:VC_Battery_SW_VAL,·Number). It serves as a reference, so the script knows when the Battery LVar from the sim has changed. OK? That's the whole "trick" here, it prevents the script from just running every time. You cannot just set it to whatever value you want (why 10? why 20?) LVars don't have to be initialized. Their life begins when they are first used in code. So (L:MyVarBat) is 0 every time AAO is initialized (restarted/connected to the sim/a script is alterted/ etc.)

You cannot "intercept" an LVar - they are just values, stored in the sim under this name. If this LVar keeps its value, you can write an Autoscript that compares it with your own reference value and then triggers some code of your own design - like calling a batch file. But if the aircraft designer chose to only use the LVar momentarily, this won't work. You will have to try, there is no knowing this in advance. You would create a script like this and save it. (L:VC_Battery_SW_VAL, Number) (L:MyBatRef) != if{ (L:VC_Battery_SW_VAL, Number) 10 == if{ (SPEAK:on) } (L:VC_Battery_SW_VAL, Number) (>L:MyBatRef) }Then use Scripting->Aircraft automated Scripts to run it every 500ms or something. Then, every time you turn on the battery (or rather, flip the switch to "on"), your computer will say "on" - that's what the SPEAK command does. Replace the SPEAK command with whatever you need, probably EXECBAT - see AAO manual. Be mindful that this is just off the top of my head. None of this is tried or tested.

What do you mean by "convert"? In general I would expect that you can just use the Lorby StreamDeck editor to drag the actions from the StreamDeck profiles to the StreamDock ones (you don't need an actual Elgato StreamDeck to install their software and consequently their profiles). But it has been a long time since I tried this myself. Neither the StreamDeck nor the Mirabox plugins were meant as actual features of AxisAndOhs. They are just examples of what to use AAO's WebAPI for and how to do it. They are a bit of Javascript, demonstrating the communication between the device software and the AAO API. The plugins are not set in stone, feel free to adapt and alter them at your leisure.

It does work for me, using the "StreamDock" software that comes with the original Mirabox N4. Version number is 3.10.194.0707, no further updates are available. The devices of the various brands and their associated software can be slightly different. As the AAO plugin is just a bit of Javascript, feel free to correct/alter it to your needs. The UI software should have a debug mode or debug web page, with the Mirabox it is http://localhost:23519/ But you may have to activate debugging first, not sure.

App focus issues are usually only relevant when you are using keyboard commands? In any case, I would not start AAO with the sim, that would be the first step. Next, disable Mobiflight and Voice Attack, see what happens. (are you aware that AAO also does voice recognition?) Mobiflight in particular can be problematic when used with AAO. Both apps essentially do the same thing(s), and they can step on each other's toes. P.s.: I won't be looking at your screenshot, sorry. My AntiVirus flags that web page as malicious.

In AAO you use the (EXECBAT: command, see AAO manual around page 83 "AAO specific RPN commands". But "click on a switch in the cockpit" can have many different consequences, and only very few of them can be observed from the outside by AAO. Essentially the sim only "reports" K: events and IEs over SimConnect. For those you can use the (LISTEN_FOR_RPN or (LISTEN_FOR_K script headers to catch whatever is being sent from your switch. If the switch doesn't send anything that you can observe, that would mean that you have to alter the switches' code in the sim to make that happen. Are you the developer of the aircraft? Ideally you would add a bit of Javascript to access the AAO WebAPI and send the EXECBAT command directly.

Then I have to assume that the issue is specific to your computer. Not sure how I can help with that. I don't even know where to start looking, this has not been observed before. If I have to guess, I would say that a piece of software, another addon or a driver is interfering here. Also, when there are app focus isues, I wouldn't let the sim start AAO. I always do it the other way round, my AAO starts the sim. That also prevents problems with admin privileges.

The correct syntax would be (L:1:CONST_FEATHER_Switch1, Number) LVars that are to be synchronized with the sim must have a unit in AAO. Use "Number" when in doubt. Otherwise the LVar remains internal to AAO (so you can freely use your own LVars in your scripts without weighing down the interface to the sim). On a side note, in the latest SDK documentation for MSFS 2024 Asobo says that "L:1:" equals "Z:". Don't know if that is true though.

Sorry, but no, no idea. To me this looks like SimConnect has just been terminated from the other side - which is probably exactly what happened when the sim crashed. This does not tell you anything about the cause. I doubt that an AAO logfile can be of much use here anyway (because it is the sim that has problems, not AAO!). Only if there were hundreds or even thousands of exceptions in the file, that would be an indication that you did something wrong with your assignments. Unfortunately that is all theory, there is no viable way to nail this down in a deterministic way. I still stand by what I wrote earlier. Something in your sim or in your computer does not agree with either AAO itself, its Community packages, or the .Net framework in general. That is entirely possible, which is why there is a DEMO version of AAO that everybody should try before purchase. Just look at my own devel computer - it just does not like MSFS. No matter what I tried, I never found out why that is.

What does that mean? You don't need the Community packages in normal operations, AAO works just the same without them. They have a special purpose that you probably won't need anyway.

What does that mean? What they should be is Axis to "On Change" Joystick high sensitivity: OFF MSFS SU12 LVar processing: ON

The number of log messages is irrelevant. Only the timestamp is, that is what must coincide with your stutters. "3" is an unknown ID (of an event, variable, etc.). Some of those will always be there in the logfile because AAO forces that exception when it connects to the sim to get a baseline for future error reports (SimConnect doesn't tell you why something happens or when exactly, just "oops, something went wrong"). In general they are nothing serious, and nothing that should happen during the flight. If they happen during that flight, that would mean that AAO had to disconnect for some reason and has reconnected automatically. You would see that in the StartupLog. Just be mindful that the timing of the events is the important part, not their mere existence. In all other cases a "3" would mean that you are using a variable or event that the sim doesn't know. But then it won't just be a handful of exceptions - if you really assign an incorrect event to an axis, you will see hundreds of them. It is next to impossible to troubleshoot this. The simulator has too many moving parts, and apart from all the Javascript in play, there can be additional SimConnect clients in the aircraft logic that you don't even see. I suspect that at some point several things go wrong at the same time, and the sim stutters. Trying to find a singular cause for that is - challenging. Did you disable the lorbysi - Packages in your Community folder?

There is no such thing as a "RPN script polling rate". AAO processes the scripts, not the simulator. The app has its own RPN parser. Only atomic variable values are synchronized with the sim. AAO constantly adjusts the refresh rate to the actual capabilities of the sim, by measuring the return times. You can only increase the refresh rate by hand, by settings axis to update "continuously" instead of "On change" and by activating "joystick high sensitivity" in the hardware menu. If you didn't do this, AAO will "turn" at about 18 Hz, dynamically adjusted to the actual load situation. Make sure that "MSFS SU12 LVar processing" is ON in the Application menu. If you suspect a SimConnect flood, I suggest that you take a look at the AAO logfiles. But you would have to somehow force that flood to happen, AAO won't do that on its own in normal operations. More likely, stutters are caused by the sim processing errors internally. Those you could check using the console in MSFS developer mode. But since this is only happening on your computer, there is no frame of reference for me to give advice. To me this sounds like a general instability and that AAO is simply pushing the sim over the top. I don't even think that it is GPU related either - that you got an NVidia error was just coincidence IMO (=an exception bubbling up and ultimately being thrown by the most active component of the sim?)

The issue is probably not with the app itself, but with what you are doing with it. The behavior that you describe suggests that the app is busy processing a massive amount of errors/exceptions, potentially writing them to the logfile(s). Are you using mouse input or virtual mouse events? Speech recognition or output? Low level Windows access, like window controls (=WebFMCs v2)? A script that is calling itself in an endless loop? ...until the process memory is filled up and every new call causes an error that AAO has to process, making the situation progressively worse. Check AAOs logfiles if they are really big, with thousands of entries. "AAO plugins stop working": what do you mean by that? What "plugins" are you using? (just making sure the we are talking about the same thing there)

Opinion? Can't say that I have one. This makes no sense - at all. This problem is currently limited to your computer, which makes it impossible to reference anything. Update the graphics drivers, make sure that your .Net libraries are current, update the operating system. If there is a problem, it is likely that someone else caught it in another game/WPF app (TMBK the sim itself is one too), and that NVidia or Microsoft have corrected it by now. You could switch off the graphics on the AAO main dialog using the three little icons above the button and axis lists. But if you even have trouble when the app is minimized, that is probably futile as well. Make sure that no other addons are running in parallel, especially not those that essentially do the same thing (SPAD, FSUIPC, MobiFlight). Disable the AAO "lorbysi-content-*" package(s) in the Community folder, just to see what happens (=rename the manifest.json to manifest.off) Personally, I never had much luck with MSFS 2020. I cannot fly from any airport south of EDDF, the sim will immediately crash. If it loads at all, in most cases it gets stuck between world map and the simulation. I cannot fly for more than 30 minutes, because the sim will (of course) crash on me at around that time. All this has been happening for years now, on two different computers at that (but both development machines with many libraries and odd memory layouts). And this happens with or without AAO running. We are currently using 5080s together with AAO and lots of AAO specialities (like gauges) in a commercial (=hardware) sim that is running P3D V4 - zero issues. So it is not about the card, that much seems certain.

There is no general rule of "how" this is done. These things are potentially different for every single aircraft - they depend on what the aircraft developer has implemented. With the HJET, none of the default events works for me. I had to implement special scripts to control the thrust levers. The HJET developer made it impossible to use defaults, instead one must operate the animation LVar in a certain way. I'm not sure how I can explain this, so here is a template of my aircraft configuration. But was made for the Honeycomb bravo and a simple Thrustmaster joystick. https://www.dropbox.com/scl/fi/bzmcqy22x2jgm4wlc54qm/HJET.tmpl?rlkey=hpuwjdxkbp7tymlkene4yweod&dl=0 Btw. Events never have a unit, there is no "number" or "percent" or anything with events. Something starting with "L:" is not an event, that's a variable. Those do have units, but they work very differently from events. On a side note, I have the exact same driver version that you have, albeit with an old GTX 3090. I never had a single crash with it.

Here is another idea, which is a bit more esoteric: maybe this is about the axis that you've assigned? Maybe by choosing just the right (in this case wrong) event, some animation in the model gets "overloaded" somehow (too many frame changes, animation position out of range?) and causes the delay and the crash? Did you try this with other axis - or even just a single button? What about different aircraft?

AAO does not do any graphics related calculations. If anything, it is the .Net WPF framework that the app is running on that could cause it (=Windows itself) . If that is the case, then AAO will not be the only app where this can happen. But. In 6 years you have been the first and only person of a low 5 figure total number of users to report this. IMO that would suggest that this particular behavior is specific to your computer. Please note that AAO should always be run minimized (there is a feature to do this automatically in the Application menu). When nothing is rendered, there shouldn't be any problems - right (?? I don't really know, just guessing).

Sorry, but that is intentional. For one, the SimConnect API doesn't care about app focus, it always works, even from another computer. Second, many people are running additional apps and addons alongside the sim. If AAO would only work when the sim window has the focus, it couldn't do its job, it would constantly be blocked by the app focus being shifted elsewhere. Besides, many people are using full screen mode and might not even be aware of app focus. Granted that this is a problem for keyboard based setups. Which is why many simmers get themselves a button box of some kind, like the StreamDeck, Behringer X-Touch, etc. The only solution off the top of my head would be to have a special button/combo that you use to toggle the AAO controls on or off when you need them. For example with the AAO Control Layers, you would put all your button assignments on the yellow layer. Then you would add two additional button assignments that switch bettwen the default/gray layer and the yellow one. When you fly, you switch to yellow, when you do something else, you switch to default (or red,green,whatever). Same principle could be applied using the AAO Combo Button feature - you add the same "Combo" assignment to all buttons, setting it to toggle mode. Then you can use that to toggle all buttons on or off.

Yes. That doesn't happen. But if you want to be extra careful, create a backup of your current database using the "Tools" menu in AAO.