John Dowson

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

This is already implemented and will be in the next release. This only affects the auto-start of the websocketserver, as it doesn't make sense starting it before FSUIPC has a connection, That would also be a good idea. Latest beta attached below - you shouldn't need the Init3308 init parameter with this. John FSUIPC7.exe

The FS version is not available until FSUIPC is connected to the FS. You can set the FSUIPC7 ini parameter init3308 to 13 (for MSFS2020) or 14 (MSFS2024) to prevent this. In the next FSUIPC7 release, I will also delay the starting of the websocketserver until FSUIPC7 is connected to the FS and the version known - see John

I gave details on how to add input events to offsets in a post earlier in this thread, with a link to an example... The "input events' you see in the MSFS behavior windows are B-vars, and are only accessible via calculator code, and only in MSFS2024 (i.e. you cannot use these in MSFS2020). As I said before, you should look at the Input Events available via FSUIPC, and use the input event logging facilities in FSUIPC to determine what input event controls a particular function. The B-vars and input events are basically the same, but you will find there are usually several b-vars associated to a given function (*_set, *_inc, *_dec, etc) but only one input event. So, for the taxi lights 3, there is the input event LIGHTING_TAXI_3 which you can either: - assign to directly to change the value and thus turn the lights on/off - add the input event to an FSUIPC offset, where you can read it, write write to it (to also trigger the input event value change), wait for an event, etc So, to read the value in lua or get an event when it changes, add it to a free/spare FSUIPC offset. And if it is in an offset, you can then set the offset to 1/0 to turn the lights on/off, using FSUIPC's offset controls, rather than using calculator code. Please re-read my earlier posts and take a look at the example i gave (to increment/decrement the value of an input event, which is slightly more complicated than just setting it). There are many FSUIPC offset areas designated as free for general use, see the Offset Status document and search for 'free' or 'general'. John

Sorry but no. If I did that, then I would get many support issues saying that they couldn't start FSUIPC as they double-click it and nothing happens, when it is already running and sitting in the system tray. There just has to be some feedback if/when you start something and nothing happens - surly you understand that? You should really look into the issue causing this - why is FSUIPC being started multiple times? John

That is normally the case, but as I had to fire-up the license generation machine I have also generated one for FSUIPC6, valid until 15th March. Just save the attached file to your FSUIPC6 installation folder. John FSUIPC6.key

No need to shout... Once a macro is created, you would assign to the macro as you would any FS control, as stated in the User guide (relevant part in bold): Is that not clear enough? Regards, John

Do you mean logging simconnect? What is confusing about those instructions? Please let me know and I will update... But you probably don't need to do this - it is a last resort. It can help with diagnosing simconnect connection issues as it shows all simconnect clients and how many connections they are using (as well as all SimConnect activity). And the log files can grow large very quickly. Ok, not problem - thanks for the update. If these issues return, check the FSUIPC log file and see if there are any connection issues and if so take appropriate action (whatever that may be!). Regards, John