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.