Lorby_SI

There is a separate variant of AAO for MSFS 2024 that must be installed as an additional app. Each AAO variant is a Windows application in its own right. Each has been compiled for the simulator it is meant for and has the appropriate SimConnect libraries. The AAO apps don't share any data, except for the folder in Documents. Check your account in the shop where you bought AAO for the separate MSFS2024 installer.

No, sorry. I programmed a flight at EDDF 20 minutes ago and took off towards LIRF. The buttons still behave the same as they did at the beginning. They are not the fastest, mostly due to the low update rate that has been set in the WebFMC. About 8 times per second or lower, so it doesn't overload AAO's network API. As long as you didn't change the resolution or the size of the captured window, that should work fine. But this popout technique puts a significant strain on the network, your computer and the sim, no doubt about that. Be mindful that you cannot compare this to the iFly or the PMDG WebFMCs. Those use completely different techniques, and they are a lot less performance intensive.

The package has not been installed correctly, part of the path is missing. No wonder that it didn't work. The correct path is this one, exactly like it is in the ZIP file: \Documents\LorbyAxisAndOhs Files\WebPages\fmcs\a300 only then all parts are in the correct location.

That file is for the EFB, not the CDU. The iFly has its own SDK, similar to PMDG. The script is there to tell AAO to collect the data from that SDK. The A300 has neither - no SDK, no script. With this plane (and most of the other Vol2 WebFMCs), AAO wants to capture and stream the popped-out window showing the CDU screen. It also moves that window to a position outside your screen, so it won't cover your simulator. Apparently, something about this process is going wrong on your computer, but I don't know what that could be, sorry. I would probably take a look at the error console/developer tools of your browser, maybe prevent the move off-screen (global.js WINDOWPOSITIONSET) to see if the popout is there in general, or even try a different browser altogether. For example, old-er iPads cannot display HTML5, that has tripped up some people too. Normally, when the CDU cannot be popped out automatically, you do it manually, and then refresh the web page (F5).

There is no such script. A300 uses popout, iFly has a native interface. Completely different technologies.

Theoretically yes, and you could do it yourself. This is all open source, you can duplicate and edit to your heart's content. The most effort will be to figure out the button bindings for each new CDU. Just be mindful that opening more popout windows will potentially eat into your FPS.

That would only mean that the web page cannot pop out the screen on its own. The only way to figure that out is trial and error. Be mindful of the mousepos too. What the web page tries to do is call up a camera view that includes the CDU, then place the mouse in the middle of the CDU and pop it out for you. But when the web page also can't find the instrument that you have popped out manually, then one explanation would be that the name of the popout window is different from what it should be. That's in the line above, "popname = ". It expects the window to be called "WASMINSTRUMENT". If your manager app changed that name, you will have to change it here too.

Sorry, no idea. Working fine here with the inibuilds model. Different A300? Modded maybe?

Double check that you write the LVar exactly the same everywhere. AAO RPN is case sensitive and space characters matter too. If you cange upper/lower case or have too few/too many spaces, AAO sees them as different variables.

<Element> <Position X="90" Y="45"/> <GaugeText> <FontFace>ARIAL NARROW</FontFace> <FontHeight>18</FontHeight> <FontColor>0xffffff</FontColor> <HorizontalAlign>CENTER</HorizontalAlign> <Value>%(L:somename, String)%!s!</Value> </GaugeText> </Element>

I would have to see the actual code of the AAO FIP. Be mindful that there is a PDF about how to create AAO gauges and also a Gauge Editor dialog within AAO. The correct element would be <GaugeText> It will never work in a simulator XML gauge though, because they don't support these LVars. String LVars are an AAO exclusive construct, they don't exist in the sim/SDK. You would have to create a html instrument instead of the XML gauge and query the AAO WebAPI from that.

Try popping out the FMC manually first, then call the web page.

Replace in what capacity? What WAMA can still do is track and park the aircraft that you actually fly (provided that the 3D model of the aircraft can be injected as a new object). What WAMA cannot do (and TMBK nothing else can) is provide a list of all aircraft that you have in your hangar. That data is often only "in the cloud", there are no local config files to parse etc.

Depends on what you mean. WAMA cannot stop MSFS from crashing when querying certain sceneries. Also, the streamed content in MSFS 2024 rules out any hope for WAMA gaining full functionality like it had in P3D. Add to that the issues with the AI aircraft in general. Now that you remind me, I think that the time has come to retire WAMA for good. It has had its time, but that is in the past.

Sorry about that, that's a glitch in the interface to XP. Just delete the configs that you don't need. This will be improved in the next version of AAO, that will be using the new API in parallel. If you want, send an email with your proof of purchase to the support address and you can try the current development version. Address is on the last page of the manual.

Depends on what you mean - the display/dial in the sim or the display on the StreamDeck button? 1. Behaviors in the sim: generelly no. But there are probably a dozen things that could theoretically cause this, but none of those is actually "known" or documented. Off the top of my head I'd say that this would depend on which controls of what aircraft you have assigned exactly how, what else the StreamDeck profile contains and how many scripts are in play in AAO in general that may cause delays. On top of that, the communication between the StreamDeck plugin and AAO is done via your IP Network stack. So, in addition to USB problems you may have, any incursions that involve your network processing would also interfere (like big download streams running in the background). Mind you, this is all theoretical. I've actually not heard of this behavior before. 2. On the StreamDeck itself: What will happen though is that the display on the StreamDeck itself will be choppy, and that is actually normal. The actions are only refreshed every x milliseconds (depends on what you set in the settings.js file), so there cannot be "fluid" changes by definition. Dialling up the refresh rate will potentially cause other problems, so compromises have to be made. But this would also depend on what the action + plugin + AAO + sim have to do in order to process your input. So this may be an issue with some planes and implementations but not with others. Personally, I've never noticed either - but I'm not a "power user".

Strange that the Toggle-BVar wouldn't work. But you never know, developers can do whatever they want in that regard. Try scripting the toggle functionality 1 (IE:CS_INPUT_P17_003_SW2) - (>IE:CS_INPUT_P17_003_SW2) (I don't have this plane so I cannot test it. But if the IE behaves in the way that you describe, the script should do it. It reads the value of the IE, subtracts it from 1, and writes the result back into the IE) Small scripts like this one don't have to be implemented with the script editor. You can copy&paste them directly into the button assignment by switching the Key Down/Key Up to "MAN" (with the little green button below the box), then selecting "RPN" as the type and pasting the code into the box.

You seem to have found this IE in the AAO event list that you opened from thecAdd Button dialog? In that list, click on that event once, so the sub-set of its generic bindings opens (the so-called BVars). There should be one named ..._Toggle. Double click that to transfer it to the button. Normally that does the trick for a momentary button.

I found an AAO script package for the FFS 727 on fs.to. Axis and Ohs Scripts for FSS 727 - Utilities for MSFS | Flightsim.to

None of these assets follow any rules or guidelines, the aircraft developers just inplement whatever they want. In many cases they do this without caring about the specs that Asobo has laid down. There are at least a dozen ways to operate knobs -and even more to make them in-operable from the outside, so they only work with the mouse (like the spring-loaded GEN switch in the C208 for example) - IEs never have "SET, DEC, INC". They only have a name - BVars are the "bindings" of an IE, the two belong together. They can have any "do-word" attached that the developer deems appropriate. There are no rules. - (L: (B: (IE: (A: etc. -> that is the syntax for READING from a variable - (>L: (>B: (>IE: (>A: etc. -> that is the syntax for WRITING to a variable or event. - When using LVars in AAO, you must supply a unit when the variable is to be sent to the sim: (L:whatever, Number) Example: (L:FSS_B727_PCP_EPR_KNOB1, Number) 1 + (>L:FSS_B727_PCP_EPR_KNOB1, Number) Otherwise the LVar is only used internally in AAO I would suggest staying away from ChatGPT. The topic of simulator behavior code is so esoteric that there is only a limited number of actual people who actually understand it. A chatbot on the other hand can only answer half way correctly to well known questions and facts. Statistically, 85% of chatbot answers are doubtful and 45% are outright wrong. Seems more like waste of time to me.

Here you go: https://www.dropbox.com/scl/fi/fezkl6lkfhe6as7ovbhv4/cj4fmc.zip?rlkey=61fxa7agz5cwqrlc46z9m1ein&dl=0 This is the old native CDU technique as an AAO web page (in fact, it is actually the old one...) but with an updated Community package for MSFS 2024. I've tested it with the CJ4 and it seemed to work fine. The WT21 supports the MSFS2024 instrument plugin system, so no problems there.

Sorry, no clue. Node JS is not my world. And Mobiflight even less so. From my point of view it would be a lot easier to make a native bridge, similar for example to the one that I made for the BKSQ Starship. Or maybe this requires a Plugin, like the WT G1000. This would require that you familiarize yourself with the Coherent Debugger from the MSFS SDK. Very powerful tool to analyze the HTML/Js part of the running sim.

Sorry, but that won't be possible for the forseeable future. It takes just too much of an effort. But the technique is not that hard to learn, and everybody is welcome to try their own hand at this. Although I am not sure that it can even work in FS24.

Ah, OK, sorry - I forgot to update the original thread after I made the change in the app.

You're welcome. Also, don't forget about the voice recognition feature in AAO - that may provide even more interaction (if you don't have something like Fs2Crew or MultiCrewExperience already)