John Dowson

The format if the .FLT file is defined by MSFS/Asobo and cannot be changed. All FSUIPC can do is use the facilities provided by the SDK, which only allows flight files to be saved and loaded. What is actually saved and loaded is up to the SDK. Any request for changes in what is saved (and loaded) should be addressed to Asobo/MSFS. There is also no access to the weather engine from the SDK. John

You can use presets by writing to offset to the generic control offset at 0x3110, but you need to determine the control number if the preset. You can also use offset 0x7C50 where you can write the preset name directly (preceded by 'P:') - see the offset status document for details) I presume you can write to any offset using the websocket server, and I am not sure if there is a higher level API available, but@Paul Henty should be able to confirm. John

You can do this but if FSUIPC is running it could re-write the ini with them back in. If FSUIPC is running, make sure the axis assignment window is open BEFORE you edit the ini. And once you have edited and saved the ini, click the reload button to reload your changes. Also, don't forget to remove the calibration assignments. John

Your devices on your old system: A=GF-TQ6 Throttle System B=3 axis 0 button device [used as rudder] C=3 axis 16 button joystick [used as yoke] The FSUIPC6.ini for the new system contains two [JoyNames] sections. Please remove this one: Your other [JoyNames] section shows that you have 3 devices: A=PFC Yoke B=GF-TQ6 Throttle System C=PFC MFD Rudder Pedals These are very different from the devices on your old PC. You shouldn't really copy settings between controllers - always better to set them up afresh. However, you could try.. But first, are the PFC standard HID devices? i.e. does FSUIPC see them as normal devices, or do you need to use one of the additional PFC drivers (e.g. PFCcom64.dll)? If they are standard HID devices (i.e. no PFC dll needed), then you could switch the letters around to match your previous letters, so (after removing that other [JoyNames] section), change to i.e. change your yoke to be C, your throttle to A, and your rudder to B, as they previously were. John

The installer will (or should) still create an add-on.xml file under your Documents\Prepar3D v5 Add-ons folder (under an FSUIPC6 folder). The actual FSUIPC6 installation folder should reside elsewhere, and not under a windows-protected folder. Try installing under C:\FSUIPC6 or C:\Prepar3D v5 Add-ons\FSUIPC6. Windows updates can affect the behaviour of these folders, especially with the use of cloud back-up services, such as OneDrive, which microsoft seem to be pushing quite aggresively. As I have said, the latest version is 6.1.8, and ONLY the latest version is supported. Please download and install the latest version in a non-windows protected folder. If you have any issues after doing this, please attach your InstallFSUIPC6.log file. John

I don't know but you should not install FSUIPC under your Documents folder. Please select a folder not under a windows protected folder. Only the latest version of FSUIPC6 is supported, which is v6.1.8. Please update. Any further issues with installation, please attach your InstallFSUIPC6.log file. John

It is - in the FSUIPC7 installer. This is the message I see (in the FSUIPC7.log): 152703 [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.7 (WASM version 0.5.8) Or are you installing the WASM from another package? If so, where - the one under the SDK folder or downloaded from www.fsuipc.com? I think I also update those but will check... John

That is certainly possible, if using the same controllers/ Why not just copy/use the same ini file? Your device GUIDS will have changed, and also your ids, but this is easy to correct by manually changing the GUIDs in the ini to match. This will be due to the change in GUIDs/IDs of your controllers. Please attach both you original and new FSUIPC7.ini files, together with an FSUIPC7.log file from your new PC and I will take a look. John

Hi Al, previously there was a 32 button limit (buttons 0-31) for direct assignments, with buttons outside this range needing a lua script to trigger virtual button flags. However, since release v7.1.0 (released about a year ago) up to 128 buttons are supported natively. As button numbers 32-39 are reserved for POV buttons, standard buttons with numbers > 31 will be numbered from 132 onwards (i.e. add 100). This is documented in the User Manual, P22: John

But this is not correct and would mess up many peoples system (including mine!). You only need to uninstall any of the 2015, 2017, 2019 or 2022 versions that are installed. I also have versioned installed going back to 2010. And it is not Microsoft Visual C++ you should uninstall, but the Visual C++ redistributable packages. They are different. These links change as the combined package is updated. However, the link to thee page with the latest updates doesn't, which is why I use that one instead, and just give instructions to install the latest combined packages for both x64 and x86.

No. Presets are names associated to a string of calculator code which is executed by the FS ('calculator code' is a scripting language used by XML gauges), and you can use/activate hvars in calculator code, as well as set lvars, read lvars, send events, perform logical operations, etc. John

The problem with adding another CDA for lvar names is that I would also need to add another CDA for the values, as the current 2044 restriction is actually on the value CDAs. I can increase at some point, but would rather not unless essential. I don't think memory is much of an issue these days, as each CDA is only 2k. Presets are only for actions and cannot be used to get values - they would need to be known to FSUIPC for this (e.g. to add to an offset). John

The link (https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170) has this: and the instructions say to download and install the x86 and x64 versions of this latest combined redistributable package. I don't see how I can make this any clearer, and do not understand why I keep getting support questions on this subject. I ask what is not clear so that I can update on user feedback to prevent further support requests... John

Then you misread the instructions.: i.e. it is the combined redistributable package that you need to install. Why is it not clear? Just follow the provided instructions, i.e. - uninstall any of the 2015, 2017, 2019 or 2022 VC++ redistributable packages that you currently have installed - download and install the cumalative combined package for 2015, 2017, 2019 and 2022 using the link provided (in the README.txt file) I'm sorry, but I do not see what is not clear about this in the current instructions: John

There is no need to use hvar files any more as you can activate all hvars using presets, either the provided MF presets or you can add your own. Please see the MobiFlight HubHop resource for a list of available presets (see https://hubhop.mobiflight.com/) - search for presets containing AS530 for the G530 presets. FSUIPC7 will only detect USB joystick type devices. If your USB card is not if that type, FSUIPC7 will not recognise the buttons/switches natively (i.e. in the assignments panels). However, you may be able to use lua as this can detect non-joystick type HID devices - see the provided HidDemo.lua. Alternatively, you could try using MobiFlight (with FSUIPC). John

Ok, thanks for the update. I have no idea what previously prevented FSUIPC7 from starting. Very strange! John

Done.

Where do you see these instructions? All you need to do for MSFS is run MakeRunways with Administrator privileges. This is correct as that file has nothing to do with MakeRunways. See the 'LIST OF FILES PRODUCED' in the MakeRwys README.pdf. John

There are no throttle controls logged in the attached log - its mainly left/right brake and prop pitch1 (ex1). I see you are also using the Just Flight 146. This may not be using the standard throttle controls? If its using the Ex1 throttle controls, you can assign to these by selecting 'Send to FS as normal axis', Try moving the throttle in the UI to see what throttle controls it is using (i.e. what control is logged) and switch to using those - you should do this in a specific profile for that aircraft. The assignments and calibration look ok. If you want check these, try switching to another aircraft first and test them with one that definitely uses these throttle controls, such as the Baron G58. John

I cannot tell what is happening from those screenshots... Could you show me (attach) your FSUIPC7.ini and FSUIPC7.log files. For the log, please enable logging for axis controls, load your aircraft and move your throttle axis/axes through their full range (forward then back) and then exit (do not start a new log file!). If the log file is too large to attach, you can zip/compress it. John

I will update tomorrow (or maybe Tuesday)...

It should be "L:EmbApFlchClick" and not "L=EmbApFlchClick" - i.e. a colon after the L. You can use any offset that is free for general use - that is the whole point of them... What is this section in your FSUIPC6.ini for: There is no such section in FSUIPC6 (and the format is wrong for FSUIPC7). Please remove that. Your version of FSUIPC6 is also out-of-date - you are still using 6.0.9 and the latest version is 6.1.8 - please update as only the latest version is supported. John

This should be set as default. No. All folders/files are created by FSUIPC, you do not need to create anything. And profiles in separate files are only used when you set UseProfiles=Files Please see the document Profiles in Separate Files.pdf. Each profile will have an entry [Profile.xxx] where xxx is the name of the profile. Again, you do not create this - FSUIPC creates this for you when you create a new profile. In this section are the aircraft names that use the profile. You can have many aircraft using the same profile (and you should name your profile accordingly, e.g. TwinProp), but many aircraft (more so in MSFS than in previous FSs) will require their own profile, especially if using lvarsm hvars or presets/calculator code. Yes - this is also added automatically when you create the profile or add an aircraft to an existing profile. No - when you create a profile (or add an aircraft to a profile) the full aircraft title will be used. To match other liveries, you should edit the aircraft title (in this line in the FSUIPC ini file) to be a substring match to the title of the aircraft so that it matches different liveries. Otherwise you would have to add the aircraft again when using a new livery as the title would not match. There is also a new ini parameter called UseAirLocForProfiles which, when set, will use the folder name of the aircraft.cfg file for matching aircraft to profiles, which should catch most (if not all) aircraft when using different liveries. Please see the section on profiles in the User Guide, as well as the Advanced User guide for a description of the UseAirLocForProfiles parameter. John

Yes, this is what you reported. I was just suggesting to try 6.1.8 again to confirm. The problem only seems to occur in the latest ProSim beta as well, which also indicates its not an FSUIPC issue. Anyway, talked to Pete about this - he is aware of this issue and will check later next week.

I'm not sure about that - there are very few changes between 6.1.7 and 6.1.8 - only the following: - Bug fixed that prevented assignments to buttons with numbers 64 – 95 from being triggered - New functionality to allow the user to add any simvar to a free FSUIPC offset Looking at that link, this was your issue: I'm not sure how this can have anything to do with FSUIPC... Can you try 6.1.8 again to confirm please. As I don't have/use Prosim, I'm not sure what I can do. I'll see if @Pete Dowson can check this as he uses the ProSim 737 (probably later next week, after the Bank Holiday). John