John Dowson

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

Not for me - there is nothing I can do about this - it is (obviously?) an MSFS issue, and nothing to do with FSUIPC. I really don't understand how add-ons in the Community folder can affect the functionality provided by the EXE.xml file. I suggest you raise a bug with MSFS/Asobo and report your findings there, as it is they who need to look into this. Cheers, John

I have nothing more to say on this matter that hasn't been said already. If auto-start via the EXE.xml isn't working, just use the MSFS.bat method to start FSUIPC7 or start it manually.

So try 0x6B (or 107) for +, and 0x6D (or 109) for -. John

No sorry, I was mistaken in this. I added support to send left/right ctrl & shift, but not for assignments. This was implemented to support assigning button/switch assignments to key presses assigned in MSFS (as some controls only work in MSFS, such as camera controls). It will be very difficult to add support for left/right shift/ctrl/alt as currently I only allow 1 byte (8 bits) to handle the modifier key, and 7 bits are already taken/used - from the User manual: So you can only have a maximum of 1024 key assignments. There are around 80 (rough guess) non-modifier key codes, so with the 6 (or maybe 5) modifiers currently provided, that allows for around 480/400 distinct assignments. Do you really need more than this? Another issue with switching to left/right modifiers would be in handling existing assignments, which I would need to think about... So, all-in-all, I don't think this is going to happen, at least any time soon. It will be a lot of work for little benefit, as far as I can see. There is a lot more additional functionality that would be more useful for most folks, so I won't be considering this for the time being. Sorry about that. Regards, John

I do not understand the term sketch in your question, but please read the document FSUIPC Lua Plug-Ins.pdf (which will be in your FSUIPC documents folder, under your Windows Documents folder). Extensive documentation is provided so that I don't spend all day responding to such questions - please check the documentation (and existing support requests - most questions have been asked before...) before requesting support. John