John Dowson

It doesn't make sense to allow this in FSUIPC due to the way calibration works in FSUIPC. FSUIPC calibrates to an FS control, and as there is no specific control/event when assigning to a preset, it does not know the range to calibrate to. Max/min/scaling etc can easily be handled, either in the RPN itself. or you can just write the axis value to an offset and do whatever you want with it before using it in a preset.

All I can see in those images is that one has an FPS of 127 and the other of 110. Isn't an FPS of 110 enough? The log file you attached is very strange, as it just shows FSUIPC connecting and disconnecting, It makes no sense to me, and you have not provided any context. What actually happened? What/why is FSUIPC closing shortly after being started: ?

The log file you attached was attached when FSUIPC was still running and also stops after 30 seconds. You are also using an old an unsupported version of FSUIPC. Only the latest version is supported - please update. And your ini file shows that you are not actually using FSUIPC for anything. You only have one (strange) button assignment, you have profiles but they are empty, and you [MacroFiles] section is very weird... Are you assigning in MobiFlight? i cannot support mobiflight - please use their support channels (discord) for issues with MF.

How have you assigned? There can be toggle controls, set controls that take a parameter (on/off) and separate on/off controls. So it depends on how you have assigned. You can also use offset conditions to check the state of a button before changing it, if require. Please show me / attach your ini file so that I can see your assignments.

You cannot calibrate when assigning to presets - this just doesn't make sense to allow this. No - it doesn't make any sense to allow this. There is no way that FSUIPC can calibrate values needed for a preset. No. Just use scaling.

Is there a simvar or lvar that holds the current state of this button? If so, log that... And also please at least activate logging for Events, and attach your log file here (as well as your ini) and I can take a look. Just defining a macro cannot affect the aircraft state on start-up. Something must be triggering this.

So its NOT an lvar. And it is not 'doing anything' as it doesn't exist. Juat because an lvar exists for the rudder trim and aileron trim, doesn't necessarily mean that one will exist for elevator trim. And if you list the lvars and its not there, it doesn't exist. If you are thinking that it should exists as there are similar ones for rudder and aileron trim, then you are mistaken and are wasting both your and my time on this. Use the facilities provided to determine what is available, don't guess.

Please: - turn off WAPI trace logging. Debug level logging is sufficient - also activate logging for Axes Controls and Extras - please also attach both your FSUIPC7.ini and myevents.txt files as well as a new FSUIPC7.log - please don't attach images unless requested. It is the files I need to see.

Almost all lvars are defined by the aircraft... Well, there are no lvars added to offsets by default. And as I have said many times now, listing the lvars in FSUIPC will list ALL lvars available fromthe last scan. You can even reload and list lvars, which will list ALL lvars defined and available. If that lvar isn't there' it is NOT an lvar, 'custom' (which means nothing) or otherwise. I don't understand why you think that is an lvar - why do you think that? How can you see it? How can you read/set/change it then?

But the macro does nothing unless you run it. So, if something is running the macro when you start FSUIPC or MobiFlight, then stop/disable that. A macro file does nothing by itself - something needs to trigger it to be ran. You can use FSUIPC's logging facilities to determine what,

Almost all lvars are defined by the aircraf... I still have no idea what you mean when you say 'custom'. As I said, if FSUIPC does not list it, it is NOT an lvar

I don't see how this can be the case. There is no such scaling. If assigning an axis to a preset, the axis value Out value should be used as the parameter, which should also match the In value. WAPI Debug level logging should show the values being used.

We seem to be going in circles here....I know that it isn't closing, and I need to see your file if you want my help looking into why... John

I am sorry but I don't understand this - how can running FSUIPC7 force spad.next to lose a connection? Yes - by not connecting FSUIPC7 to MSFS. Once it is connected, it is interacting... FSUIPC does not do anything with any devices/controllers unless you tell it to. Unregistered versions do not even scan for devices.

Then that must be the default value that it has when started. All aircraft switched/buttons/knobs will be in a pre-defined state on start-up, and this may not match the state/positions of your buttons/switches. The state of your physical buttons/switches are not read at start-up and the aircraft but in the same state - you have to start the aircraft with your buttons/switches in the correct position to match the state of the aircraft when started. You may be able to change the default state somehow but I don't know about this - you would have to ask on the aircraft support forums. Otherwise, you could just send the command to turn standby off when you start, for example by just running that macro, e.g. [Auto] 1=1SK CLOCHE:StbyInstrum

But an axis and an lvar are two completely different things. If you are assigning an axis to a preset, it is the axis value that is sent to the preset as the parameter. It is then up to you to calibrate/adjust that value in the preset RPN to whatever is needed. An lvar can accept a range of values, and every lvar is different. Some lvars only hold a 1 or 0, others can hold a range, and that may be from 0-100, -100 to +100, 0 to 1, etc. It is up to you to determine the range and scale the axis range accordingly. The range of values an axis sends depends on the axis. Standard joystick axis usually send values in the range -16384 - +16383, but some (especially those using potentiometers) can have a range of 0-1024 or -1024 to +1024. Calibration is used to calibrate the axis range to the range expected by the control being used. There are quite a few MF presets that calibrate to that range, and some for other ranges (0-1024 being another common range). You need to look at the preset code and description for such 'potentiometer' presets and update or change to your axes range. Because different hardware/drivers use different ranges for axes.

What do you mean by this? If an lvar isn't listed, it doesn't exist (or hasn't been 'discovered' yet in a scan).

Can you please show me / attach both your macro file and your FSUIPC6.ini file.

When FSUIPC7 is auto-started, 'Exit with FS' is always set and the options menu entry for this is removed.

Well then that needs to be looked into and fixed. Is the 'Exit with FS' active/checked? If so, and FSUIPC7 is not exiting cleanly when MSFS exits, can you please show the FSUIPC7.log file.

If you need to know/read the value of anything (lvar, input event, simvar) then add it to an FSUIPC offset, You can then use FSUIPCs offset controls to set the value, including increment and decrement controls. Are you sure thats an lvar? There is a simvar called ELEVATOR TRIM PCT, held in offset 0x0BC0. You can try assigning to the offset word inc/dec controls on that offset to control the trim. That is the normal method of getting a more responsive trim as you can specify the delta amount to your needs, or have a fast and slow assignments (i.e. different deltas) on different buttons (or virtual buttons). There are also other solutions for trim - e,g, see

FSUIPC knows nothing about MSFS assignments or settings, and I do not know if they apply when assigned using FSUIPC - you will just need to try it. You can/should first calibrate in FSUIPC if assigned there, and you can also apply sensitivity "slopes" there.

Having never tried MSFS (or even used) an xbox, I cannot really advise. These forums are for FSUIPC support, which only works with the PC version, so I doubt you will find many xbox users here either. I would presume all flight simmers, as opposed to gamers, would be using PCs. John

Yes - if assigning an axis or button/switch/key in fsuipc, you should remove any assignment to the same axis/button/switch/key in MSFS, otherwise both assignments will apply and cause issues/conflicts. If using fsuipc for all assignments, you can create a new/empty profile for your controller in msfs. Otherwise, you csn just remive any assignment in msfs once assigned in fsuipc.

Sorry but I cannot help you with issues with FSX - try avsim. John