John Dowson

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.

Shouldn't be a problem. I'll look into this next week and maybe post a dll for you to test (FSUIPC6).

Which switches? What list? What "Hex of the control" - sorry, I don't understand. To assign a button or key to control a switch, first see if there is a "control" to operate that switch. The controls are the items displayed in the assignments drop-down menu. There is also a text document created (in your Documents\FSUIPC7 folder) called Controls List for MSFS Build 999. Also, if you activate logging for Events and toggle the switch in the UI, the event (or control) that the switch uses will be logged, and you can try assigning to that. Note you can 'Open Console' (also available from the log window) to see the events logged directly as you activate them. If no standard controls/events are available, you can look to see if there are any lvars available to control these switches. To do this, use the Add-ons -> WASM -> List Lvars menu option (you must have your aircraft loaded and ready to fly). If you see any that look like they might be what you need, you can try changing their value (using the WASM->Set Lvar... menu option). Once you have identified an lvar that works, you can then assign to this. There are three ways to do this: - by creating a macro file - by writing a short lua script - by trying the latest FSUIPCv7.2.0 beta which has a new facility to add lvars to offsets. The first two options are described in the user guide. For the third option, see I can't really help if you do not provide any relevant information. Which aircraft are you using? What did you assign to? Is this assigned to an axis or to buttons/keys? If you want further help with this, I will need to at least see your FSUIPC7.ini and FSUIPC7.log files, and a description of what you are trying to achieve and what you have tried.

Just to avoid the overhead of flagging the virtual button that triggers an assignment that then sends the control, by sending the control directly. However, makes more sense to use virtual buttons if your assignments are different for different profiles, as you say. The 'fast' rotary should send the controls at a faster rate. If you are only sending controls in the press event you are only getting around 8-10 'presses' per second, and are so only sending 8-10 controls. If you also send on release, you double this to 16-20 controls per second. It is common practice to assign this way for 'fast' rotaries. Another common practice, especially for trim wheel assignments, is to duplicate your assignments (by editing the ini, copying the assignment line and increasing the index number), which is basically the same as 'just sending two control/virtual keypresses on the button press', as you say. Of course, you can also do this for the releases, if you also have them assigned. Some people use one method, others a mixture of both, whatever feels right for them.

Ok, glad its now working for you. There are lots of things on the stock Asobo A320neo that aren't working (and never will). Thats why there is the FBW version. Just use that.

The 0.0000 value at 18047 us also VERY early (18 seconds after starting), thats probably the empty value before it received any data. However, I don't understand why its logging later as U32 and no later log as FLT32. This is the problem when you paste extracts - they are difficult to understand. Please do as advised, log as both U32 and FLT32, and then show me your full log and update ini files.

Error 740 indicates that you need elevated/admin privileges to run. What is this? Why are you trying to run a http address - that is never going to work....(and Error 2 is File Not Found) Error 2 is simply 'file not found'. Are you sure that you have the correct location? What happens when you open a command prompt and type: 😄\Program Files (x86) \Google\Chrome\Application\chrome.exe F:\MicrosoftFlightSimulator\Procedure Avion\A320NX_Checklist_OddSobriquet\AirlinePack A20NX_Checklist_AirFrance.pdf ? So many spaces in that command as well, and I am not sure if they are there or not. Please, next time, do not paste content, but attach both your FSUIPC7.log and FSUIPC7.ini files so I can see EXACTLY what they contain.

That and anything else - did you install ANYTHING from honeycomb with your Alpha/Bravo? If so, remove for the time being. Have you looked at the User guide? We provide extensive documentation so that we don't have to answer such questions. Please read the documentation, try things out, and report back IF you have issues. And I have already told you where to start: Yes, but you aren't using profiles. Why don't you actually try to create a profile and start assigning to it? But if they are working in P3D and you havbe no assignments in FSUIPC (except for throttle 1-4) then you must have them assigned elsewhere, either in P3D or in the Honeycomb config tool. You really need to decide where you want to assign. If you want to assign in FSUIPC, we recommend disabling controllers in P3D, and you should not use the Honeycomb configurator or any other software from honeycomb, at least initially when wetting things up. And, as I have already said, if you have any issues, I need to also see your FSUIPC6.log file, with relevant logging added showing your issue. But I would advise you to start by at least reviewing the User Guide.

You are using an old (unsupported) version of FSUIPC6. Please update to the latest (supported) version, v6.1.1. And try the attached FSUIPC6.ini file: fsuipc6.ini You have multiple devices of the same name and I am not sure which is which. If they are the wrong way around, try swapping the assigned letters (in your [JoyNames] section. section) - with FSUIPC closed.

I'll take a look in detail tomorrow, but why are you reading the offset? Your function and event call are wrong: Try with: Well, that shouldn't happen! You should try again and if you get issues report them. Best to set logging for the WAPI and WASM to Debug and attach your FSUIPC7.log and FSUIPC_WASM.log files of/when reporting issues. Where is this from? Its not in the log you attached. Maybe try monitoring 0x0818 as both a U32 and a FLT32. It would be helpful if I can see that in the full log, together with your updated ini. That really shouldn't be necessary. Your log shows the script start ok the first time: Anyway, there has been a couple of changes in management oif lua events in 7.2, so please download and try that and report back first, and I'll take a look in more detail over the weekend.

You should monitor as a FLT32, not U32. ipc.readFLT is correct. I don't know why you are getting that value, it does seem strange. I will take a look (probably tomorrow now though), but would be useful if you could attach your FSUIPC7.log file showing the issue, together with your FSUIPC7.ini file and your lua script. You should maybe also try the latest FSUIPC7 beta, available here: John

The installation of the MSFS.bat file is not logged in the installer. Do you not have an MSFS link (to the batch file) on your desktop?