John Dowson

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

I need to see this file. It should not be that big, but try zipping/compressing and then attach - it is a text file and should compress to a small size. John

Are you using Windows 11? If so, please see the provided README.txt: John

Also, just check your FSUIPC7.log file. Maybe the lvar wasn't available to add to an offset once you loaded the aircraft? This can happen with complex aircraft as it can take up to a minute or longer before all lvars become available. You can adjust when FSUIPC scans for lvars by setting the LvarScanDelay WASM ini parameter to a higher value. Its default value is 5 (seconds). I use a value of 45seconds, but some folks find that a minute or longer is needed. This depends on your system and the aircraft in question. Please see the Advanced User guide on how/where to use/set this parameter. John

It comes with the installer. Just download the latest version and run the installer. Not if you want to continue using the MobiFlight events via FSUIPC event files. You can do things without the MF WASM, but you would have to stop using the MF events and re-program those assignments to use lvars, hvars or calculator code. This is quite straightforward for most MF events, as they just set lvars or activate hvars, but some are more complex and require compound assignments. For the time being, it may be easier to continue using the MF WASM module. For the next FSUIPC7 release, I am planning to implement a mechanism that sends calculator code directly from predefined custom events, such as those listed in the MF events.txt file, and to also allow parameterized custom user-defined events. This should remove the need to use the MF WASM module entirely. I will publish details hwen ready. John