John Dowson

I suspect that there is an issue as you have installed an application under your user account' AppData folder. Please re-install into a non-windows specific/protected folder, such as, for example, C:\FSUIPC7 or C:\MSFS-add-ons\FSUIPC7. You can skip registration and copy/move across your FSUIPC7.key (and FSUIPC7.ini, and any other files you may use) to the new location. Once things are running as expected, then delete that folder.

What is that path? The GFDev64.dll should be in your FSUIPC7 installation folder, which should NOT be under your MSFS Community folder - although that is where the FSUIPC WASM module is installed (folder fsuipc-lvar-module). If you don't know where your FSUIPC7 installation folder is, use the File -> Open Installation Folder option. Otherwise, please show me/attach your FSUIPC7.log file. John

Before anything else, please update your FSUIPC7 version to the latest version, 7.3.20 - you are using an old an unsupported (beta) version, 7.3.9i. If you still get connection issues, please first refer to the WideFS7 User Guide before posting again, and read the section Configure your Network. If you still get issues, AFTER configuring your network and trying various options (especially setting the Protocol and ServerName or ServerIPAddr address WideClient ini parameters). then also attach your WideServer.log file, as well as the updated 4 files that you already attached. But it is far easier for you to diagnose any network issues on your side, given the information provided in the WideFS User guide and Technical manuals provided. Cheers, John

No. This information is taken from your Windows registry, and the reason why it is blank is due to the GUID assigned to the CH THROTTLE QUADRANT being the same as two entries for xbox 360 controllers: There you can see two xbox controllers and your CH THROTTLE QUADRANT having the same GUID and the same id assigned. The empty name is being taken from one of those xbox entries. Are you actually using two xbox controllers? If not, the solution would be to remove those entries from your registry. I can help you with this if needed. If they get added back after removal, you may need to remove the CH THROTTLE QUADRANT entry as well (it will get added back once its reconnected), but first try removing those xbox entries. Once they have been removed, reboot then start FSUIPC7 (no need to start MSFS) and take a look at your log and ini files again. If they show any issues, post/attach them here again. John

That's an interesting idea. I don't think this would replace the current menu, but I could add a button that pops-up a tree-view window, and then the selection made there could populate the drop-down selection. I will make a note and look into this when time permits. I am also thinking of changing the selection from a drop-down list to a combo-box. this would then allow you to enter more characters to find the correct preset, rather than just positioning the drop-down on the item starting with the letter of the key pressed. Everything in the ini file has a purpose - see the Advanced User guide for a description on the button assignment lines. You can do that - just make sure that the index number (first number on the line) is unique, and also that the joystick letter and button numbers are correct (as well as the press, release or repeat code/letter). Also, if doing this when FSUIPC is running, make sure the button assignment window is open when you edit the FSUIPC7.ini, and click the Reload button once you have saved any changes. Once you have done this, reload the FSUIPC7.ini file in the editor (as it will be re-written) and check there are no errors. John

The email address is different in the WideFS7 purchase (flying@mpcee.co.uk) to the one used in your FSUIPC7 order. Did you check the box and enter this different email address (and also re-enter your name, which is the same for both) as advised? John

All 3 parts must match - email, name and key. If the name and/or email for your WideFS7 license is different to that of your FSUIPC7 key then you need to check the appropriate box and also enter those details. If that is not the issue, please let me know your WideFS7 order number and I will check your key details here. John

Then you need to load the AS_connect dll, get the addresses of the functions/variables you want to use, and then use them to generate the radar/bin file: ... if (!hBtstrpDLL) hBtstrpDLL = LoadLibrary("as_connect_v5.dll"); if (!hBtstrpDLL) hBtstrpDLL = LoadLibrary("as_connect_64.dll"); if (!hBtstrpDLL) hBtstrpDLL = LoadLibrary("as_connect_v6.dll"); if (hBtstrpDLL) { // Get pointer to its exported "ASN running" BOOL BYTE *(FSAPI *ASNIsRunning)(void) = (BYTE *(FSAPI *)(void))GetProcAddress(hBtstrpDLL, "isActive"); if (ASNIsRunning) ... pAmbientIcing = (BYTE *) GetProcAddress(hBtstrpDLL, "AmbientIcing"); pWshLat = (float *) GetProcAddress(hBtstrpDLL, "WshLat"); pWshLon = (float *) GetProcAddress(hBtstrpDLL, "WshLon"); pWshRange = (float *) GetProcAddress(hBtstrpDLL, "WshRange"); pWshMinAlt = (float *) GetProcAddress(hBtstrpDLL, "WshMinAlt"); pWshMaxAlt = (float *) GetProcAddress(hBtstrpDLL, "WshMaxAlt"); *((FARPROC *) &pSetRdrParams) = GetProcAddress(hBtstrpDLL, "SetRdrParams"); pAmbientTurbulence = (float *)GetProcAddress(hBtstrpDLL, "AmbientTurbulence"); pExportedPrecipType = (BYTE *)GetProcAddress(hBtstrpDLL, "ExportedPrecipType"); pExportedPrecipRate = (BYTE *)GetProcAddress(hBtstrpDLL, "ExportedPrecipRate"); pExportedAmbientVisibility = (float *)GetProcAddress(hBtstrpDLL, "ExportedAmbientVisibility"); pInCloud = (BYTE *)GetProcAddress(hBtstrpDLL, "InCloud"); ... Exact details on how to use the dll functions should be provided/available from ActiveSky. John

I am slightly confused by this as there is no Active Sky for MSFS - as far as I am aware... This makes sense, as there is no radar data (bin or jpg) produced by FSUIPC7, as there is no ActivceSky for MSFS. And is this radar image correct? Does the data/image come from ASN or MSFS? There is no way to get weather radar data via simconnect. There is a WebAssemply API that is provided that allows weather data radar images to be created and used in glass cockpits - the MapView API - maybe ProSim is using this? See https://docs.flightsimulator.com/html/Programming_Tools/WASM/MapView_API/MapView_API.htm I did look into this API to see if it could be used to generate a radar weather jpg (but not a radar.bin file - that is ASN specific) via the FSUIPC WASM, but it was not obvious that this could be done easily as the API looks more like like something to be used by aircraft developers. I may spend more time looking into this API to see if it can be used by FSUIPC at some point in the future. John

Sort of...FSUIPC see's a press on the first button press and a release on the second (or vice-versa, depending on the initial state of the button's toggle flag. The button assignment panel only registers a button when it sees the press, not the release, although you can assign to the release in the same panel. Yes, you should be able to do that - as I suggested earlier, you could try using the beacon/nav lights on preset on the press, and the off preset on release (or vice-versa). Note that you can simulate this type of action on any button by using the buttons' latch flag, denoted by an F when using compound button conditions - see the Advanced User guide for details. Not good memory, unfortunately - I just searched these forums for a similar issue. Try the forum search in future, rather than just google. Cheers, John

You didn't really answer my questions...can I assume then that its the second case, and that the first button press is not detected/logged? This would also imply that the first press isn't being detected for some reason. This issue has also been reported previously - see So it seems that this is how the VRI MCP works, as a (sort-of) toggle - so on one press you get a press event, and the next you will get a release event. And as you assigned only to the press event, its only taking action every other press. So the solution would be to assign the toggle preset to both the button press and release. Also see the following topic conversation that talks about this issue: John

But do you see the first press registered/logged/detected by FSUIPC? Your log shows two button presses for the beacon lights (with another two a short time later): If you see the press being detected and logged each time, and the preset is being executed, it can only be a problem with the preset calculator code. Which version of the FBW A320 are you using (release, dev or experimental)? Have you tried switching to using the on/off presets on press/release instead? If you don't see the first press detected/logged, then the issue will be with the lua that is being used for your VRI device. As it looks like you are using LINDA for this, you should contact LINDA support if that is the issue. John

You can do this with an "offset condition" - see page 24 of the Advanced User guide, section ADDING OFFSET CONDITIONS. You need to have an offset that holds the current switch position, then you can add a test on this value to determine if the assignment should be triggered or not, depending upon what value the offset holds. Try adding this yourself - if you need further assistance then please show me/attach your FSUIPC6.ini file.

As it says on the download page (on SimFlight) for MakeRunways: Looks like I still need to update fsuipc.com with this information though... John

It is created by FSUIPC, but the contents are provided by ASN in a callback as a block of binary data, and FSUIPC just writes the provided data as received. You need to check the ASN documentation to determine the content and structure of this data.

No, but you MUST understand how these things work. When using a profile, if an axis or calibration section is present in the profile, then these profile-specific section will be used and the general axis and calibration sections will be ignored completely. However, if either of these sections is missing from the profile, then the general sections will be used. Button and key assignments work in a different way. All general button and key assignments are inherited in a profile, unless overridden/redefined. That really shouldn't happen - only the ATR profile assignments should be used as they will replace the general assignments. If you think that this is not the case, then you need to show me/attach your complete FSUIPC7.ini and ATR.ini profile files, and also a log generated with logging for Buttons & Keys and Events activated. This will show what assignments are being selected when you press the button/key.

The radar image is just a bitmap. The other file contains information used for "other processing or investigation". I am not sure in the format if this file and it doesn't seem to be documented anywhere. Maybe check with ASN.

Such errors can sometimes be safely ignored, especially if they are only reported in a single add-on aircraft. But if they are reported for many aircraft then this can be a sign of corruption in your P3D installation, and you should re-install the P3D Client component. John

You can use the control number of the Offset Byte control that you want to use to write to offset 0x0B46, with the appropriate parameter - see the Advanced User Guide on page 33. Otherwise, if there is a custom control number for the aircraft you are using, yo can also use that. Or if there is a preset available, yo can calculate the control number of the preset and use that, although it is better to use the preset name itself via offset 0x7C50. John

That is correct - there is no specific functionality for speedbrake detents. How have you assigned your speedbrake axis? You could try assigning in the right hand said if the axis assignment panel, where you can set a specific value for the speedbrake when entering/leaving specific ranges. This should allow you to set the specific value for a detent when entering the axis range around that detent.

Ok, thanks for the update. John

Sorry, but I don't know what else to advise. You can check the windows Event viewer to see if anything is reported there. You can also check that your VC++ redistrubutables are up to date - but I have never seen an issue with the VC++ redistributables with FSUIPC4 before.... There is nothing wrong with the installer - it has been downloaded and used by thousands of people without issue. The issue is certainly specific to your system and I cannot advise any further on this. If all else fails, you can try manually installing FSUIPC4. To do this, create a Modules folder under your FSX folder and place the FSUIPC4.dll in it. You then need to manually modify the FSX dll.xml file, located under <your user account>\AppData\Roaming\Microsoft\FSX If the dll.xml file doesn't exist, you can create it with the following content: If it exists, just add the FSUIPC4 <Launch.Addon> section John FSUIPC4.dll

I do not understand what your issues is.... your GoFlight modules should be detected and available for assignment just as any other controllers. In your FSUIPC7.log file you should see the devices detected - this is what mine shows: If you then go into FSUIPC's button assignment panel, you should see the button presses detected and can be assigned there. John

Also, check that you are running everything at the same privilege level - if one application is running with administrator privileges, then everything else must be ran at the same privilege level or they won't connect.

Your log shows no issues. I can's see how this can be an FSUIPC issue, but you can try setting logging for IPC Reads and IPC Writes - this should then log any activity of programs that use FSUIPC.