Lorby_SI

Ah OK, now I get it. The mag events are all on/off toggles. That's why they behave like they do. I've updated the template, it should work for all planes that use the default mag events.

That one is the perfect example of what I was talking about. You can control all 4 switches at the same time with the "global" SDK events (MAGNETO_OFF, MAGNETO_RIGHT etc.). But you cannot control them with the individual events (MAGNETO1_OFF, MAGNETO1_RIGHT etc.). Some weirdness in the aircraft code interferes with the individual events and makes them move the knob to incorrect positions. Apparently, for this aircraft, individual scripts are required to achieve individual control. Here is a template that does this - bear in mind that it was made for the Bravo Throttle, you will have to reassign all positions of the rotary encoder and the button that switches the layers. PMDG_DC6_MAGS.zip

That is not what I meant. Most aircraft don't use the default SDK events at all for cockpit interaction (but they might use them inside their own code). In this case, in order to assign stuff in AAO, you have to analyze the behavior code = what exactly is happening inside the aircraft/simulator "under the hood" when you operate the switch/knob/lever/whatever with the mouse. Then replicate this code in AAO. The mouse is the preferred/official control method, that is why one has to take this route. The standard way to do that is to activate the MSFS developer mode, open Tools->Behaviors, then click back into the sim, hover the mouse over the knob/lever/etc. in question and press Ctrl+G. That will in most cases load the behavior code, and you can look at the ...Interaction... or ...MouseRect... components to figure out what you need to do in AAO. If the aircraft is reacting to the default event, fine, you're good. If the aircraft developer provided MSFS IEs, even better. If there is neither option, behavior code is the way to go.

When you already know how to target each individual magneto, I suggest that you follow my instructions above. Create the appropriate assignments for each engine, then move them to other control layers. One layer for each engine, with a button to switch between the layers.

Go to Hardware->Device Blacklist. Move all items into the list on the right with the "Ignore" button, except the game controllers that you are using in AAO. Also Ignore all keyboards and mice. Also, make sure that Mouse Yoke is not active, should you be using that.

AAO is using BOTH ports. Both Xp APIs have their strenghts and weaknesses, so the app is accessing both for what it needs to do. I suspect that this is about the hard coded "localhost". I should have used the configured IP address instead. Sorry, but I was wrong about the localhost thing. This is not the issue here, the app is correctly using the IP address that you provide on the setup dialog

The actual implementation will probably be different for every single aircraft. AxisAndOhs is essentially just a translator between you and the MSFS SDK. The variables and events that you see in the AAO lists are those from the official MSFS SDKs. Unfortunately, aircraft developers don't care much about these standards, and they implement their control schemes whichever way they want (IEs, BVars, LVars, whole scripts). In some cases, there isn't a way to move a switch in the cockpit at all, because they only implemented mouse controls. Personally, if you need individual controls, I would use AAOs control layer logic for that Figure out if the engine/magneto controls can be actuated remotely - like, at all Then figure out how to do what you need for a single engine, create the necessary button assignments Copy, paste and edit these assignments for the second engine, and move them on the yellow control layer Repeat for the third engine, put those on the red layer Repeat for the fourth engine, put them on the green layer Assign the event "AAO_CONTROL_LAYER_TOGGLE" to a button - each click will switch to the next layer and give you control over that specific engine. I can create a template for one of your aircraft, but I will need the exact name, model and developer for it, and a detailed description of what operation you are doing with the mouse that you want to implement in AAO. Be mindful that I don't have an Alpha, I can only do this with the rotary selector on the Bravo - hoping that it works the same way (=each position corresponds to a joystick button press)

Something must have changed? Did you update AAO to the latest variant? If you did, then the interface to XP has definitely changed and you need the latest version of XP too. The legacy XP API was unreliable when it was reading the aircraft name strings. The new version now uses the equally new XP Web API on "//localhost:8086/api/v3/" I imagine that maybe the "localhost" part may be going wrong for you. I suggest that you send an email with your proof of purchase to the support address (address is on the last page of the AAO manual).

It is what it is. Files in the cloud aren't files at all, they are just download links. So if you store all your \Documents\ only in the cloud, then AAO will not be able to use that folder. It will instead (automatically) use its' configuration folder in \AppData\Local\LORBY_SI\

If those are the Vol.2 FMCs, then they have been installed incorrectly. You must keep the structure \Documents\LorbyAxisAndOhs Files\WebPages\fmcs\... intact, with the URL /webapi/fmcs/c750/. The global.js is in the top folder "/fmcs/" On a side note, AAO can be in trouble when you are outsourcing your user account data to OneDrive - like you seem to be doing according to the path that you posted above.

I don't understand. The "docs" are exactly one PDF: "Using AxisAndOhs on a remote computer with MSFS.pdf" - and that has barely two pages. What exactly is confusing about it - so it can be improved? Again - this is not about networking AAO, you have to search for instructions about networking SimConnect. And the process for networking SimConnect has been unchanged since 2008 and it is the same for FSX, P3D and MSFS - that is I why I assumed there should be such instructions available. Get the IP V4 address of your server computer (= the one that is running the sim) For example by opening a CMD window and running "ipconfig" For the SERVER: Edit the SimConnect.XML file on your server as instructed by the PDF (create a backup copy just in case). Essentially, change the "Static IP4 port" entry to <Scope>global</Scope> and add <Address>whatevertheipis</Address> For MSFS 2024 shop version the file is here: "\AppData\Local\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalCache" For the CLIENT: Edit the SimConnect.cfg file that is in the package =enter the server's IP address at the correct spot and save it on your client computer (where you intend to run the networked AAO). The file is simply saved to the default "\Documents\" folder. Install AAO on both computers Run AAO (only!) on the client computer, go to "Application" and activate "Networked SimConnect" That's it. The remote AAO will connect to the sim just like it would when you run it on the local computer. Due to the SimConnect.cfg file all SimConnect client programs know where to contact the server. AAO Gauges and other user content go into the same folders on the client as they would on the server. This principle is applicable to all external SimConnect apps, it is not about just AAO. If both files have been edited correctly, then all that could interfere is network security - unfortunately, nobody can really help you with that, all firewalls, routers and AV products are different. I've just tried it, and this works absolutely fine with the latest version of AAO. The whole process to set this up barely took 15 minutes (but I've done this many times before, so the comparison is probably unfair).

I've updated the installers for the DEMO on flightsim.to and the AAO website. They should work correctly now. Make sure to try the DEMO again before you buy the app.

OK, I figured it out. For some reason, the DEMO version is packaging the wrong SimConnect version. I will make a new installer for the DEMO.

And AVSIM is getting on my nerves. I am getting timeouts all the time.

There is something wrong with the DEMO version. I will look into that, but at the moment I'm at a loss.