John Dowson

You can reverse an axis in two ways, The first, an easiest way, is to do this in the calibration window. Note that if you have assigned your toe brake axis using 'Send direct to FSUIPC calibration' then you should always calibrate anyway. Please see the section on calibration in the FSUIPC User guide. The 2nd way to reverse an axis is to use FSUIPC's axis scaling facilities, This is described in the Advanced User guide, but you basically just add ,*-1 to the end of the axis assignment line (when FSUIPC4 not running) in your FSUIPC4.ini file. However, you should certainly do this via calibration when possible. You can also filter out spikes and add a calibration slope (to change the sensitivity of the axis around the centre and extremes) in the calibration tab. John

I cannot see how this topic is in any way related to the issue you are posting about - condition levers not working. There are various topics already posted on this issue - please see the following and if you still have questions then either post in this topic or start a new topic: This issue reported in this topic has been identified and now fixed in the latest FSUIPC release 7.3.13 which has now been released, so I am closing this topic now. John

A better place for this question would be the LINDA support forum. But LINDA is a graphical front-end to the Lua interface provided by FSUIPC, providing sets of aircraft-specific lua scripts for making assignments easier for a variety of hardware. FSUIPPC only recognises HID joystick type devices dor direct assignment (i.e. using the UI interface), but other HID type devices can be controlled using Lua. Usually we recommend first trying windows default drivers when using FSUIPC, but if may be possible to use the manufactures driver, if that enables the device to be correctly recognised by windows. However, I cannot advise for specific hardware that I dom'y know about - you just need to try with default windows drivers and with the manufacturers one to see which will work. That is the main purpose/reason for using LINDA (a UI on top of FSUIPC'c lua system), but I think it can also do a lot more these days. But again, more of a question for the LINDA forum. Not necessarily known as a joystick type device, but it must be at least seen as a HID device to be used using lua. You can use the HidScanner program (available in the Downloads -> Useful additional programs section of this forum) to determine if the device is recognised. Another question for the LINDA support forum, but I think the profile systems are distinct. So your profile would be loaded in FSUIPC, and the LINDA lua scripts associated to the loaded aircraft are available in LINDA. I don't know how LINDA maps the aircraft name to the scripts being used. Sorry I can't be of more help, but as your questions are mainly LINDA related, you may get a more helpful response on the LINDA support forum. John

That's good news, but lets wait and see until SU11 is released.

No problem. I don't think there is any reason that the Axis Steering Set control cannot also be calibrated, so I will look into allowing that in the next release. John

The steering calibration in FSUIPC uses the older Steering Set axis control, and not the Axis Steering Set one. Therefore to calibrate, you need to assign to Steering Set, and not Axis Steering Set. John

Please always attach the full FSUIPC6.ini file, not extracts. I will take a look and get back to you. In the mean-time, you can reverse the steering tiller axis by using FSUIPC's axis scaling functionality. To do this, change your teering tiller assignment line(s) in your FSUIPC6.ini file: to the following: i.e. add ,*-1 to the line which will scale the axis by multiplying by -1, i.e. it will be reversed. John

But that is in a loop. The lvar can be created after the loop starts, but the lvar will be read once it is available. With the event.lvar call, the lvar should be available when you call this (I think!), which is why I suggested adding that check. That is the offset monitoring. Try the debug /trace lua plugins to see what is happening. With the information you provided, I do not even know if that lua script is running (or what FS or version of FSUIPC you are using) If you want further assistance, please attach your lua file (not paste its contents), together with your FSUIPC ini and log files, the latter generated with logging for lua plugins enabled. John

This is the correct way to add an lvar to an offset in FSUIPC4,5 and 6 (in FSUIPC7 there is an easier way). If that isn't working, I expect this is because the lvar doesn't exist when you are calling the event.Lvar function - you can test for this using the ipc.getLvarId function, e.g. function fdcmdrvalue (LvarName, LvarValue, userParam) ipc.writeSW(0x66F0, LvarValue) end id = ipc.getLvarId("CpitCmdrSetValue") if id == nil then ipc.log("Lvar CpitCmdrSetValue doesn't exist!") else event.Lvar("CpitCmdrSetValue", 100, "fdcmdrvalue") end Also, please try using the lua debugging facilities (using Debug/Trace Lua plugins from the Logging tab with Send to console window checked) to see what is occurring in your lua scripts. You can also take a look at your FSUIPC log file if the console window output scrolls too fast for you to read. John

The change in SU10 that caused this issue has been identified - it is due to a change made in the way a simconect function is used (RemoveClientEvent - see here for details). This should (hopefully) be corrected in a future update, but in the meantime I have added a fix so that previously functionality can be restored, and you can now calibrate again in FSUIPC7 when assigned to 'Send to FS as normal axis' or assigned in the sim. This is available in the attached beta 7.3.13a: FSUIPC7.exe John

All information on FSUIPC7 auto-start is in that FAQ entry - I have nothing more to add or say on this issue. Please read that thoroughly (there is an alternative method you can try..) - as it says in the README.txt: Sorry but I have responded to this same issue so many times now - this is why that FAQ entry exists; John

The desktop icon that is optionally added by the FSUIPC7 installer does not start FSUIPC7 - that icon simply starts MSFS and shows a splash screen for 25-30 seconds while MSFS is loading. It is MSFS that starts FSUIPC7 via the EXE.xml file. There is no AutoStart ini parameter. Please see the following FAQ entry that details how auto-start works and what to check to fix any issues: John

Thank you - but it is now John not Pete - Pete retired a few years ago. No, there are no mouse macros in FSUIPC7 / MSFS. Many aircraft in MSFS make extensive use of Lvars, and there are also new variable types that you can investigate - mainly hvars, which are HTML variables which are used to acrivate UI components. However, the easiest way to use lvars and hvars (as well as other variable types, such as z cars) is to use calculator code, and the easiest way to use calculator code is to use the provided presets, available in the control assignment dialog boxes by selecting the checkbox Select for Preset. The presets provided are from the Hub Hop resource which is a community driven effort led by MobiFlight - see https://hubhop.mobiflight.com/presets/. Also see the Advanced User guide on how to use lvars/hvars/presets in FSUIPC7, in the WASM section. Looking at the preset list, the following look applicable for replacements to APU_BLEED_AIR_SOURCE_TOGGLE and APU_BLEED_AIR_SOURCE_SET for the FBW A320: A32NX_APU_BLEED_OFF_OFF A32NX_APU_BLEED_ON_ON and maybe: A32NX_OH_APU_BLEED_TOG There are many other bleed controls - please take a look at the MF Hub Hob site. It has a good search interface and you should be able to locate the presets needed for the items you need, and the presets you see there should be available for assignment in FSUIPC7. John

No - the PMGD offsets are just populated by the (client) data received from the aircraft - nothing is changed. John

There is no problem installing FSUIPC4 on multiple computers. If the registration validation is failing - and you have already registered with the same details, then you must be entering them incorrectly. Note that all 3 components must match - your email address, name and key. You can also just copy your FSUIPC4.key file across from your original installation to the laptop and use that. One other possible cause could be out-dated VC++ redistributables. You can check what VC++ redistributables are installed and maybe download and install the latest combined package from https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170 - make sure you uninstall any of the 2015, 2017, 2019 and 2022 ones already installed before installing this combined package. If your issue persists, please let me know your FSUIPC4 order number and I will check your details here - but if they have previously validated ok, there really shouldn't be an issue. John

I have no idea - I just add this data as provided by the PMDG 737 SDK. This is therefore a question for PMDG - try their support. John

Ok, thanks for the update. John

What do you mean by 'disappears'? Do you see the FSUIPC7 splash screen? Is an FSUIPC7.log file generated - if so, please show it to me. Otherwise, please update your VC++ redistributables to the latest combined package and try again - uninstall any of the individual packages already installed. Instructions and a link to the VC++ redistributable download page can be found in the README.txt file. John

Yes, you can do that, and many people do use this method to reduce sensitivity. However, you will lose the full range of the axis. John

So you cannot read 32-bit floats or 64-bit double floats from C-Pascal? I find that quite strange... I cannot possibly allocated fixed offsets for this when they will only be used for a specific aircraft and dor such a small subset of users. But, as I said, there are mechanisms provided for the user to do this - if its a standard simvar that is held in the offset, you can dd the same simvar as a different type, i.e. as an integer, using the mechanism provided and documented in the Advanced User guide (page 34). If its a PMDG offset, then you would need a lua script (registered version of FSUIPC only) to monito that offset and pick up any changes (using the event.offset function, as already suggested) amd convertt the value to the required type and then write that value back to an offset free for general use. I can help with both of these, but you should try to do this yourself first. Note that I am away this weekend (the wife's birthday), and so will be unavailable from a few hours time until Monday morning, so I can help further then if you are having issues. John

I am trying to help, and would help further if you had a better attitude. John

Have you looked into using the custom controls? See There are also presets available for these, e.g. for the strobes you can use PMDG_B737-7_LIGHTS_POSITION_STROBE, and for the master battery the following are available (see https://hubhop.mobiflight.com/presets/😞 Note you can assign to MF presets (as well as your own user-defined presets) by checking the checkbox 'Select for Preset' rather then 'Select for FS control'. Note also the PMDG custom controls (not Rotor Brake controls) only work with the latest version of FSUIPC7 - 7.3.12, released yesterday. However, I believe nost of the PMDG presets are using the Rotor Brake control, so they should work in earlier versions. John John

FSUIPC cannot possibly cause any of the symptoms you describe. If you did no install the WASM or the auto-start component, then FSUIPC7 as no affect in MSFS at all until you run it - i.e. it makes no changes to anything in your MSFS installation. Installing the auto-start component only modifies one additional file (EXE.xml) in an MSFS folder, and installing the WASM only installs that into your MSFS Community folder. Nothing is changed in MSFS itself Uninstalling FSUIPC7 will leave MSFS in exactly the same state as it was before you installed FSUIPC7. I therefore cannot see how FSUIPC7 has anything to do with any of your issues, sorry. John

You can also use a lua script, using event.offset, to get the existing offset value whenever it is updated, convert it to whatever you like and then write the new value to a free user offset.... John

You can try adding the same simvar (ELECTRICAL BATTERY VOLTAGE) to a free user offset as another type that can be read/converted using SC-Pascal. I am not 100% sure on this (and won't have time to look into this until next week), but you could try adding this as a a 32-bit float (F32) or as an integer (I32) if they can be read in SC-Pascal. I think the original 64-bit double value would then be converted or cast to the defined type. See page 34 on how to add simvars to FSUIPC offsets. Any issues let me know, and I will take a deeper look next week. John