John Dowson

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

You can use either. If using set, make sure you are setting to 0 for off and 1 for on. If using toggle, you can add an offset condition so it only toffles depending on the current value. If you do not understand what that means, use set. Please: 1. Activate debug level logging in the WAPI. To do this, add the following to the [WAPI] section of your FSUIPC7.ini file: LogLevel=Debug 2. Set Log->Buttons & Keys in the FSUIPC7 menu. 3. Load your aircraft and press the assigned button 4. Exit FSUIPC7 5. Show me your FSUIPC7.ini and FSUIPC7.log files. John

No...why do you think that? For PMDG aircraft, you have to use their SDK - custom controls and PMDG offsets. See the included document on PMDG offsets Offset Mapping for PMDG 777X.pdf, and check out this FAQ post on how to use PMDG custom controls: It will be in your FSUIPC5 Documents folder, which should be under your Modules folder. The upgrade price from FSUIPC5 to FSUIPC6 is 9.99euros (+ tax). You should get that price automatically on checkout if you have purchased a license for FSUIPC6. But maybe you don't need this, up to you... John

Two things may apply: 1. When you manually change the ini, you need to either restart FSUIPC for these to take affect, or, usually if it is an assignment you are changing, you can reload the assignments from the UI assignment panels (see the reload assignments button in each panel). 2. Sometimes lvars are not available on the initial scan for lvars. You can force a rescan/reload of lvars using the Add-ons->WASM->Reload menu option. For complicated aircraft, it can take up to a minute after the aircraft has loaded for some lvars to be available. There is a parameter that you can set in the WASM ini file (FSUIPC_WASM.ini) called LvarScanDelay. This is, by default, set to 5 seconds. I use a value of 45seconds, but some folks have this even higher. The correct value depends upon your system and the aircraft you are using. If you find that the lvars are not initially available, try a reload to see if they then become available, and if they do, try increasing this scan delay parameter. John

Of course! The ini file is where FSUIPC saves the assignments you make in the UI. Why are you using set rather than toggle (as the example I keep referring you to in the advanced user manual)? With that assignment, you are setting the lvar to 0, i.e OFF. But does the master caution turn off in the aircraft? That is what this assignment does. What happens to the bravo lights is another matter, and that depends on how you are controlling the bravo lights (are you using AFC Bridge? Or the FSUIPC lua scripts?)- this is a separate issue. On the Bravo or in the aircraft? If this works when you change the lvar value using the Add Ons -> WASM -> Set Lvar... menu, it will work via an assignment. If its not working, try logging - add debug level logging to the WAPI (by adding a LogLevel parameter to the [WAPI] section of your FSUIPC7.ini - RTFM) and button & key logging in FSUIPC7 via the log menu. Then keep the logging console open so you can see what is happening when you press your assigned button. John

You are confusing two different methods. One method is to add the lvar to an offset, AND then use an offset manipulation control on that offset - you DO NOT need a macro file. The second method is to use a macro file. If you are using a macro file, you DO NOT need to add the lvar to an offset, So, in this case, as you are adding the lvar to an offset, just remove the macro file. Then, assign your button (or key press) to the Offset Byte Togglebits control, giving the offset value as 0xA000 (the offset you are populating), and the parameter as x1. This is EXACTLY the same as the example given on P45 of the Advanced User guide, except that you are using a different lvar name - but it is still a boolean type variable (with values 0 or 1). What is so difficult to understand about this? Can you please explain as I am getting pretty fed-up of repeating basic information when I have spend a lot of time to provide user manuals for this.... Also, please remember that you should NEVER manually change the [MacroFiles] section in your ini (as with many other sections). This is managed by FSUIPC and should never be manually changed, unless you really know what you are doing. In fact, never change anything in your ini unless advised in the documentation or by support. There is no place that says you should manually adjust this section. Any issues, try looking at your FSUIPC7.log file. This should indicate any errors, and you can also add more logging via the FSUIPC7 Log drop-down menu. You should learn how to use these facilities and understand what is logged, to help you solve your own issues, although I am always here to help - but that should be a last resort... I have now had many many support requests like this, and, to be honest, it is becoming a bit of a pain, as it is always the case that the manual hasn't been read or followed, and i am endlessly repeating myself. This takes time away from more useful activities, such as improving the documentation (which nobody seems to consult anyway...) and adding new functionality.... John

I am also looking into making calculator code easier to use in the next version of FSUIPC7. I will publish exact details when this is released, but the general idea is to allow you to define paramterised calculator code and give that a control name, which you can then assign to directly in the control menu drop-downs. I will use the same format as the MobiFlight events.txt file (except parameterized, i.e. allow a parameter in the calc. code that is replaced by the value you define when you assign to that control) so that the MobiFlight events.txt file can be used directly, i.e. without having to install the MF WASM module or any FSUIPC event files. John

Please see the following post: That is for FSUIPC6 and using PMDG aircraft, but the technique is the same. The controls you assign to will be different however, and that depends upon which aircraft you are using. You can try the default controls - and always a good idea to set this up using default controls in your default profile, and use profile-specific controls for aircraft which use different controls. It is up to you to determine which controls to use for the aircraft that you have loaded. John