John Dowson

Yes it does. But there is nothing we can do in FSUIPC to fix this. It needs to be fixed in the RXP GTN750. We are requesting this data in the standard way - they need to correct their software so that SimConnect recognises the value has change and provides the value when updated. John

I see you are also using P3Dv4.5. I hadn't noticed this and checked in P3Dv5.1. I'll check in that version, but should be the same....

The numpad keys won't work, so please don't try/use them while testing. Your log file is also useless to me. You closed and started a new log. Please don't do this - I need to see the entire log. Please follow my instructions again and show me the entire log file. DO NOT activate any other logging other than that requested.

Ok. Thanks for the update. John

Just checked and the ATC menu options are working ok with the number keys (but not the numpad keys!). Could you enable FSUIPC logging for Buttons & Keys, load your aircraft, open the ATC menu and make a selection. Then close P3D and show me your FSUIPC6.log and FSUIPC6.ini files.

If you re-installed, you shouldn't have to re-register. The details should be populated from your existing key file. It looks like a key file wasn't created for some reason. You can create this manually. In your installation folder, create a file called FSUIPC6.key. Then open in an editor (e.g. Notepad++) and enter the following, replacing the parts in bold with the required information: Note you also installed FSUIPC in your P3D Add-ons folder. It is better to choose another location outside of this and outside of the P3D folders (e.g. C:\FSUIPC6 or C"\P3D Add-ons\FSUIPC6) to keep your FSUIPC6 installation outside of the P3D add-ons folder (and outside of a windows protected folder such as Programs Files).

Did you make sure all 3 parts (name, address or email, key) were exactly as specified in your simmarket email? Best to cut and paste to make sure. I don't have access to your order details, but Pete will (maybe) pick this up later and verify them.

No! It has to be there, with your FSUIPC7.log and FSUIPC7.JoyScan.csv files. Do you see them? Are you sure that you are looking in the correct place?

All standard (user object/aircraft) data is requested via simconnect using the SIMCONNECT_DATA_REQUEST_FLAG_CHANGED and SIMCONNECT_DATA_REQUEST_FLAG_TAGGED flags, so we only receive the data value from simconnect when they have changed. This is the case for all the data we request/receive.

The latest version of MakeRunways (5.11) is compatible with MSFS. Its up to you if you want to use it or not, depending upon if you have any utilities that need the output it produces.

You should not delete it, you should uninstall rather than deleting. An unistaller is created in your installation folder - please use that to uninstall FSUIPC7, or the windows App management panel. Its EXE.xml. Does the installer just stop there or does it continue? What happens if you click 'Next'? Do you have an MS Store install or a Steam install? Could you try uninstalling FSUIPC7, if installed. Run the uninstaller located in your installation folder. If it is not installed at the moment, you can skip that. Then check your EXE.xml file, and if there is still an FSUIPC7 entry, remove it. For MS Store installs, the file is located under LOCALAPPDATA\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\EXE.xml and for Steam installs, under: APPDATA\Microsoft Flight Simulator\EXE.xml Then run the installer again. For your installation folder, make sure that you select a location outside of your Documents folder (where it defaults to!) and outside of your MSFS installation (e.g. somewhere like C:\FSUIPC7 or C:\MSFS-Add-ons\FSUIPC7). Make sure the installer finishes, and if you have any issues, please attach your InstallFSUIPC7.log file. P.S. Please give your support requests an appropriate title, not your user name. I have updated it for you this time.

FSUIPC7 only supports a max of one 'accelerator' key. Did you try with just one - this was working in previous MSFS versions, but I haven't tested it in the latest version. Also, FSUIPC7 handles these accelerator keys (shift, ctrl, alt) in a different manner than other keys. It doesn't receive these keys via simconnect, but detects if they are pressed/held down when the main key is received via simconnect. Thats why the logging is different. So, please try with a single accelerator key. If thats not working, I'll take a look.

@DakotaPilot Its probably not going to happen as I just don't have the resources. There is so much development needed for FSUIPC7/MSFS, and with also keeping FSUIPC6 up-to-date with P3D, and support for all products (including FSUIPC4 and WideFS6/7), I just don't have the time and can't see this getting any better at least for the next couple of years...

But you can just leave MSFS running, you don't have to re-start it everytime. You can reload your button/axis assignments when needed (if editing the ini), or stop and re-start FSUIPC7. If assigning a device in FSUIPC, we recommend to initially start with an empty profile for that device. Just create a new profile for each device (apart from keyboard and mouse) in MSFS and assign then to your devices - new profiles are created empty. Your ini file shows that you are using v7.0.3. The latest version is v7.0.4 - please update. Your ini file is also a bit of a mess....! Have you manually edited this and not ran FSUIPC7 after editing? Some assignments are made to joyletters, others to joy numbers. This is very strange...did you add these manually? Do you have a 'Saitek Aviator Stick'? Its listed in your JoyNames section (assigned to letter Q) but has no GUID. You have assignments to it in your 'Bell Helo' profile. And you 'Robinson Helo' profile has assignments to device '0', which is your rudder pedels. Is this correct? The Cessnam Skyhawk 172SP is also assigned to two profiles 'FSX C172 Lessons' and 'single_engine_piston'. An aircraft should only be in one profile! You also have quite a few assignments to PAN_VIEW and other PAN controls - these are not currently working in MSFS. To control the views, you have to assign keypresses to the view controls in MSFS, and then assign your POV to those key presses. Anyway, please clarify what devices you have and also show me your FSUIPC7.log file, and I'll update your ini for you to try. You should also download and install v7.0.4, although don't run it yet until I've provided you with an updated ini. As for your flaps issue, I'm not sure what that is or for which aircraft, but we can look at that after we've cleaned-up your FSUIPC7.ini.

Thanks for the clarification. Please update if/when you get a response. John

Yes, this is a known problem and seems to effect the activity scenarios more than others. Not sure why, but again seems to be related to SimConnect usage by external clients. I can only re-iterate that if you get a CTD with MSFS (even if its only when using FSUIPC), then this is an issue with MSFS and should be reported to Asobo, Of course, if its FSUIPC that is crashing, then I'd like to know....I've had many reports of this but each one I've investigated is an MSFS crash and FSUIPC auto-closing as a result.... John

How are you monitoring that value? The FSUIPC knows nothing about 'S' values (or 'L'. 'H', K', etc). That's gauge code syntax. FSUIPC offsets are (mainly) based upon simulator variables, i.e. those you can request via the SDK. The variable lists accessible for this are published, one being 'GPS WP NEXT ID'. As I said, FSUIPC just receives that value from SimConnect and populates the offset accordingly. The problem is that the valur we receive from SimConnect is not correct. That must be due to the model not updating this correctly. Maybe the GTN750 you are using is not populating the generic P3D data variables for this and its using its own internal variables (lvars or local variables). John

That does sound strange. If the event is triggered (regardless of from where), it should be logged. Maybe an issue with custom controls and the SDK. I'll check this at some point, but FSUIPC can only log the events that it receives via the SDK. I will look into this at some point, but this may take a while (I'm trying to do just basic support at the moment, so I can concentrate on development...), post again if this is an issue and I may investigate further, but would prefer to delay this type of issue for the time being). John

Ok, thanks for the update. This also seems to confirm that its related to the amount of data going through SimConnect that provokes this issue, although that is for Asobo to decide and address. I could maybe pause/stall the data requests/reception until the flight is fully loaded to prevent this....I may look into this if this problem persists and is not addressed by Asobo. John

But the simvar that FSUIPC uses is the GPS WP NEXT ID! It is this simvar that is not holding the correct string/value. Maybe they use their own lvars instead?

Make sure that you are using the latest WASM module. You need to follow the MF/WASM forums to know what is working and the latest releases. And its only thr events that you can use at the moment - ignore the lvars and hvars. I am working on a WASM module for FSUIPC to handle these. I won't be providing a WASM module for events though - I'll leave that to other providers, and the events they use can be added to FSUIPC via the event files. The MobiFlight WASM an events list is updated quite often. Maybe check that you Module is up-to-date with the latest event list release. For the latest releases, the events that the MF WASM module supports are now in a text file included in the WASM module install itseld, so you can cross-reference there. John

Strange...I don't know how or why it stopped working (e.g. FSUIPC should have no affect on MSFS keypress assignments...) but I'm happy its now working....(so I don't have to look into this any further 😎) John

Did you try when starting FSUIPC7 after the bush trip has loaded? After you start MSFS, and if FSUIPC7 is auto-started, exit FSUIPC before starting the bush trip. Then load the bush trip, and when its finished loading, start FSUIPC manually. I know this is a bit of a faff, but I'd like to know if its the loading of the bush trip that's affecting FSUIPC, or the final state after loading.

As I said, as I'm not sure how to enumerate available lvars (or hvars) I am leaving this for now and adding them via user-added (or installer) files. Basically I've gone down this route for the initial implementation as I don't yet know how to get a list of available lvars or hvars. There are lists already published for some aircraft models (SPAD.next and MobiFlight I think), but only for some a/c models. Maybe we can request a list of lvars (and hvars) available for each aircraft from Asobo? Or rely on mod developers to publish these. Anyway, as I said, I'm not sure how this can be done in a reliable way at the moment, so I'm leaving this to the user (to provide the files) and FSUIPC will use whats provided. Once I've got the lvar functionality working, I will look into a more user-friendly way of building the lvar/hvar lists. John

What aircraft are you using? I just assigned a button to F7 (default Flaps Increment assignment in MSFS) and it works as expected in the C172. Anyway, rather than assigning to a keypress, why don't you assign directly to the flaps decrement/increment controls? Otherwise, could you activate logging for Buttons & Switches and Events, load your aircraft and press the button that you have assigned to the F7 key. Also, press the F7 key to see what that logs, and then close MSFS and show me your FSUIPC7.log and FSUIPC7.ini files.