John Dowson

It probably has a button number > 31. You don't say which version of FSUIPC you are using, but if its FSUIPC6 or FSUIPC7, I have just released a beta version with support for up to 128 buttons: please see Otherwise, you would need to use a lua script to map those buttons to virtual buttons. You can use the example HiDDemo.lua provided for this, or, probably better, adapt one of the Aha or Bravo lua scripts for your device (by changing the Vendor and Producr ids), which are available from the User Contributions section.

It won't - I just mentioned this as it is a general control to insert a pause, but it will not 'break' or prevent further assignments being executed. Sorry if that confused you.

You can assign an axis to these controls using 'Send to FS as normal axis'. If you do this, also check and remove any calibration as well. Yes, its a know issue with some add-ons. For throttle configuration in the CRJ with FSUIPC, please see this post:

Sending direct to FSUIPC calibration and calibrating can cause issues with some complex add-ons due to the priority levels of the axis controls seen by the sim. Try 'Send to FS as normal Axis' instead and remove any calibration.

You need to add the MF events to FSUIPC using event files (*.evt). Please see these threads:

As well as what Pete has said, there is a 'Pause Control' that you can use to insert a break in multiple assignments or macros (but not in compound assignments) Its FSUIPC added control 'Pause (ms)', number 1152:

The FS doesn't need to be he active window to receive button presses, although it needs to be the active window to receive key presses. Are you sure you had something assigned to the button press? You can always activate logging for Events and Buttons & Keys yo see what events, if any, are being sent when you press a button or key.

I've far too much to do and no time to start looking at c#. I can rebuild the API as a dll at some point though, and export the public functions of the WASMIF class. Not sure when I'll get time for this at the moment, but I'll let you know when its done.

Sorry, what do you mean? There is no 7.1.0, only 7.1.0a. Are you sure it was FSUIPC7 that crashed, and not MSFS. Do you have an FSUIPC7.log file for the crash, and a windows event? No it doesn't! If it says that, that is the version you are running.... I don't know what you are doing, but sounds like you did not install the v7.1.0a version correctly. You should use the downloaded FSUIPC7.exe to replace your previous FSUIPC7.exe (or just rename the existing one first). I think you should re-install the full version again (v7.0.8), then re-download the 7.1.0a version and use that to replace the installed FSUIPC7.exe. If you then have any issues, show me your install log as well as your EXE.xml file. You can do this by not selecting to 'Auto-Connect to FS'. But then you need to manually connect. If that is a feature request, I can put it on the list and look into it at some point. However, there is a lot to do at the moment and I it will be a long time (> 1 year) before I will get a chance to look into this. I thought the recommended way to start Linda was via lua and ipcReady.... However, it should start with a run command if you want to do it that way. But there is no point in just telling me these things, I need to see your logsd and ini files if you want me to look into anything. Sorry, what does this mean? The [LuaFiles] section is auto-generated by FSUIPC and just lists the lua files found in your installation folder, for assignment purposes. I'm not sure what you are asking, but if it is related to Linda then you should ask on the Linda support forums. I don't use Linda. John

Presume you mean 66748 to 66800.... There have been many reports on many of these events not working (both in the FSUIPC as well as the Asobo forums). However, there are MobiFlght events for the G1000 which are working, so you should try with them (you will need to install the MF WASM module - there are various posts on this here, on Asobo forums and on MF).

No, that won't be an issue. If a button isn't assign, it just means that FSUIPC will not do anything when you press the button (except maybe log). That shouldn't be happening. Can you explain what you were doing when this occurred? You could activate logging for axis events, and the next timne it happens, show me your FSUIPC log fie, as well as your ini. Note also that your FSUIPC version is out of dat - the latest version is 6.0.13, so please update. There is also a beta version available, v6.0.14, which has support for yp to 128 buttons, and as the bravo has button numbers > 31 you may want to try this version that should allow you to assign all the butons. Its avaiilable here:

Yes, looks like your GUIDs have changed at some point. You can remove the following entries: Leaving just the following for your [JoyNames] section: You will also need to check for references for those devices in your profile files and update. Change the following joy letter references (in the [axis] and [buttons] sections: B -> G (or H( C -> H (or G) K -> E L -> J M -> D P -> G or G (?)

Yes - update to the latest version, v7.0.8. There was an issue closing luas that used the com library that is fixed in this version. J0hn

I don't know - did you try calibrating? You can still calibrate if sending to the FS as normal axis, but that may have issues with priorities, but that only usually affects detailed add-on aircraft that implement their own subsystems. You can try it, but really assigning direct to FSUIPC calibration (and calibrating) is the way we recommend and should be tried first. Why do you not want ti use this? This can be done via calibration, not programming. You need to assign and calibrate in a manner that works for the loaded aircraft. Also, if its aircraft specific, berrer to assign and calibrate in a profile. J0hn

Sorry, I can't at the moment. There are more important things I need to work on for the majority of FSUIPC users, such as access for up to 128 buttons (just released as a beta) amd lvar/hvar access, now part done (WASM module + API client). Once thats done/completed, I am planning to make a survey (SurveyMonkey) for the remaining features that need to be implemented, and I will let you users decide on the priority. John

This is a know issue with Xbox one and xbox 360 controllers. From the included README.txt: This is because those controllers are not native DirectInput, but XInput devices. I will be looking at this at some point, but I'm afraid its low priority so won't be available for quite a while. For the time being, its best to assign ion MSFS (or use the default MSFS profile) for those controllers. John P.S. And the title of this post is very misleading. I will update, but please give your posts a relevant title.

Ok, thanks - I'll update the spread-sheet with this info. But, as I said in another post, please update to 7.0.8! Ok, I'll check this. But the documents really need to be used together. At some point, I will revise and merge into one document....when I get time....! Ok. Not sure of the update frequency on that offset. If its an issue, I can maybe increase the frequency, but if its not an issue (as its not something that needs to be immediate really....) probably best to leave it as-is.

Yes, most probably. However, they are not documents but config files for extra utilities: This is a config file for the FSInterrogate2std.exe program This is the config file for the WebSocketServer. Not sure why they were skipped though. I've attached them if you want to drop them into the correct place (the FSUIPC7/Utils folder): FSUIPC.FSI FSUIPCWebSocketServer.exe.config There is also a minor error in that a link wasn't created in your FSUIPC7 folder to your FSUIPC7 documents folder: But this really isn't important, especially if you know where your FSUIPC7 documents are installed. John

Ok, but there are a few issues in the 7.0.7 release. I have corrected these and released 7.0.8 this morning. Please update. John Oh - and thanks for reporting back!

Ok, but its very strange that this only happened with 2 documents and the remaining were installed ok. I can only think that it must be to do with permissions if the docs weren't open. Yout install log may reveal something. Ok, I'm happy about that!

Ok, although that's rather strange. Could the documents have been open? This would have prevented them from being uninstalled and re-installed. But glad its all working for you now. John

Yes, this should be possible if its sending the keypress to FSUIPC as a windows event to the class name - it shouldn't need the focus. Sorry, but I don't think there is anything I can do about this in FSUIPC. Maybe try AHK support to see if they can do anything for you.

I'll take a look and follow up when I get a chance. Thanks for letting me know, John

Usually you would send key presses to the windows class name, not the pid, but thats another matter - maybe AHK gets the class name from the pid and uses that. FSUIPC7 also picks up key presses from the FS when that has the focus, via SimConnect, so you could try sending the keypresses to MSFS instead. However, this may nor work if using modifier keys, as although FSUIPC7 detects most (but not all) key presses via simconnect, it will scan the keyboard to detect any modifiers (shift, ctrl, alt) when it receives the main key press/release.

No point attaching an install log if you didn't use the installer. I released v7.0.8 this morning, Please download that and run the installer to reinstall. Then, if you have issues with either: - the installer crashing after installing the exe is installed or doesn't exit cleanly - FSUIPC7 not starting with MSFS then show me your InstallFSUIPC7.log together with your EXE.xml, which should be located under: <USER>\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt (the actual location will be shown in your install log file)