John Dowson

But what exactly is your problem? Your files show that all 4 of your devices were detected and acquired for use: Can you not assign to them? What have you tried? Your ini file shows no assignments and is basically empty. Why did you not install the FSUIPC WASM module? You will have no access to lvars, hvars or presets without this installed. Also better to have FSUIPC7 auto-started with MSFS. If manually starting. best to do this when MSFS is up and running and at the main menu, to prevent issues that can arise from too many reconnection attempts. John

There may be an old version of FSUIPC3 around somewhere that works with FS2002, but I am afraid that I cannot provide this. Your question has also been asked before - see Later: Maybe one of these versions will work (found by google): 3.75: https://www.flightsim.com/files/file/65823-fsuipc-375/ 2.92: https://www.fs2000.org/2002/10/16/fs2000fs2002-fsuipc-dll-v-2-92/ Note that there is also a free license available for FSUIPC3 (presuming it works with these older versions) on FSUIPC.com. John

Ok, then you will have lost any presets that you added to the events.txt file. You should only add events to the myevents.txt file - that is why this is provided, and leave the events.txt dile for the MF presets, which is updated on each release. You could check your recycle bin to see if your old events.txt file is there. If so, restore that but then move the presets you added to that to the myevent.txt file instead, Thanks! John

Yes - the events.txt file is ALWAYS deleted when you uninstall, and re-installed when you install (provided you have not de-selected the install component for this). The myevents.txt file is never touched - this file is not known to the installer or uninstaller. This is why you add your own presets to the myevents.txt file and not the events.txt file. The latter is managed by the installer/uninstaller, whereas the former is managed by you. No, as I have no idea what you added to your myevents.txt file. I have my own, of course, but it will be completely different to the one you were using. As I said, you have to try and find it on your system - you are the only one with that file, and it is created and managed by you. If it has gone, then you must have deleted it. Please don't attach images - far better to attach files, i.e. it is your InstallFSUIPC7.log file that would tell me what was installed, not a screenshot. Your screenshots do show that you have Explorer set to hide the extensions of known file-types - best to change this. Also looks like you deselected the option to install the MF events.txt file for some reason. If you didn't do this, there may be an error in your installation log but I doubt this very much as there has never been an issue installing this file.

Or find out which offset it is using, if it is getting this value from an FSUIPC offset. You can then spoof the value of the offset it is reading to read the correct value from a different offset, using the facilities provided at offset 0x0024. There is a lua example plugin provided that shows you how to do this, called liar.lua. John

Installing/re-installing does not touch the myevents.txt file - if it is gone you have either manually removed it, or possibly you have re-installed into a different folder. Did you change the installation location? If so, the file will be in your old installation folder. You can also check the UninstallFSUIPC7.log file which will list the files it has removed. It should be in your installation folder, but if its not there then, as I said, you have either manually removed it or possibly installed into a different folder. Try searching your system for this file - you can use Everything or something similar. If the file is not on your system, there will be no way to recover it. John

Sorry, but I don't see how this can be due to the latest update - or in any update. If your axis is inverted, then this is due to the device driver, and not FSUIPC. There are two ways to handle an inverted axis: 1. via calibration, if calibration of the axis is allow via FSUIPC's calibration pages 2. via axis scaling, using a parameter of *-1 appended to the end of your axis assignment entry - see the section Additional parameters to scale input axis values in the Advanced User guide on page 42. If you need further assistance, please show me / attach your FSUIPC7.ini file so that I can see your assignments. John

This is usually due to using an aircraft with a different livery and not using substrings for your aircraft names in the profile section (i.e. you must manually edit the name of the aircraft in the profile section of your FSUIPC6.ini file)... If everything is shaded/inactive, then this implies that there are either compound or offset conditions have been added to the assignment, or that the button/switch is overloaded (i.e. has more than one control assigned to it). To diagnose assignment issues, please activate logging for Buttons & Switches as well as Events/controls (non-axis) and reproduce your issue, and show me/attach your FSUIPC6.ini and FSUIPC6.log files, after exiting P3D. John

If you are using a steam installation, check to see if a phantom xbox controller is being detected - this is a known issue, and can be fixed by adding IgnoreDevice=0x28DE,0x11FF to your [JoyNames] section of your FSUIPC7.in file. Otherwise, f your devices are not being recognised, please show me/attach your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files. As a new forum user, your upload limit will be very low and the files may need compressing/zipping. Note I have deleted your first post on this issue, posted in an unrelated topic. John

Looks like something is continually trying to set two lvars (with ids 2109 and 2110. Try listing the lvars (via Add-ons->WASM->List Lvars - the lvars will be listed with ids and in id order in your log file) to see what those lvars are, which should give you a clue as to what is updating them (probably either a lua script or maybe GSX). Try and see if these are necessary and if they can be stopped. But 4 lvar updates a second shouldn't cause any issues, but excessive logging can cause stuttering issues. Why are you logging the FSUIPC WASM to the MSFS console, instead of the WASM log file? You must have set this in one of your FSUIPC_WASM.ini files - stop this by setting/changing the ini parameter LogType back to File: ; LogType: File, Console, Both LogType=File You can also switch off such logging by setting the LogLevel back to Info. You only need Debug level logging set when needed for support issues.

Is this just on client/remote, or also on the server/FS machine? If just on the client, it may be because SLC cannot access lvars when running on the client (at the moment), so you will need to wait for an SLC update. If its also on the server/FS machine, then ask about this on the SLC forums. Yes - you added this to the client FSUIPC7.ini so that FSUIPC7 can talk to the remote WASM, and as instructed in the Appendix that shows you how to configure FSUIPC7 for remote access. Your logs also showed that this was working fine.

Please see the README.txt file (section Problems installing or registering FSUIPC7) and/or the Installation and Registration guide (section Invalid Key Problems) and follow the advice given there. Only once you have tried everything mentioned there and it still doesn't work, then let me know your FSUIPC7 order number and I will check your details here. Note that in all cases where this is reported this is down to either user error, not having the latest combined VC++ redistributables installed, or due to anti-virus software.

Note that you can always use FSUIPC's offset logging facilities to check/verify the contents of an offset. The aircraft title offset 0x3D00 is certainly populated/available, but may not when MSFS is in the main menu. John

Your remote log looks good, thanks. Your MSFS machine log does show some re-connection attempts at start-up. Looks like your DetectToConnectDelayAuto ini parameter is set too low: the current value is 115, you should change this to around 170.

What sort of problems? I doubt very much this is anything to do with the latest version - there were very few changes in this update and nothing that should cause any issues... I don't usually provide older versions as any issues with a new version should be rectified in that version, However I gave attached the previous version, 7.4.16, below for you to try. Rename your current exe (e.g. to FSUIPC7.exe.7417) and save the attached version to your FSUIPC7 installation folder and try that. If your issues are no longer present, could you then go back to the latest version and try again. If you still get issues, let me know what they are and attach your FSUIPC7.log file, as well as your FSUIPC7_prev.log file from the working version so that I can compare them. John FSUIPC7.exe

FSUIPC only holds a small subset of available simvars (or a-type variables) in its offsets. If you want to use (i.e. read and write) the value of a simvar via offsets, you can add it to a spare/free FSUIPC offset - see the section Adding Simulator variables (simvars) to FSUIPC offsets on page 35 of the Advanced User guide, If you just want to update the value of the simvar, you could define a preset for this, instead of adding it to an offset. But if not familiar with calculator code or RPN, may be easier to add it to an offset and use that, John

Which is why I said to refer to the documentation! it is an ini parameter that changes the default location where the lua files should be located.

Note also that macros are also an easy solution to toggle or set lvars and hvars, but if you also need to read the values of an lvar better to add to an offset and use that. See the Advanced User Guide for details on macro use. I can also see now that the documentation also needs updating, as macros also handle presets and input events.

Thanks for the update. Note that this fix has now been released in the latest version of FSUIPC7, v7,4,17. John

You don't have to use macros - you can just overload the assignments if you prefer, as I showed. However, if you have many buttons with overloaded assignments, and you are using more than 2 actions on a button press/release, it may be better to use macros, but its up to you really. Create a macro file - you would normally name it after the aircraft to which it applies, or maybe the the aircraft + subsystem. As this is for the PMDG777, create a macro file called PMDG777.mcro. and add the following contents: [Macros] 1=GearLandLights 1.1=C66079,0 1.2=C1152,2500 1.3=PPMDG_B777_Landing_Light_Nose_Off,0 Restart FSUIPC7 and you can then assign to the macro and then you would need to add the compound button condition to the assignment (compound and offset conditions always go on the assignment, not in the macro itself). John

Lua scripts should be placed in your FSUIPC installation folder, unless you have LuaPath set in which case they go in that folder - see the documentation. I don't have the fenix so can't help much, but you just need to look into replacing the lvar A32NX_AUTOPILOT_1_ACTIVE with something similar for the fenix, i.e. add an lvar (or something) to that offset which indicates when the AP is active. Maybe the OP @Adamski can help... John

That won't execute both actions as you have the same index number - should be: 19=CP(+A,23)A,10,C66079,0 -{GEAR_UP}- 20=CP(+A,23)A,10,CPPMDG_B777_Landing_Light_Nose_Off,0 -{Preset Control}- To insert a delay, you can add a pause control, e.g. 19=CP(+A,23)A,10,C66079,0 -{GEAR_UP}- 20=CP(+A,23)A,10,C1152,2500 21=CP(+A,23)A,10,CPPMDG_B777_Landing_Light_Nose_Off,0 -{Preset Control}- That will add a delay of 2.5 seconds (2500 milliseconds)., Note that you can also use macros to send multiple commands - see the user manual for details. John

As I have said, you have to choose between the GF software and FSUIPC. If you want to use FSUIPC to control your GF device, then follow the instructions for FSUIPC. I have told you what to do several times now, and there is plenty of documentation which you seem to be ignoring. Again, then read my posts and the provided documentation and try things. If you think this then you have not read the documentation correctly and have not tried to assign anything to your GF devices yet. Why don't you try this? Once FSUIPC is registered, you will have visibility of the buttons/switches assignment panel, which is the UI you used to assign your buttons/switches, and is described in the user manual. No programming is required, although some advanced features may require manual editing of the FSUIPC ini file, which is also described in the user manual). Because there is nothing specific or special about a GF device - it is just another controller. You assign the buttons/switches/rotaries as you would with any other controller. The FSUIPC GF driver (GFDev.dll) just makes the GF device visible to FSUIPC, where it is then treated like any other controller. There is no distinction between any other standard USB controller and a GF device, except that the additional driver is needed for GF devices. I don't understand why you keep posting the same questions, which I have answered many times, and don't just go ahead and try things...at least register your FSUIPC3, install the GF driver and go to the button assignments panel and try and assign to your GF devices. Please do not post again until you have at least tried that. Once you have some hands-on experience, things will hopefully make more sense....

You are trying to install FSUIPC5 or FSUIPC6 - this is NOT compatible with FSX/FSX-SE. You need FSUIPC4, which requires a separate license. John P.S. You posted in the FAQ sub-forum where it states NOT for support requests, I have moved your post.

I have just taken a look at the GFDisplay documentation, and in the first pages, under Installation and Configuration, it says: Did you not see this? i.e. nothing is going to work if you are using an unregistered/unlicensed version of FSUIPC3, which you seem to be doing for some reason, even though the license is freely available. I repeat, READ THE DOCUMENTATION. John