John Dowson

This sounds like the axis has been registered as a digital on/off axis, although I would have expected to see 0 (not -16383) and 16383. Check this post if this is the issue: Otherwise, check and try calibrating in the windows game controls configuration, and see what values/movement you see there. John

If you don't want to have the splash-screen, just don't use (or install) the MSFS desktop icon. This just displays the splash screen and starts MSFS, so if you don't want the splash-screen then use the MSFS icon or menu entry to start MSFS instead. John

I don't know why you are attaching your installation logs... Have you read what I have already said on this issue? I cannot add any more to what I have already said, and you need to tell me what is actually happening:

What does this mean? There is no password, and there is nothing that you can change. All 3 parts of the registration - Name, Address, Key - should match the details you received in your purchase email, and also available in your SimMarket account. Copy and paste the details so that they are the same. If it still does not verify, check that your VC++ redistributables are up-to-date. I recommend you uninstall any of the VC++ redistributables you have currently installed for 2015, 2017, 2019 and 2022 and download and install the latest combined packages (both x64 and x86) from https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist. If you still have issues after this, let me know your order number and I will check it here. Do NOT post your key details! John

Do you have a steam or MS Store version of MSFS? Please attach your InstallFSUIPC7.log file. Did you run MSFS at least once before trying to install FSUIPC7? What is the location of your MSFS UserCfg.opt file? John NB: I have deleted your other post on the same issue

This depends on the MSFS version - whether you have an MSFS install or a steam install. For the latter, it is under <USER>\AppData\Roaming\Microsoft Flight Simulator

It is still not possible to detect the active pause states, as far as I am aware - although I have not looked into this again for some time. MSFS contains various different pause states, activated by different controls. It is recommended to switch to one of the other pause controls, which are detected. I posted about this in the Asobo forums: https://forums.flightsimulator.com/t/simconnect-mega-thread/116305/79?u=impolitegem5317 John

You seem to keep having the same issues...but I really can't say any more in the auto-start than I have already.... John

Looking at the MobiFlight HubHop resource (https://hubhop.mobiflight.com/), there are 4 presets available for toggling the 4 superchargers: PMDGDC6_SUPERCHARGER_1_TOGGLE - 128101 (>K:ROTOR_BRAKE) PMDGDC6_SUPERCHARGER_2_TOGGLE - 128201 (>K:ROTOR_BRAKE) PMDGDC6_SUPERCHARGER_3_TOGGLE - 128301 (>K:ROTOR_BRAKE) PMDGDC6_SUPERCHARGER_4_TOGGLE - 128401 (>K:ROTOR_BRAKE) These are quite new and may not be in the current events.rxr file included with FSUIPC7 - I have attached the latest one. John events.txt

The only config parameter for VRInsight devices (apart from the COM port config section) that comes to mind is this one: Then the issue will be with your assignments. As with PMDG aircraft for other FSs, many of the standard controls / offsets do not work and you have to use custom controls (using various parameters with the Rotor Brake control). Alternatively, there are many presets available for the PMDG 737 for MSFS, although these will not be in the current events.txt file included with FSUIPC7. I have attached the latest below - use this to replace your current one and you should see many new presets for the PMDG 737. John events.txt

👍

I'll take a look next week (Wednesday - holiday until then...) - but if they are lvars, they are already available. Try listing the lvars - Addon->WASM->List Lvars - and see if they are there... John

Maybe the control codes have changed. Check the documentation for the MSFS version, or check the MobiFlight hubhob site (https://hubhop.mobiflight.com/) for available presets - there are currently 270 available. However, they won't be available in the current events.txt file as this is out of date. I have attached the latest event file - use this to replace the one in your current FSUIPC7 installation: events.txt With that updated event file, there are three presets for this: PMDG_B737-7_LIGHTS_ANTI_COLLISION_OFF PMDG_B737-7_LIGHTS_ANTI_COLLISION_ON PMDG_B737-7_LIGHTS_ANTI_COLLISION_TOGGLE Looking at the preset code, you can use the Rotor Brake control (event id 66587) with a parameter of 12401 (if you don't want to use the preset directly). John

You should always check your FSUIPC7.log file when adding lvars to offsets as these will most probably tell you what the issue is, and you should also always attach that when requesting support on these issues. Looking at your ini: Several things stand out: 1. you have no profile called 'Boeing'. You have two profiles - '247' and '737'. If you are setting this up for the B247D, it should be: [LvarOffsets.247] i.e. it needs to match the name of the profile that you want to use this with. 2. Your lvar names contain spaces...are you sure this is correct? I suspect they should be L:ENG_THROTTLE_1 L:ENG_THROTTLE_2 i.e. use underscores rather than spaces. 3. You are assigning all those lvars as single unsigned bytes, so that they can only hold an integer number between 0 and 255. Are you sure this is correct? Check what values the lvars you are using hold, and assign them the correct type. Also make sure that the offset size is correct, i.e. if you change the type to a larger size, make sure that the next lvar is not overwriting the offset area from the preceding one. John

Not 100% sure as I don't have this aircraft, but I suspect that there will be PMDG custom controls for this, using specific parameters for the Rotor Brake control. If you are not familiar with PMDG custom controls, see the following FAQ entry: John

FSUIPC has a 'spoofing' facility activated by offset 0x0024, which allows another value to to override the actual offset value when being read from external programs - see the offset documentation for details. I also provided a script to show how this is done for the parking brake offset 0x0BC8 substituting the value with the value from the lvar L:A32NX_PARK_BRAKE_LEVER_POS - see As for the specific PMDG variables, I am still unsure what PMDG are providing for the MSFS version. For P3D/FSX, PMDG provided additional data that is added to a specific PMDG offset area. I am still waiting to hear from PMDG if this additional data is available in the MSFS version, or if they are now providing this information in another way, such as via lvars. If PMDG are providing this data (via custom client data areas) I will update FSUIPC7 to include this data and provide documentation on what is available. I will post updates on this is the following thread: John

Ah yes...that has been know to cause issues with complex aircraft...thanks for reporting back. John

Please attach your FSUIPC7.log and FSUIPC7.ini file. Note that I am on holiday and will not be looking into any issues until Wednesday. John

No problem!

I think you are misunderstanding what the event functions do... they register a function to be called when the event occurs - the actual event.key functions registers the event and returns straight away. The handling function is called when the event occurs - it could return a value but there is no point as there is nothing to handle the returned value (except the thread...). John

👍😎

The issue was a simconnect issue and not specific to FSUIPC or Spad.next (and nothing related to the auto-start), although it was these programs that seemed to be the most affected. It was related to requesting specific simvars when MSFS is in the main menu which caused a CTD, which has now been fixed. John

Do you mean you cannot open FSUIPC7? Is it starting - do you see an FSUIPC7 splash screen? Have you looked in your system tray to see if its there? If it is, you can open it from there or use the (default) hot-key Alt+F to open the FSUIPC main window. If your issue is that FSUIPC7 is not auto-starting with MSFS, there are already many threads on this issue - check them for a solution. Have you assigned and calibrated it? Does FSUIPC7 see this yoke? You really need to provide more details if you want further help. I do not even know if you have FSUIPC7 tunning at the moment... John

This is basically correct - the *_EX1 controls don't go through FSUIPC's calibration. However, you can do more than just reverse - you can perform scaling on the axis values (see P41 of the Advanced User guide, section Additional parameters to scale input axis values). FSUIPC's tiller axis blends rudder and tiller controls and the blending can be controlled by various ini parameters - see the box on page 30 of the User guide for details on how this works. If you don't want to use rudder/tiller blending, then assign directly to the FS tiller control rather than the FSUIPC added one, and scale or reverse as needed. John

This is a problem with MSFS. The FSUIPC WASM module just scans for lvars whenever a new aircraft is loaded, and reports what it finds back to FSUIPC7. It sems the MSFS returns many lvars used in both previously used aircraft and for aircraft sitting in your Community folder that have not been used. This can create issues as currently only a maximum of 2044 lvars are returned from the WASM to FSUIPC7, and so if you have an aircraft such as the FBW A320 installed in your folder, many of the lvars will be for this aircraft, reducing the number available (or returned) for the current aircraft. Note that when the WASM scans for lvars, there is no way for it to know if the lvars are for the previously loaded aircraft or an aircraft just installed in your Community folder - as far as the WASM and FSUIPC7 are concerned, they are the lvars that are currently available. Due to this, it is recommended to clear your Community folder of all aircraft before starting MSFS and just leave the one that you want ti use for that session, and most people use the MSFS add-on linker for this. There is not much I can do about these extraneous lvars - this needs to be addressed by MSFS / Adobo. I could increase the number of lvars passed back from the WASM to FSUIPC7, but the current limit (2044) should really be enough. I may consider increasing this (to 3066) in a future update, but it will take me a while before I have time for this. This has been reported before: John