John Dowson

Sorry, but it seems that you have either not read my previous comments or have not understood them. I have no idea why you would want to put the GFDev.dll in the GF software folder - it goes in the FSUIPC installation folder (i.e. in the modules folder under your FS installation. And you have to choose between using FSUIPC doe your GF devices or the tools provided by GF. If using FSUIPC, you should NOT use any GF drivers - uninstall them and let windows install default drivers, And do not use/run any GF tools - you only need FSUIPC3 and the FSUIPC GF driver. Again, please see my previous comments. There is no point in even looking at GFDisplay until you have FSUIPC working with your GF devices. And you need to understand how to use FSUIPC3 before toy can start with GFDisplay. Gave toy read the documentation for FSUIPC3, as advised? Well, if its not registered then nothing is going to work, Details of the FSUIPC3 key are available on the fsuipc website (https://fsuipc.com/). I do NOT run the forum (that is SimMarket). I support FSUIPC, versions 4, 5 and 6, As I said, FSUIPC3 is unsupported, but I can help you where I can... But you haven't! You seem to have not even read my previous comments, let alone any of the required documentation, i.e. the documention that comes with FSUIPC3, NOT the GFDisplay documentation. And as I have already said, you proceed by installing AND registering FSUIPC3 (which you haven't done..), then you install the GFDev,dll in the correct place (which you haven't done), and then you test and program/assign your buttons/switches/rotaries. Only once that is done and you understand the basics if using GF devices with FSUIPC, then start looking at GFDisplay and/or lua scripts to control the displays. That is certainly not going to happen and is not necessary. Just read my comments and follow my advice, You seem to be ignoring almost everything I am saying, which is why you are having so many issues. Read my comments and follow my advice - if you can't do that, I cannot help you. John

Yes. If you have multiple versions of P3D installed, then you can either use a single FSUIPC6 installation for all P3D versions installed, or you can have separate installations for each P3D version - see the Installation and Registration guide for details. Why roll-back and not have both P3Dv5 and P3Dv6 installed? You can use the same installation for FSUIPC (and also for many add-ons, aircraft and scenery) for both installations (when using the add-ion xml method). If its on the PC clients, it should be started by WideClient, not FSUIPC, as FSYUPC only runs on the server/P3D PC, not the client. So why copy into FSUIPC.ini? A WideClient installation in a client PC will be exactly the same when using P3Dv5 as when using P3Dv6. Any issues with programs not starting, check your logs to see what the error message/code is - they will give you a hint as to why they are not started. John

No issues? You said: "after much research have failed to get them working in both FS9 and FSX"? Ok, but this is thew first time you have mentioned FS2004. As far as FSUIPC is concerned, FS2004 is the same as FS9 - you need FSUIPC3. Sorry, but this is not possible. The current/latest 32-bit GF driver is (file) version 2.2.2.1 (or product version 2.22, a bit confusing..) from January 2013 - what version are you using? And if using the FSUIPC GF driver (GFDev.dll), you do not need any other GF drivers or software - remove these. Of course! Once the GF driver is installed, this will make your GF buttons/switches visible to FSUIPC, where you then need to assign your buttons/switches, as you would with any other device/controller. The GFDisplay driver is another additional program that uses FSUIPC and the GoFlight driver (GFDev.dll) and is used for driving displays, Start with just FSUPC3 and the 32-bit GoFlight driver (GFDev.dll) and try and assign some buttons/switches. Once you have that working, then add in the GFDisplay program and read the manual to use this. Lua is a programming/scripting language. FSUIPC has a lua interface and additional lua libraries that allow you to write lua scripts that interface with the FS and FSUIPC, and allows further access to GF devices via is gf library. Please see the documentation provided by FSUIPC3. I don't understand why you are having so much difficulty... First, install FSUIPC3 and the 32-bit GFDriver and take a look at the documentation that comes with FSUIPC3. Read the Installation and Registration guide, which will tell you how to install and register, then the User guide, and also take a look at the Advanced User guide and the Lua Plug-Ins document. This should give you an overview of the functionality available and the knowledge to program/assign your GF buttons/switches/rotaries. Once you have that working, then look into adding GFDisplay to control your displays. And please note that: - FSUIPC3 is provided free-of-charge but is unsupported. This is very old now, I have never used it and have no access to the source - I do not have any GF display devices and have never used the GFDisplay program so cannot really help with this - I don't have and have never used FS9 or FS2004 What GF devices do you actually have? You can also try searching these forums for advice and possibly lua scripts for specific devices. But I really don't understand why you/anyone would want to continue using FS9 or FS2004. You should consider updating to either MSFS2020 or P3D (v5 or v6), or at least FSX (but this is also very old now!).

Yes - it is available as an FS Control, but it shouldn't really be needed...

No - I don't have anything configured/assigned for this aircraft. For aircraft that I have for support purposes, I only look into assignments on request (and when I have time!). This looks like quite a complicated aircraft and I would need to spend quite a bit of time to learn how to control this. For example, I don't know how to activate the Autopilot in the cockpit - I can't seem to move the AP engage switch in the VC, but I suspect this is something to do with the state of the aircraft (I can see/read that it needs turn knob in detent and one yaw damper powered, as well as main/essential power on - I would need to read/investigate on how to do this...!). However, there do seem to be quite a few lvars as well as input events available for the auto-pilot: Input Events: AUTOPILOT_PITCH_SELECTOR<>=2.000000 AUTOPILOT_KNOB_VERTICAL_SPEED<>=0.000000 AUTOPILOT_TURN_KNOB<>=50.000000 AUTOPILOT_HDG_SEL<>=0.000000 AUTOPILOT_ALT_SEL<>=0.000000 AUTOPILOT_ENGAGE_SWITCH<;FLOAT64>=0.000000 AUTOPILOT_NAV_SELECTOR<>=0.000000 Lvars: 417188 [INFO]: ID=529 FSS_B727_PDSTL_AUTOPILOT_HDG_ENG_SW_IsDown = 0.000000 417188 [INFO]: ID=530 FSS_B727_PDSTL_AUTOPILOT_HDG_ENG_SW_MinReleaseTime = 0.000000 417188 [INFO]: ID=531 FSS_B727_PDSTL_AUTOPILOT_ALT_ARM_SW_IsDown = 0.000000 417188 [INFO]: ID=532 FSS_B727_PDSTL_AUTOPILOT_ALT_ARM_SW_MinReleaseTime = 0.000000 417188 [INFO]: ID=533 FSS_B727_PDSTL_AUTOPILOT_ALT_ENG_SW_IsDown = 0.000000 417188 [INFO]: ID=534 FSS_B727_PDSTL_AUTOPILOT_ALT_ENG_SW_MinReleaseTime = 0.000000 417344 [INFO]: ID=1130 FSS_B727_PDSTL_AUTOPILOT_HDG_ENG_SW = 0.000000 417359 [INFO]: ID=1131 FSS_B727_PDSTL_AUTOPILOT_ALT_ARM_SW = 0.000000 417359 [INFO]: ID=1132 FSS_B727_PDSTL_AUTOPILOT_ALT_ENG_SW = 0.000000 417406 [INFO]: ID=1322 FSS_B727_WASM_SET_AUTOPILOT_HEADING_LOCK_DIR = -999999.000000 417469 [INFO]: ID=1573 FSS_B727_PDSTL_AUTOPILOT_HDG_ENG = 0.000000 417469 [INFO]: ID=1574 FSS_B727_PDSTL_AUTOPILOT_ALT_ARM = 0.000000 417469 [INFO]: ID=1575 FSS_B727_PDSTL_AUTOPILOT_ALT_ENG = 0.000000 417609 [INFO]: ID=2044 PMS50_AUTOPILOT_INSTALLED = 1.000000 417609 [INFO]: ID=2045 PMS50_AUTOPILOT_VERSION = 3.000000 417609 [INFO]: ID=2046 PMS50_AUTOPILOT_TOGA_ACTIVE = 0.000000 417609 [INFO]: ID=2047 PMS50_AUTOPILOT_MANAGE_MANUAL_ARMING = 1.000000 417609 [INFO]: ID=2071 PMS50_AUTOPILOT_ALT_ARMING = 1.000000 417609 [INFO]: ID=2085 PMS50_AUTOPILOT_CAPTURED_ALTITUDE = 0.000000 417625 [INFO]: ID=2142 FSS_B727_AUDIO:autopilot_disconnect = 0.000000 So you should try those - you can see what values are needed by activating in the Virtual cockpit then re-listing the lvar/input event values and see how they change. If there are both input events and lvars available for a button/switch, I would try the input events first, although an lvar update may be sufficient. Let me know how you get on - any issues let me know and I can investigate further. John

Yes. This just means that any lvars detected after the initial scan will not be known to FSUIPC, i.e. if you try and list them or use them with an lvar function (e.g. adding to FSUIPC offsets, using directly in a macro or in a lua lvar function) then they will not be seen or updated. You can still use such lvars via presets/calculator code. This should not be an issue as any lvars you want to use should be loaded and available after the first scan. Note also that if you create lvars via the various mechanisms for this in FSUIPC, a scan will automatically be performed and the lvar will be available. You can also force a scan if/when required (via the Add-ons->WASM->Reload menu option, or via lua (ipc.reloadWASM()) or a specific add-on control Reload WASM). John

It is likely that your WASM module is crashing - see the following FAQ entry on how to confirm this and how to prevent this (or at least make this less likely to occur): John

FSUIPC3 is compatible with the FS9.1 update (which was made available on October 9th 2004) but not FS9. FSUIPC3 is now available for free - see https://fsuipc.com/. But be aware that FSUIPC3 is no longer supported. For Go Flight modules, you need to use the FSUIPC 32-bit GoFlight drivers, available from the same location - just copy the dll to your FSUIPC3 installation folder. Note that I have never used FSUIPC3 (before my time!) but I believe the GF driver should also work with this version. For FSX, you will need a registered copy of FSUIPC4, and also the 32-bit GF driver. There is certainly no issue running FSX/FSUIPC4 on Windows 11. If FS9.1 also runs on windows 11, then so should FSUIPC3 (as it is an embedded dll) and the GF drivers. John P.S. GF devices are also supported by FSUIPC's lua interface. Lua scripts will be needed to support any GF devices that have displays. See the User Contributions section of this forum for some lua scripts for GF devices.

Ok, thanks, Just want to check that the PMDG 777 thread is started/stopped correctly when needed (on the client PC/installation).

Your looks fine, although looks like you were using the Fenix A320 rather than the PMDG 777 so I couldn;t check if that thread was started/terminated correctly. John

Sounds like your WASM module is crashing - please see the following FAQ entry:

Looks likes you attached that log when FSUIPC7 was running, and it ends after less than 0.5 seconds and doesn't really show much...very strange - did FSUIPC7 crash?

Sorry, I should not have suggested this as the SDK for the 777 is different from that of the 737. The 737 presets use the custom control (via the Rotor Brake control): For the 777, the custom control is the following: To use custom controls in PMDG aircraft, see the following FAQ entries: To use the custom control in a preset, you have to use the first method (i.e. via the Rotor Brake Control). Create two additional presets: My_PMDG_B737_EFIS_CPT_BARO Dec#19108 (>K:ROTOR_BRAKE) My_PMDG_B737_EFIS_CPT_BARO Inc#19107 (>K:ROTOR_BRAKE) My_PMDG_B737_EFIS_FO_BARO Dec#25808 (>K:ROTOR_BRAKE) My_PMDG_B737_EFIS_FO_BARO Inc#25807 (>K:ROTOR_BRAKE) Sorry, but if you ask for help with something that is clearly documented, you will be referred to the documentation. Documentation is provided so that I do not have to answer the same questions repeatedly. If I do not understand what you are asking, I will of course need clarification and further information - I am not a mind reader...And I support FSUIPC7 and can show/help you how to use this - I do NOT support MSFS, PMDG aircraft or any other specific aircraft, although I do help out with assignments when I can...and if I have the aircraft, but this is not something that is included when you buy FSUIPC. Things ARE complicated with MSFS - there are so many different ways to assign, and every aircraft is different. I just supply the tools to help you with this. You need to learn how to use them.

The view controls have not been working since MSFS was released - from the README.,txt file: You can also control use using the camera presets (under MobiFlight -> All vendors -> All Aircraft -> Camera). Or you can set the simvars CAMERA STATE, CAMERA SUBSTATE, CAMERA VIEW TYPE AND INDEX:0 & CAMERA VIEW TYPE AND INDEX:1 individually via offsets 0x026D, 0x026E, 0x026F & 0x0270. John

You use the exe I provided to replace the current one in your FSUIPC7 installation folder - iy will use the same installed WASM as the previous release (i.e. no WASM update). Ok, good to know, thanks - probably due to the PMDG 777 thread now running. Could you please show me your FSUIPC7.log file from this version, on the client machine, so that I can check a few things. You should raise a support ticket for this. Also ask if lvar access when running across a network can be added as this should be possible and relatively straightforward, as the .Net dll that SLC uses for this already allows for this. Regards, John

That is everything available from the PMDG 777 SDK. If there are no specific offsets for throttle or auto-throttle, maybe the 777 is using the provided simvars in which case you can use the standard/general offsets for this. Otherwise look at the available lvars, which can be added to spare/free FSUIPC offsets if required (for both read and write - PMDG offsets are read-only). I can see these lvars that may be of use: Throttle1_Pos Throttle2_Pos XMLVAR_LeverThrottleHidden1 XMLVAR_LeverThrottleHidden2 MCPAutothrottleSwitchOnLeft MCPAutothrottleSwitchOnRight MCPAutothrottleSwitchOffLeft MCPAutothrottleSwitchOffRight There are no "Input Events" available for the PMDG 777. There may be some H-vars (HTML variables), but you would need to inspect the throttle behavior to discover these (see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/). But Hvars don't hold values and are only for controlling HTML elements in the UI, so most probably not relevant. If none of this is sufficient for your needs, you can ask PMDG about this. John

I have corrected for this in the attached version, 7.4.17b, if you could try it. Please show mr your FSUIPC7.log file from the client PC after using - and please exit FSUIPC7 before attaching files. John FSUIPC7.exe

I have discussed this with Steve, the SLC developer, and it looks like there are currently restrictions when using SLC on a remote/client PC: SLC will need an update to handle lvars on a remote machine. Ok. Looking at your log file, there are a few issues I need to fix when running FSUIPC7 on a client machine: - I need to update the PMDG 777 thread to be able to use the remote connection - WASM / WAPI facilities are disabled as no WASM installed - the WASM is on the server machine and these facilities should be available (this was previously working, but I think a recent change in initialization order has broken this) I will look into these issues, but I'm afraid that this will not fix your issues with SLC. John

Ok - best to read the section Multiple Joysticks for Multiple Pilots on page 45 of the Advanced User guide.

I think this maybe the issue...Are you also running FSUIPC7 or WideClient on the remote machine as well, or just SLC? If running FSUIPC7, have you configured this for remote access on both the [General] and [WAPI] sections (as explained in the appendix on setting-up FSUIPC7 for remote access)?

Note that another user posted a similar issue a couple of months ago: There was no resolution to the issue though as the OP didn't respond to my last post.

@lamikela1 You posted this in a very old topic and in the main support forum - I have moved your post to the specific sub-forum for FSUIPC7. That is incorrect as you have duplicate index numbers, so only one will be used. All index numbers MUST be unique, so try: John

I have no idea as I don't have SLC and know nothing about this.... What does this mean? There is a known issue with the WASM in that it can crash when using complex aircraft and complex add-on scenery. There is a FAQ entry on this with a fix - see If that is not your issue, please provide a more detailed explanation of what the problem is, and please show me/attach your FSUIPC7.log and FSUIPC7.ini files, attached when FSUIPC7 is NOT running, and also your FSUIPC_WASM.log file (see the Advanced User guide if you do not know where this is located) attached when MSFS is NOT running and after a session where you experienced your issue. John

Many MSFS aircraft continually emit some events, and these events are different for each aircraft. You can stop such events being logged by using the DontLogThese ini parameter. Ok. The 4th registry entry isn't causing any issues so you can ignore this. This is something that the MSFS steam edition seems to create on start-up. If you exit FSUIPC7 and restart it once MSFS is running, you should not see this device. What that ini parameter does is to ignore this device when detected, so it shouldn't cause issues. I also need to see your FSUIPC7.ini as this has also been modified...you now seem to be using a profile called 'Fenix A320 - Scoot (2018) 8K' which wasn't present in the ini files you previously attached... Did the 'safety no smoking' presets work: ? Do other presets work after you have determined that the seat-belt preset doesn't? If not, you may be experiencing a WASM crash. Please see the following FAQ entry on how to determine if the WASM has crashed and if so how to prevent this: If that is not the issue, then I will need to investigate further, but I can't see how this can have anything to do with the use of the IgnoreDevice ini parameter The seat belt presets you are using just change the value of the lvar L:S_OH_SIGNS between 1 (on) and 0 (off). When you execute the preset, does the lvar value change (you can list the values using Add-ons->WASM0>List Lvars)? If so, then the preset is working as expected. If not, can you manually change the value of this preset using the Add-ons->WASM0>Set Lvar menu item and does that have the desired effect? For any future logs, please activate logging for Buttons & Switches, Events, Extras and WAPI->Debug level logging. No logging for Input Events necessary. You can also ignore those other events by adding the following to your Fenix [Profile.xxx] section (where xxx is the profile name): DontLogThese=66068,65957,66519 Probably also a good idea to set Debug level logging in the WASM (via the FSUIPC_WASM.ini file) - see the Advanced User guide on how to do this / where that file is located. John

No need to see the log file as you have determined that the WASM crashed - just try with the updated parameters.