Lorby_SI

Sorry, I'm away from the computer this week. The aforementioned IE works fine for me, together with the reverser toggle button ( also IE ) There is no reason why it shouldn't work for you??

AAO and SPAD are not related. As I wrote above, AAO doesn't know and doesn't care about custom variables. As every aircraft developer can just invent them, there is IMHO no point in even trying. When you know their names, you can just use the variables in Scripts or add them to the database manually if you really want to. AAO doesn't have to know them in advance, they just work - as you can see in the scripts above. If you insist on seeing a list of the LVars, use "Scripting->Read LVars from sim" in AAO. This will add all currently available LVars to a group called "Local Simulator Variables". Just be aware that there is A LOT of them. Using the MSFS developer mode / Tools->Behaviors / Ctrl-G method to find out about the actual control in question is way better. Mostly because LVars are not the recommended choice for operating controls - that they sometimes work is often more of an accident (again IMHO). Look for "MSFS Input Events" first, which are in the Event treelist anyway in a group of the same name (if the developer chose to implement them)

I've just uploaded a new version of the EJets WebFMC too. There were some styles missing (like the white lines on the Radio page).

I thought that I did just that? Yes, it is working. When the screen is blank, then the Community package "zzz-lorbysi-aao-fsse170mcdu" for that WebFMC is either missing, disabled or otherwise non-functional in your sim.

What you are seeing is the representation in your Windows Registry. Not all of the devices are actually there, but Windows remembers them anyway...

n·(>L:FSS_EXX_AUTOBRAKE,·Number) n goes from 0 to 4 for the 5 positions of the selector The actual solution will depend on what control you want to assign to it (button, axis, rotary encoder..?) For example, this script is a one button toggle that cycles through all positions of the autobrake selector 0·1·2·3·4·3·2·1·(L:FSS_EXX_AUTOBRAKE,·Number)·(L:EJET_AB_IDX)·8·iseq·(>L:FSS_EXX_AUTOBRAKE,·Number)·(>L:EJET_AB_IDX)

Still sounds weird. That is not something that is known to happen. Maybe try disabling the Windows USB power management features (there is an option for that in the Tools menu - it is only available when AAO is started with the "As Administrator" option because it is changing the Registry. Computer has to be restarted after making this change)

Careful with LVars. They are just variables, there is no guarantee that changing their value will do anything useful. With MSFS, try Input Events first (they are in the event group "MSFS Input Events" when you are sitting in the cockpit). All others, BVars, LVars, HVars, if you know their names, you can just use in scripts, AAO doesn't have to know them in advance. There is an option in the Scripting menu to read all LVars from the sim (just be aware that there are LOTS, as they are primarily used for animations and internal coding), or you use the MSFS developer mode "Tools->Behaviors". The latter has the added benefit that you can call up the behavior code for the controls in the cockpit by hovering the mouse over them and pressing Ctrl-G. Then look at the Asobo_GT_Interaction...LeftSingle/Wheel/Drag etc. which contain the code that you want to replicate in the app.

Or use your own LVar to switch between 100 and 1000 Example: (L:FSS_EXX_FGC_ROT_VAL_ALT,·Number)·(L:MyAltInc)·0·==·if{·100·}·els{·1000·}·-·(>L:FSS_EXX_FGC_ROT_VAL_ALT,·Number) (L:FSS_EXX_FGC_ROT_VAL_ALT,·Number)·(L:MyAltInc)·0·==·if{·100·}·els{·1000·}·+·(>L:FSS_EXX_FGC_ROT_VAL_ALT,·Number) And you set (L:MyAltInc) to 0 for 100 increments and 1 for 1000 increments.

You have AxisAndOhs, right? Then you can make scripts that increment/decrement any amount you want. FSS are using an LVar that contains the altitude value, and that can be incremented at will. (L:FSS_EXX_FGC_ROT_VAL_ALT,·Number)·100·+·(>L:FSS_EXX_FGC_ROT_VAL_ALT,·Number) (L:FSS_EXX_FGC_ROT_VAL_ALT,·Number)·100·-·100·max·(>L:FSS_EXX_FGC_ROT_VAL_ALT,·Number) (L:FSS_EXX_FGC_ROT_VAL_ALT,·Number)·1000·+·(>L:FSS_EXX_FGC_ROT_VAL_ALT,·Number) (L:FSS_EXX_FGC_ROT_VAL_ALT,·Number)·1000·-·1000·max·(>L:FSS_EXX_FGC_ROT_VAL_ALT,·Number)

So I bought the 190 series just now, and the web MCDU is working just fine for me, same as for the 17x - without any changes. Make sure to follow the instructions in the readme file and that the addon package for the WebFMC is in your Community folder.

WebFIPs don't utilize CSS. It would help if you would post the actual code of that gauge, so I can try it on my end. Normally the fonts look the same in Desktop and WebFIPs, I haven't seen the effect that you describe before. Or send the gauge to me by email, the address is on the last page of the AAO manual. Please don't forget to send your proof of purchase too.

Sounds weird. I have the HC Throttle too, but I don't have any problems with it. Could it depend on what is assigned to the switches? Any specific examples? There are so many options of what can be assigned, and most assignments can be done in multiple different ways. It is absolutely impossible to give any generic advice, sorry. Make sure to blacklist all other hardware in AAO, so it can't interfere with the items that you do want to use (Hardware->Device Blacklist). Also, make sure that nothing else interferes, most importantly the simulator itself. You can only assign the same "thing" either in MSFS or in AAO, but not in both at the same time.

I've made a couple, but it was a real nightmare. Your only chance of creating a fully working bridge would be to get the written protocol specification from the hardware manufacturer. I haven't had much luck with that though, they never answer. When it is reasonably certain that it is a serial / COM port protocol, you can have my SerialScanner app. This is just tracking the data coming in from the device, and you will see realtively quickly if it makes any sense. Meaning for example if there is an acutal relation between a button press and the data that is going out from the device. There doesn't have to be, it could also use a constant stream of messages of varying contents. But at least figuring out the input protocol is technically possible. But IMHO it is absolutely impossible to figure out the outbound protocol (=how to light up LEDs or display something on the device's screen). There are no standards, so this is usually proprietary code - that you normally cannot observe. If you can get your hands on the specs, then it is worth a try. If not, I'd leave it be if I were you.

If this is a serial protocol, then reading data is not possible with the AAO app itself. The app is focused on the common protocols that "everybody" uses (game controllers, MIDI, CAN). It doesn't deal with specialized hardware at all - that is what the Web API was made for. Someone would have to write a Bridge program, like those on the AxisAndOhs website, that understands the RSG serial protocol and translates it for the AAO WebAPI.