Why does AAO lose its saved state....?

[flyforever 267]

 A suggestion: at times, when I open an assigned axis, I notice that the device has changed on its own and lists another device( an axis originally assigned to a throttle quadrant, now shows  rudder pedals as the device), without my having moved the physical lever at all. This is frustrating. I know I can "lock" the assignments, but the "lock" hardware locks all of them, so it makes it very difficult if not impossible to check one axis for accuracy, lock it, and then move to another axis. Lately, I keep loosing axis function, and have great trouble trying to troubleshoot.

Ideally, I should be able to assign an axis to a device and lock it permanently--unless I've physically removed the device from the USB port and plugged it into another.

[Lorby_SI 2,042]

26 minutes ago, flyforever said:

Ideally, I should be able to assign an axis to a device and lock it permanently-

Sorry, but I don't understand - what's the difference to the lock mechanism that is already there?? "Hardware->Lock assignment controls" prevents all accidental changes to existing assignments, be it by malfunctioning external controllers or by you when accidentally clicking or spinning the mouse wheel in the wrong place.

Locked is locked - isn't it? What difference does it make in your use case if one single item is locked or all of them? 

Edited February 7 by Lorby_SI

[Lorby_SI 2,042]

30 minutes ago, flyforever said:

when I open an assigned axis, I notice that the device has changed on its own and lists another device(

I don't think so. It changes right when you open the dialog, because without the lock in place, it immediately starts scanning. A controller moved by accident or a noisy potentiometer will then be registered as a new assignment.

Edited February 7 by Lorby_SI

[flyforever 267]

4 minutes ago, Lorby_SI said:

I don't think so. It changes right when you open the dialog, because without the lock in place, it immediately starts scanning. A controller moved by accident or a noisy potentiometer will then be registered as a new assignment.

Ok, let's assume that it's a noisy potentiometer. I can assure you that the noise as AAO displays is barely noticeable. It might make sense to have a filter for disregarding some pot noise.

[Lorby_SI 2,042]

The filter is already in place. You have to "isolate" a specific device with the little padlock  to put AAO in "high sensitivity" mode.

Why not use the locking mechanism mentioned above? It seems to work quite well for everyone?

Edited February 7 by Lorby_SI

[flyforever 267]

19 minutes ago, Lorby_SI said:

Sorry, but I don't understand - what's the difference to the lock mechanism that is already there?? "Hardware->Lock assignment controls" prevents all accidental changes to existing assignments, be it by malfunctioning external controllers or by you when accidentally clicking or spinning the mouse wheel in the wrong place.

Locked is locked - isn't it? What difference does it make in your use case if one single item is locked or all of them? 

I am not sure. The reason why I am bringing attention to this is that when a lever stops functioning in the sim, AAO appears to work normally. A good example is two throttle levers, both of which work fine. Some minutes later one of the two lever is no longer responsive. In AAO the lever appears to work normally.  Why would this happen?

[Lorby_SI 2,042]

Just now, flyforever said:

Why would this happen?

Sorry, no idea. 

I don't think that this has anything to do with the hardware assignment (otherwise it would stop moving in AAO too). That sounds more like a SimConnect problem ( wrong event or variable? One that this plane doesn't like?)

[flyforever 267]

Just now, Lorby_SI said:

The filter is already in place. You have to "isolate" a specific device with the little padlock  to put AAO in "high sensitivity" mode.

Why not use the locking mechanism mentioned above? It seems to work quite well for everyone?

I do use the high sensitivity mode as well as the locking mechanism. The fact is that recently I've been experiencing issues between AAO and the sim. At times, AAO recognizes all the axis, but nothing moves in the sim. At times, some axis in the sim stop working  while AAO shows them to be normal.

 

[flyforever 267]

1 minute ago, Lorby_SI said:

Sorry, no idea. 

I don't think that this has anything to do with the hardware assignment (otherwise it would stop moving in AAO too). That sounds more like a SimConnect problem ( wrong event or variable? One that this plane doesn't like?)

True, but if I assign an axis through the MSFS control option, I don't have this issue. Of course, I use AAO for its ease of use, especially when changing aircrafts. I am strictly referring to axis behavior. Buttons work fine--always.

[Lorby_SI 2,042]

Just now, flyforever said:

some axis in the sim stop working  while AAO shows them to be normal.

Other apps/addons interfering? FSUIPC, SPAD, Mobiflight, ...? 

Possibly a SimConnect flood? (then everything stops working, buttons too)

Not sure what to tell you, this hasn't been reported before. Check AAO error logs, click on the green LED to disconnect/reconnect?

[Lorby_SI 2,042]

3 minutes ago, flyforever said:

but if I assign an axis through the MSFS control option, I don't have this issue

AAO has nothing whatsoever to do with or in common with the MSFS controller assignment logic. That, and what can be done with SimConnect, are two entirely separate and unrelated modules or "logics". They cannot be compared.

Edited February 7 by Lorby_SI

[Lorby_SI 2,042]

7 minutes ago, flyforever said:

I use AAO for its ease of use,

So what exactly did you assign as throttles? MSFS prefers the Events, "THROTTLE1_AXIS_SET_EX1" etc.

Edited February 7 by Lorby_SI

[flyforever 267]

I'll do some checking. thanks.

[Lorby_SI 2,042]

3 minutes ago, flyforever said:

I'll do some checking. thanks.

MSFS generally prefers Axis Events over Variables. Use the second box from the top, the most common flight control events are right in the very first group.

[flyforever 267]

56 minutes ago, Lorby_SI said:

AAO has nothing whatsoever to do with or in common with the MSFS controller assignment logic. That, and what can be done with SimConnect, are two entirely separate and unrelated modules or "logics". They cannot be compared.

The AAO log does show  Access violation lines looking like:

2/7/2024 2:28:51 PM.227 : Exception received: 29 from send id 88 errloc 88
2/7/2024 2:30:14 PM.254 : SH: AccessViolationException in SimConnect