John Dowson

64. Thanks for the update.

But don't the controls do what you want - i.e. either increment by 100 or 1000, as you want? If you want different sized increments, you could use one of the Offset <size> Increment/Decrement controls (where <size> is the size of the offset, probably a dword). Maybe try with offset 0x07D4 (Autopilot Altitude Lock Var). In the A320, you may have to switch between managed and selected modes (using the ALTITUDE_SLOT_INDEX_SET control). There may be more info on this on the Asobo forums, e.g. https://forums.flightsimulator.com/t/a320-fcu-variable-autopilot-altitude-lock-var-vs-displayed-altitude/307093/7 John

It pointed to that folder as that was the previous installation location (as you had it installed there for both v4 and v5) and the installer will always default to the previous installation location. But it IS possible for you to change this - the installation page after the component selection page (in the installer) is the 'Choose Install Location' page, where you can select the destination folder by using the Browse... button. What you cannot change is the location of the add-on.xml file, as this is defined by P3D. The problems you encountered were due to the fact that you installed for both v4 and v5, so used a single installation folder. When you ran the installer again, to install v4 into a different folder, this would have ran the uninstaller first and uninstalled, and then the default folder for the v4 install would be the v5 folder. You could have changed this, but didn't. And it would have also replaced the uninstaller (*for both v4 and v5) in that location with the v4 uninstaller just created. If you then ran the installer again, to install for v5, this would detect the v4 uninstaller and run that, so v4 would be uninstalled when installing v5. So, the problem in the installation/uninstallation is that if you want to switch back from using a shared installation for both v4 and v5 to separate installations, you should first manually run the uninstaller to remove and then run the installer twice, once for v4 and once for v5. Well, you may have problems in future (when updating) doing this as the FSUIPC registry entries will not be correct. You should delete and use the installer. Uninstall everything first (using the uninstaller first and then manually removing everything), and then install again using the installer, running it twice if separate installations required. And it is highly recommended to choose an installation folder outside of your P3D add-ons folder, and outside of a windows protected folder, e.g. C:\P3D Add-ons#FSUIPC6 (for shared location) or C:\P3Dv4 Add-ons\FSUIPC6 (for v4 only location).

As the lvar name is the macro entry name, you should not have the same lvar more than once on a macro, especially if using the same action. No, the set values have never appeared in the drop down list. Its usually just the name which should be sufficient for you to identify the action, but in the case of single lvar macros the action is also appended to the lvar name. "Macro invocation" just means when the macro is ran, so when you run the macro, the parameter is copied to the lvar (or, in other words, used to set the lvar). It refers to the parameter however it is supplied, in the macro file or in the assignment. You can do things either way, but better to leave the parameter off in the macro file and just set the parameter in your assignment, i.e. just use: [Macros] 1=L:PITOT_L=SET 2=L:PITOT_R=SET - and you must do it this way if using the same lvar and action with different parameters, otherwise there is no way to distinguish the different entries.

Hi Ralf, Ok, thats good! No idea. Sounds very strange, but that can't be anything to do with FSUIPC. Did anything else change? Try uninstalling FSUIPC (just run the uninstaller from your FSUIPC7 installation folder, or from the windows app management panel) to see if the problem is still there - I suspect so. You can re-install FSUIPC7 again in the same folder - it only rakes a minute or so. Greetings from Galicia! John

First, you posted in the wrong forum. I have moved your post for you. Second, you posted your key in a public forum. This invalidates your license conditions and your key can be banned for doing this. Please, NEVER post your registration details, especially your key, in a public forum. I have removed it from your post. As for your issue, did you enter all 3 fields exactly as written in your purchase email (with the key being 12characters, so no hyphens)? If not, please try again. If you still have issues, post again and Pete can check your details from your order number (I have no access to your details as FSUIPC4 is still with Pete).

What about the instructions isn't clear: ? So, uninstall any of the 2015, 2017 or 2019 ones that you have installed, and then download and install BOTH combined (i.e. 2015+2017+2019) versions (x86 and x64) from the provided link.

First, you posted in the Announcements section, where it explicitly states Not for support requests. I have moved your post for you, but please take care to post in the correct forum in future. K variables are for "key" events, i.e. either standard MSFS events/controls (as listed in the Controls List for MSFS Build 999 text document ) or add-on custom controls, which contain a period. That one looks like one of the latter (as it has a period). Is that an event from the FBW mod? It looks to be, as MF events, handled by the MF WASM, are usually preceded by 'MobiFlight.'. You could try to use add-on custom events in FSUIPC by using "event files", and is explained in the Advanced User Guide, section Add-on Custom Events, P36. Basically create a *.evt file (e.g. A32NX.evt) in your FSUIPC7 installation folder, and add the following content: [Events] 0=A32NX.FCU_HDG_INC The event should then appear in the assignments drop-down menu for you to assign and try.

Which offset is it using to drive the sound? If you know what that is, and if it can be changed, you could maybe do something.... I think the animation is driven differently - I doubt very much the animation is driven by the simvars on the gear position... I don't know if this is a "problem" - more probably just the way the model/animation works. If the sound is driven by an offset and you can change the offset, you could have a lua plug-in which copied the values from the original offset to a new offset but added a delay before doing this. You can then use this new offset, to drive the sound, if that is possible. Or ask them to make the offsets configurable. Then you can control what is written to the offset and when, either by using a timer or possibly a different event or simvar, if there is something that can be used to detect when the retraction has started and completed that matches the animation.

If it was previously working, what has changed on your system? This error is usually caused by missing or corrupt VC++ redistributables, and you need to uninstall and re-install. This is explained in the README.txt file that is included in the zip you downloaded: John

FSUIPC knows nothing about the visual information. FSUIPC will be receiving events and/or simulator variables (simvars) from the FS and updating the relevant offsets. What is the Bas Shaker using to drive the sound - is it using FSUIPC? There isn't anything we can do in FSUIPC - we just show the data as received from the sim, or send the event to control the start of the open/retract. Just checked the BFF Bass Shaker V2 page and it seems it comes with its own configuration software, and it talks to the FS directly, not using FSUIPC. I think you should maybe contact their support for this.

You need to determine which one, if any, is showing that message. Could it be something else? You could also show me your FSUIPC log file (and ini maybe) - that should show what was started and shut down.

That message looks to be from a program that uses FSUIPC, not FSUIPC - its an error sending a message to FSUIPC after all. What program is sending that message? Are you using FSUIPC to shutdown that program as well?

Hi Morten, I responded to this yesterday but all my posts from yesterday have gone missing for some reason... I think you are misunderstanding the installer and where things are installed. The installation log you posted showed the installation went fine. When installing for P3Dv4 and P3Dv5, you have two alternatives: have one FSUIPC installation for both versions, or have separate installations for both versions (by running the installer twice). This is all explained in the provided Installation and Registration manual. Please read this. This was basically incorrect and a misunderstanding on your part, as shown by your installation log, which shows that you opted to install FSUIPC6 for both P3Dv4 and P3Dv5, and you selected (or accepted) your P3Dv5 add-ons folder for the installation folder: So the installation for both v4 and v5 is that folder: C:\Users\Bruger\Documents\Prepar3D v5 Add-ons\FSUIPC6. i.e. your P3Dv5 add-on xml folder. It is better to select a different folder during installation, something like C:\FSUIPC6 or C:\P3D Add-ons\FSUIPC6, and keep your GSUIPC6 installation folder separate from your add-on.xml, which is the file used by P3D to auto-start FSUIPC6. The location of this file is defined by P3D. The installer/uninstaller does not change or remove any files, including your settings, other than those it has installed/creates during installation. In no way can it delete "essential files". You will be looking in the wrong location, or must have deleted them manually. Please read the Installation and Registration document. If you want separate folders for each P3D version, you must run the installer twice, once for each version.

Ok. But remember you don't need WideServer anymore - that is built into FSUIPC since version 4 (so in FSUIPC4/5/6/7). And WideClient7 is the same client you need to for FSUIPC4-7, so if it was already installed it was probably the correct version (i.e. WideClinet7 not WideClient6). However, always a good idea to check you have the latest version.

Hi, I responded to this yesterday but looks like all my posts yesterday have gone missing.... Many of the functions on the stock B787 are not currently accessible. There are at least two mods available for the B787, you should try them to see if either have implemented those functions. Otherwise, you can always ask for this to be implemented in the mod. There is the B787-XE project: https://fs-2020.org/d/184-boeing-787-mod-for-mfs https://github.com/lmk02/B787-XE and the B787-10 Heavy: https://github.com/Heavy-Division/B78XH

This update was never applied to FSUIPC4 as that has now been closed for future development for several years - at least since Pete retired.

Ok. Thanks for the update.

I responded to this yesterday but all my posts from yesterday seem to have gone missing... Ok, they are custom controls. If there are custom controls available for your aircraft, you will have to consult the documentation for the aircraft, or ask on the CRJ forums if any are available. Custom controls are provided by the add-on, of available, so you need to check the add-on documentation. I don't have the CRJ, sorry. Betas are posted in the Announcements forum - see: If you don't see the WASM menu under the Add-ins menu, you are either using a version earlier than 7.1.0, or you didn't select to install the WASM, or there was an issue installing the WASM. Anyway, download the latest beta from that link above and try that. For taxi and landing lights, try: ASCRJ_OVHD_TAXI_SWITCH ASCRJ_OVHD_LDG_LEFT_SWITCH ASCRJ_OVHD_LDG_NOSE_SWITCH ASCRJ_OVHD_LDG_RIGHT_SWITCH John

Please try the attached dl; v6.1.2c: FSUIPC6.dll

Sorry, that was my fault misleading you without checking...its also not clear from the documentation/spreadsheet. I will update to clarify.

As well as not using a free offset, as Pete has said, you shouldn't have a space between the size identifier and the offset (although it might work, I'm not sure). As you have defined the size of the offset to be SW (Signed word), when you read or write/assign. you should use the Offset Word Set/Setbits/Togglebits/etc controls for assigning, and ipc.readSW if reading in lua. i.t. ALWAYS match the controls/functions that you are using to write/read to the actual size you have defined for the offset to hold the lvar. Alternatively, and better, if that lvar just holds a 0/1 to designate on/off, store it in an unsigned byte offset, using the UB size designator, then assign to Offset Byte Set or Offset Byte ToggleBits assuggested by Pete (and using a free user offset, e.g. A000). John

Why 'of course'? I don't know this, which is why I asked. Did you try from the same drive/location that FSUIPC is located? The error reported (Error=2) indicates 'file not found', which is the error FSUIPC is receiving from windows when trying to execute that command. Maybe try a few things, such as opening a pdf on the same drive, or using a different pdf viewer. But you don't execute urls. You open them in a web browser.

No! Where is the offset (location), i.e. the place to store the value? Please see the provided documentation:

Yes, you can swap the letters over in the ini to revertback, as I said. What is not working? Profiles use the same joyletters that we adjusted in the main ini, so should not need any updates. You do have quite a few lua scripts. If any of those use joy ids instead of joyletters, then they will need updating. But if they are using joyletters they should also be ok. Maybe try activating logging for both buttons and events, load a profile aircraft and operate a button and see what is logged. If it doesn't look correct, show me your updated FSUIPC6.ini, FSUIPC6.log and your profile.ini.