Hello,
Not sure if anyone else is having this issue. I have been using AAO for a while. After SU7 however, all of a sudden some excessive stuttering is happening.
The Mainthread is constantly going from 3ms (normal) to 1000ms…it cycles back and forth like that.
I removed everything from COMMUNITY folder, but only when I remove AAO does the problem go away.
Please let me know if anyone else is having this issue.
Also, anything I can check on my end? I am using the latest AAO version.
Thanks!
Oh ok, sounds like FBW incorporated some items from the Exp version (where these knobs didn’t work with NAV/Range LVARs with above script).
But no I don’t have the most recent Dev version, so haven’t looked for these LVARs. Hopefully someone who has the latest version will chime in.
I am starting from a SD multiple actions button. First AaO as admin, then MSFS. AaO switches form “Waiting for SimConnect” to “Waiting for aircraft data” closely before the main menu appears. I have only one template and I almost always using the same aircraft. I am starting in chase view (and stick to it if weather permits).
And that is the problem why AAO can’t detect the aircraft. I know that sounds strange, but it is what it is. Nothing can be done about it, except going back to the old logic where AAO would load the aircraft scripts way too early. Some aircraft just don’t like that. The real issue is though, that the simulator events that are supposed to tell the SimConnect client that the aircraft is ready, are sent at least three times during the loading phase of the flight. That is why we had to resort to these desperate measures with MSFS, like waiting for the cockpit view to come up.
Sorry, can’t say I’ve heard that one before.
Are you running any automated scripts? What external hardware do you have?
This sounds like you either have an excessive amount of SimConnect traffic going on (check that all axis assignments are set to “on change”) or something is stuck (joystick button with repeat) - or you have an error in a repeating script or variable call that is causing exceptions in the sim. You would see that in the AAO logfiles, they are huge if that happens.
Okay, setting default camera to “cockpit” helped. Now the aircraft gets detected when the flight gets loaded. But until I ran into the trouble I reported, I had a post SU7 installation which recognized the aircraft at boot in both constellations, 2.21/4.44 and 2.22/5.03. I am just saying, I do not mean to ask you to do something about it, I just wish to understand what is different now to my system then it was before the trouble I had.
Mode dec:
(L:A32NX_EFIS_L_ND_MODE, Number) 0 > if{ (L:A32NX_EFIS_L_ND_MODE, Number) 1 - (>L:A32NX_EFIS_L_ND_MODE, Number) }
Mode inc:
(L:A32NX_EFIS_L_ND_MODE, Number) 3 <= if{ (L:A32NX_EFIS_L_ND_MODE, Number) 1 + (>L:A32NX_EFIS_L_ND_MODE, Number) }
Range dec:
(L:A32NX_EFIS_L_ND_RANGE, Number) 0 > if{ (L:A32NX_EFIS_L_ND_RANGE, Number) 1 - (>L:A32NX_EFIS_L_ND_RANGE, Number) }
Range inc:
(L:A32NX_EFIS_L_ND_RANGE, Number) 4 <= if{ (L:A32NX_EFIS_L_ND_RANGE, Number) 1 + (>L:A32NX_EFIS_L_ND_RANGE, Number) }
Okay I did some more tests. I re-installed 2.21/4.44 during the trouble-shooting and so far I stick with it. In main menu I don’t have an aircraft template in AaO - I always had, even post SU7, even with chase view as default. Now when I start a flight I have to wait like several minutes until the SD gauges get updated and the buttons can send key events. It wasn’t like that befoe, again: even post SU7 in chase view. Well it is not like it doesn’t work at all. But it is not as it used to be. Any more ideas?
Thanks for the quick reply. After some more testing, I found out that if I let AAO start up automatically during MSFS startup, the issue occurs.
If I start AAO after complete startup of MSFS, it seems to be working fine.
I’ll check for the logs you mentioned. I was wonder if I messed up a script somewhere…
Thank you very much!
So what happens when you turn the knob really slowly? Is there another button actuation between two clicks or not?
no only one button actuation and frequency change by two
I don’t run both fsuicp an AAO
What aircraft is this exactly?
Did you try the same with a normal Joystick button, to see if that also changes the frequency by 2? Did you check what the HVar is doing when you trigger it on its own, in an RPN script?
Edit 1: I have just tested the event that is visible in your screenshot with the TBM 930 (no mods). One click with my joystick button = Frequency changes by 1.
Edit 2: tested the full assignment, INC and DEC mapped to a rotary encoder of my X-Touch Mini - frequency again changes by 1 in each direction.
Either your input device is sending two events that you can’t see, or you have something else going on. I have a tester in Canada who is also using Bodnar hardware. He will look into it, but that will take a couple of days.
Just in case I will add a “Skip” option in AAO version 2.23 so you can tell it to ignore unwanted input events between “clicks”.
Edit 3:
A script to ignore every other event would look something like this:
1·(L:AS3000_T_H_TK_L_INC)·-·s0·l0·(>L:AS3000_T_H_TK_L_INC)·l0·0·==·if{·1·(>H:AS3000_TSC_Horizontal_TopKnob_Large_INC,·Number)·}
(l0 ist lower case “L0” not the number “ten”)
Yesterday it worked after the aircraft got detected in cockpit view (which I never needed to use for AaO to work before). The SDs got connected after several minutes which is a time I didn’t need to wait before. It was too late for me to actually to a proper flight. Then I closed the sim, started it again. I haven’t change a thing. Yesterday it took several minutes until the SDs finally loaded variables - today nothing. It is just not working, totally frustrating.
The SD is not really “connecting” to anything. AAO is running a web server. And the SD plugin is trying to send messages to it and expects a response. Nothing more. Same thing as if you call up a web site and stream a video.
The most common cause for “disturbances” is that something on your computer is messing with the IP transmission, for example by blocking the port. So the first thing to check is if there is trouble with your TCP/IP stack, either through interference or by design (antivirus, firewall). The safest thing to do is to change the web port on both ends (settings.js and AAO) and restart the computer. Port 6080 seems to be a pretty safe bet. If that doesn’t help, check the Elgato debug console for web or javascript related errors or cross-compatibility issues with other SD plugins. These things don’t just happen, there is always a reason. You can also check if the AAO WebAPI is working by sending simple commands with your webbrowser - or test the WebFIPs, see if they work.
Last but not least, if AAO itself is in trouble, it will write logfiles here: \AppData\Local\LORBY_SI\LorbyAxisAndOhsMSFS
But please don’ t just post logfiles in this thread, a forum is not the place for that. Send them to the email address on the last page of the AAO manual, including your proof of purchase.
Hi all,
I have been using these scripts to increase and decrease altitude in the FBW A32NX but for some reason the Decrease Altitiude has stopped working. Does anyone have an updated script i could use please?
3·(A:AUTOPILOT·ALTITUDE·LOCK·VAR:3,·Feet)·(L:XMLVAR_Autopilot_Altitude_Increment)·>=·if{·3·(A:AUTOPILOT·ALTITUDE·LOCK·VAR:3,·Feet)·(L:XMLVAR_Autopilot_Altitude_Increment)·-·(>K:2:AP_ALT_VAR_SET_ENGLISH)·(>H:AP_KNOB_Down)·(>H:A320_Neo_CDU_AP_DEC_ALT)·}
For some reason, the increase altitude script still works fine!
3·(A:AUTOPILOT·ALTITUDE·LOCK·VAR:3,·feet)·(L:XMLVAR_Autopilot_Altitude_Increment,·Number)·+·(A:AUTOPILOT·ALTITUDE·LOCK·VAR:3,·feet)·(L:XMLVAR_Autopilot_Altitude_Increment,·Number)·%·-·49000·min·(>K:2:AP_ALT_VAR_SET_ENGLISH)·(>H:AP_KNOB_Up,·Number)·1·(>H:A320_Neo_CDU_AP_INC_ALT)
Thanks
If LVars are supposed to be read from/written to the sim, they require the “, Unit” part.
In your first script, the XMLVAR doesn’t have the “, Number” while in the second script it does.
LVars without the Unit never leave AAO.
(the rules have become more rigid in AAO 2.22)
Like Lorby said it’s missing unit. Either add the unit or add SIMPROC: in front of the script (first mention is better solution)
If you want to have real behaviour with altitude changing (when 1000ft increment is selected and alt is 0100ft, it will jump to 1000ft instead of 1100ft) and also limits 0ft - 49000ft use these scripts
Dec:
3 (A:AUTOPILOT ALTITUDE LOCK VAR:3, feet) (L:XMLVAR_Autopilot_Altitude_Increment, number) - (L:XMLVAR_Autopilot_Altitude_Increment, number) (A:AUTOPILOT ALTITUDE LOCK VAR:3, feet) (L:XMLVAR_Autopilot_Altitude_Increment, number) % - (L:XMLVAR_Autopilot_Altitude_Increment, number) % + 100 max (>K:2:AP_ALT_VAR_SET_ENGLISH) (>H:AP_KNOB_Down) (>H:A320_Neo_CDU_AP_DEC_ALT)
Inc:
3 (A:AUTOPILOT ALTITUDE LOCK VAR:3, feet) (L:XMLVAR_Autopilot_Altitude_Increment, number) + (A:AUTOPILOT ALTITUDE LOCK VAR:3, feet) (L:XMLVAR_Autopilot_Altitude_Increment, number) % - 49000 min (>K:2:AP_ALT_VAR_SET_ENGLISH) (>H:AP_KNOB_Up) (>H:A320_Neo_CDU_AP_INC_ALT)
I use Axis and Ohs to opearate the Aerosoft CRJ panels, including FCP knobs for selecting course, speed, heading, etc.
Following RPN script used to work correctly for heading selection (example) - it was changing the selected HDG but also it was triggering the knob turning animation (visual feedback):
(L:ASCRJ_FCP_HDG_SEL,·Number)·10·-·dnor·(>L:ASCRJ_FCP_HDG_SEL,·Number)·(L:ASCRJ_FCP_HDG_CHANGE,·Number)·--·(>L:ASCRJ_FCP_HDG_CHANGE,·Number)
Now the script still changes the value, but no longer triggers the knob turning animation.
The only script which still triggers the animation is for V/S selection:
(L:ASCRJ_FCP_WHEEL,·Number)·10·-·dnor·(>L:ASCRJ_FCP_WHEEL,·Number)·(L:ASCRJ_FCP_WHEEL_CHANGE,·Number)·--·(>L:ASCRJ_FCP_WHEEL_CHANGE,·Number)
The script structure is the same, so I have no clue why it works for V/S and doesn’t work with HDG and all the other knobs.
The issue was probably introduced with the recent CRJ update or SU7.
What am I doing wrong?
I can turn the knob with the mouse wheel, the amination works, however I’m unable to tell if actually ASCRJ_FCP_HDG_SEL is used.
I received a hint that the issue might be related to the recent CRJ update:
Thanks guys,
It was the “number” but no idea why it worked before. Have been flying the CRJ the last week and came back to the Neo today and it stopped working! Maybe one of the updates
Previous versions of AAO would send the entire script to the sim when there was a K:2 event in it, because those can’t be processed with SimConnect. Since version 2.22 that no longer happens, the K:2 is handled separately so you can do more advanced calculations around them.