John Dowson

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)

Did you select to auto-start during the installation process? If so, there may be an issue with your EXE.xml file. Please show me that + your InstallFSUIPC7.log file. Do you have a Steam or MS Store install? Sorry, noticed what in the toolbar? What was meant to auito-start? You should NOT manual enable WideServer, unless you have manually disabled It will automatically enable when it is time to do so. If you manually enable, it does not necessarily mean that WideClient can connect. Just try letting it enable itself. Yes, that sounds about right.

A new version has been released that contains: - a fix for the compound button issue mentioned above - a correction to an offset monitoring panel issue - a fix for a bug that prevented axes working when FSUIPC7 started when MSFS already running with a flight loaded I have also changed the version number for this release, and the beta release for 128 button support is now version 7.1.0a. Please see the announcement to download the latest version.

v6.0.14b has been released with - support for compound buttons - correction to offset monitoring issue

You can just re-install in the same folder (that will be the default), and then everything should work.

All looks good now. You can just delete that missing joystick in your ini.

👍🙂

Its an attached file. You should be able to download by just clicking, but if that doesn't work then right-click and select 'Save link as...'. If you still have issues, disable any antivirus software or add an exception.

Yes, I don't see why not. Depending on the app, but if it uses offsets then you can use the general control offset at 0x3110 with control number 68536. For the control numbers for each event, there should be an automatically generated document in your FSUIPC7 documentation called Controls List for MSFS Build 999.txt, which shows the control/event numbers, i.e. 68536 TOGGLE_AIRCRAFT_EXIT_FAST John

@jaxx Please try the attached version, although I haven't tested a plane switch. Its still v7.0.7 unfortunately, but with a build date of 19/03/2021, as I released the 128 button support update as v7.0.8a. I'll revise this tomorrow and release this as v7.0.8, and merge these changes into the 128 button support release and re-release that as 7.1.0a, but tomorrow or Sunday now. If you could test this before then, that would be good, Thanks, John FSUIPC7.exe

Please try with the latest version - Its still v7.0.7 unfortunately, but with a build date of 19/03/2021: FSUIPC7.exe I'll probably release this officially as 7.0.8 tomorrow...

Martin, events issued by MSFS are pretty mixed-up and difficult to use to determine that actual state, and this changes with each release. And FSUIPC7 has to try to determine the correct state in ALL situations, from having FSUIPC7 running before starting MSFS, having MSFS auto-start FSUIPC7, or starting FSUIPC7 when MSFS is already running, either in a menu, a flight, or in some other state. And when the WideServer component is started is also dependent on these things. So, if you have an issue, I need to : - know when and how you are starting FSUIPC7 - know the state of MSFS (in menu, flight, or elsewhere) when you try to connect - see your log files, especially your FSUIPC7.log file Also note that there is currently an issue with the latest 7.0.7 release where things are not being started correctly if FSUIPC7 is started when MSFS is already running and a flight is loaded. This probably also affects WideServer, although i haven't checked. So, please wait for further tests until i have released an update for this, either later this evening or more likely tomorrow now. If you are not using that version, then you should really update, but may as well wait now until I have released the update. John

Ok, thanks for the update.