John Dowson

Those files you posted are useless to me as they are from an unregistered version. You need to copy the FSUIPC7.exe downloaded to your FSUIPC7 installation folder, replacing the existing one (and where your FSUIPC7.key file is located), and run it from there. So you won't be assigning these via FSUIPC then? If not, you should be ok with the latest version i posted. However, I would still like to understand why the FSUIPC7 can't get the Fanetic device name, so please post those files again when you have ran it correctly. John

I haven't checked this since the last time over a year ago (October 2020). I will take another look when time permits, although there isn't much I can do if the data returned from the SimConnect_RequestFacilitiesList call doesn't actually contain the closest airports, which was previously the case. It is FSUIPC that determines which are the 6 closest from the complete list received. If the closest airports aren't being returned, I don't think there is much else that can be done in FSUIPC. John

Except that you can't start MSFS from FSUIPC7....! The provided desktop link (which calls the MSFS.bat file) simply displays a splash screen and then starts MSFS. It is MSFS that then starts FSUIPC7, if you have installed the auto-start component. The only other difference from using the FSUIPC-provided MSFS desktop icon to start MSFS is that if it is an MS Store installed version, it will be started with the FastLaunch option - for Steam installs, you have to configure this in the Steam client. John

Do you mean the splash screen? That should appear for a dew seconds and then disappear. FSUIPC7 always starts iconised to your system tray. No idea, but I doubt very much this is related to FSUIPC7. When it starts, it does not even connect to MSFS until a minute or two later (when MSFS is ready). I have no idea what your issue is... are you sure that it is just not taking time to load? Takes a few minutes here, depending upon what is in your Community folder, and what the current/previous aircraft loaded is/was. You can verify that this has nothing to do with FSUIPC7 by just temporarily renaming the FSUIPC7.exe (e.g. FSUIPC7.exe.unused). You will get a dialog saying that FSUIPC7 cannot be found/started, but the loading process will continue. For any issues with MSFS, you should use the Asobo forums. John

This is normal. When MSFS crashes, this causes a fault (but not fatal) in FSIOPC as the connection to the simulator is lost. FSUIPC will detect this and then close down gracefully, as indicated by your log: It is MSFS. FSUIPC7 is a separate executable and in no way should it cause MSFS to crash. Try checking the Asobo / MSFS forums for any possible causes (there are many!), and report your issue to Asobo if you cannot find anything that looks relevant to your situation. John

There is a version available, v7/2/16c, including an updated WASM, that has a 1k limit for the calculator code if you would like to try it. It can be found here: http://www.fsuipc.com/download/Install_FSUIPC7v7.2.16c.zip John

Did you get any further with your issue? I just updated my original SPAD to the 64-bit version from that post you kindly shared, and when I run this version the gear lever works without issues in the JF arrow with the default profile, no configuration needed at all. I really don't understand why this is not working for you. John

What is that file? Never heard of it... To use hvars, you have to make them known to FSUIPC7 by adding a *.hvar file, where the name of the file is a substring match to the aircraft name. The file MUST be in one of two locations. Please see the Advanced User guide for details. Also note that I haver no idea what hvars are available for any particular aircraft. It is up to you to discover these. I have provided some *.hvar files (in the HvarFiles sub-folder). To use any of these, they must be copied (and renamed to match the aircraft that you want to use them for) to one of the two locations where hvar files are active. John

This issue could be caused by the OEMName string being returned in unicode format, although I don't understand how this can be. Could you please try the attached version, where I have changed to explicitly call the ansi version. Please keep the current log settings active - again, just run this (without MSFS) and show me the log file produced. Also, please let me know what devices/controllers you are actually using. I do not understand the different devices you previously had in the FSUIPC7.ini file you posted. Please also attached the latest version of that file, and also the latest FSUIPC7.JoyScan.csv file. John FSUIPC7.exe

Hi Detlef, Thanks. FSUIPC4, 5 and 6 use a similar windows hook to get the keyboard input, but as an embedded dll it only gets the input when the FS has the focus. As I previously said, I do not like the idea of grabbing all keyboard input regardless of focus, as this would cause issue for mot (i.e. the majority) of FSUIPC users. However, this does seems to be an issue when using additional 'keyboard type' devices. But, the issue with these is that they are not recognised by MSFS, and so the keyboard input is not forwarded to FSUIPC7 via SimConnect input events. I can look into adding a global hook for keyboard input. If I do this, it will be activated on a new ini parameter (i.e. not active by default), and if/when activated, I will disable the keyboard input from SimConnect (to prevent multiple inputs). However, as I am very busy on other things at the moment, I am not sure when I will have time to look into this fully - maybe in 2-3 months or so, but earlier if I get a chance... Thanks for the kind offer, but this shouldn't be necessary. I should be able to implement and test sufficiently using a standard keyboard (or two!). I can also post here for you to try once implemented. Thanks and regards, John

They are just the index numbers for those items, All section item that are not parameters (i.e. parameter=value) will have an automatically assigned index number that increment by 1 each time. You have "2" and "6" as assignment lines 1, 3, 4 & 5 have been removed. Please see the Advanced User guide for a description on the format of the various ini file sections. John

Yes, this is a known issue with MSFA and has been present since launch. It is even worse that what you describe - If you load the Aerosoft CRJ directly without even loading the FBW A320, you will still see the FBW A320 lvars by just having that aircraft in your Community folder. This is why many folks clear there Community folder to just include the add0ins they are going to use for the current flight, and restart MSFS in between flights, changing the contents of the add-ons folder as needed. Many people use the MSFS add-on manager to help with this. Current maximum is 2044 lvars. Your file only contains 1547 so you are no where near the maximum. If all lvars are not loaded, give it more time before the lvar scan is performed (see LvarScanDelay WASM ini parameter, as I gave already mentioned) or perform a WASM-> Reload. Yes, known issue since inception. Nothing to be done, except restart and start with a 'clean' Community folder if this bothers you. There is nothing I can do about this as far as I am aware. The FSUIPC WASM just iterates the known lvars for the currently loaded aircraft, and this is what is returned. John

That is because you are running the FSUIPC7.exe - this has never started MSFS. That is what the desktop icon (or MSFS.bat file does). Well, as I said the issue is that windows is returning a zero length for the OEMname string. No idea why this is, I will look into it. I am also not sure what devices you have, and if your 'FANATEC ClubSport Pedals V3' will be assignable, as there is no name given. These are the devices FSUIPC now finds: 156 Joy#0: Name = T-Rudder 156 Joy#0: GUID = {AF2EFD80-7E83-11EB-8002-444553540000} 156 Joy#1: Name = Joystick - HOTAS Warthog 156 Joy#1: GUID = {1EC0C490-8054-11EB-8004-444553540000} 156 Joy#2: Name = Throttle - HOTAS Warthog 156 Joy#2: GUID = {1156C700-8054-11EB-8003-444553540000} 156 Joy#3: Name = 156 Joy#3: GUID = {02624230-0D88-11EC-8001-444553540000} Notice the empty name for your device #3 (FANATEC ClubSport Pedals V3). However, the FSUIPC7.ini you posted has a completely different set of devices: 0=JAY Rudder 0.GUID={04256470-BFB4-11EB-8006-444553540000} 1=Redbird Alloy YK1 1.GUID={0425D9A0-BFB4-11EB-800D-444553540000} 2=PFC Throttle Quadrant Console 2.GUID={042600B0-BFB4-11EB-8011-444553540000} I really don't understand this...what devices do you actually have? Do you have two rudders - the T-Rudder and the FANATEC ClubSport Pedals V3?

Ok, that is interesting.... The call to get the OEMnamr string is returning a length of 0 for the name 'FANATEC ClubSport Pedals V3' for some reason, and this is later causing an crash to an array being accessed out of bounds. i am not sure yet why that windows call is returning a success code but an invalid length, I will look into this. In the mean-time, I have corrected the out-of-bounds error that this provokes. Could you try the attached please. John FSUIPC7.exe

Ok, but I don't understand why you would need to send so much in one calculator code statement... I will set the limit to 1k in the next release. That should be sufficient for most use - for example, the longest calculator code statement in the MF events.txt file is just short of 800 characters. John

It would just use more memory. 8k isn't much these days, but I would be reluctant to use such a high value when this would just be unused for 99% of people. For the next release, it will be 512bytes. After that, when I have time, I will look into allowing this to be controlled via a user (i.e. ini) parameter. John

Do you still have debug level logging enabled for the WAPI in your FSUIPC7.ini when that log file was produced? Your log shows that the lvar information wasn't received from the WASM, and the WAPI closed its connection after 64 seconds: 64516 21120 [INFO]: SimConnect_Close done This is why you have no access to lvars.

Could you also try the attached version which has additional logging added. Just use this with the same logging as added previously (just replace your current FSUIPC7.exe with this one), run it once (no need to run MSFS) and show me the FSUIPC7.log file produced: FSUIPC7.exe

Could you take a look at your registry (using the windows regedit program) and tell me what you see under this entry please: HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_0EB7&PID_183B John

This will most probably be due to timing. Try increasing the LvarScanDelay parameter in the FSUIPC_WASM.ini file - see the Advanced User guide for details. I really don't understand this...what has re-installing FSUIPC got to do with anything? FSUIPC scans for lvars each time an aircraft is loaded (nothing happens on FSUIPC7 launch). When an aircraft has finished loading, the WASM waits for a number if seconds (defined by the LvarScanDelay parameter) and then checks for the existence of all lvars by requesting the name for each lvar given an id, starting at 0 and incrementing by 1 and terminating when a null lvar name is received. This is the standard way to determine what lvars are available for the loaded aircraft. John

It is a limit imposed by the WASM / WAPI modules, which are part of FSUIPC. Sure - would 512 bytes enough? I could increase to anything up to 8k, which is the limit on Client Data Area sizes in the MSFS SDK. John

This is what FSUIPC previously did, when it was an embedded dll. I took the decision to switch to using SimConnect to receive keyboard input, as I had issues getting the input via hooks (can;t remember what exactly, was a long time ago now...), and using SimConnect also allows FSUIPC to receive (and act) upon keyboard input when it is running on a client PC (i.e. a separate PC to the one the FS is running on). But what if you are using a utility program and you need the keyboard input to go to that program? Grabbing all keyboard input, regardless of focus, seems a bad idea IMHO. Sounds like you are treating all keys as hot keys doing this.... Revising how FSUIPC handles keyboard input is something I could look into I guess, at some point...but I don't know if/when I will have time to look into this. There are far many other things I would like to do before this. and don't have time for much development at all at the moment....all my time is taken up by support and keeping up with MSFS / P3D releases at the moment... Maybe you could share your program and I can take a look. I could possibly make it a configuration option to handle keyboard input differently, but I think the way it is currently handled is sufficient for most folks. There do seem to be some issues with custom keyboards though, or button-boxes that act like keyboards.... John

Can you please show me your FSUIPC7.log file with the custom logging I requested activated and when running as administrator, i.e John

Not sure what this means, but you should always be using the latest version of FSUIPC, especially if you require support. Only the latest version is supported. The current version is v7.2.15, so please update if not using that version. Calibration is always specific to your devices and aircraft. Just assign your axis 'direct to FSUIPC calibration' and calibrate your axis in FSUIPC. You can add a slope curve (also in the calibration panels) to reduce or increase) sensitivity - try playing around with those to get a feel that is right for you. I wish you a speedy recovery! Cheers, John

This is what I thought your issue was. I can't see how this can be anything to do with FSUIPC. It maybe related to your graphics drivers - have you tried updating these? Yes, but you can select the installation folder during installation. Re-run the installer and change the installation location, and then copy across your remaining files (.ini, .key, .lua, .mcro, .dll, etc) to the new installation folder. Yes, sorry - forgot you were using FSUIPC6 and not FSUIPC7, but the installation is the same. Please see the Installing and Registering FSUIPC document. I provide the Above mentioned manual.. You should read that before installing. Nobody seems to read the documentation... Yes, the documents are always installed in an FSUIPC6 sub-folder of your Documents folder - you cannot change this. John