John Dowson

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.

I'll post when the beta is ready to test. I won't be posting any progress updates until the beta is ready. The current implementation I am working on is file based, so you will have to supply text files containing the names of the lvars (and hvars) that you want to use. The files will be loaded/unloaded when the aircraft changes, and it will load files on a substring match with the filename to the aircraft name. So, for example, A320.lvar will be loaded for the A320 (or A320.1.lvar and A320.2.lvar, etc) and Boing 747.lvar for the 747, etc. I will also allow for one file (all.lvar) to be loaded for all aircraft, although I'm not sure how useful this will be. I will also provide access to execute hvars as well. These will also be loaded by files, so need to be pre-known. Also, as hvars are activated as calculator code, I could also generalise this to execute any provided calculator code. On the FSUIPC side, I will try to preserve existing lvar functionality for the initial release. However, it will no longer be possible to create lvars (using the ':::' notation). As I will be maintaining a list of current lvar names/values in FSUIPC, I could also expand the lvar functionality in future releases to include controls for setting/incrementing/decrementing lvars directly from assignments, as well as new controls to list and activate hvars. There are already various lists of available lvars and hvars for various aircraft, although mainly it seems for the A320. I think it would be good if I could collect such lists and then I can include them in the installer. I think it should be possible to determine the available lvars and hvars diretly from the WASM module itself, although I'm not 100% sure. I think SPAD provide scripts that you can run (with the aircraft loaded) that produces lists of lvars and hvars. I will look into this further at some point, or if anyone is using these maybe they can point me in the right direction? John

If there's an FSUIPC6.log and .ini file there, it must have been ran at some point. Yes, I would remove them, but they shouldn't cause an issue unless that dll is loaded before the one in your main installation. If P3D tries to load a second dll, you will get an error an it won't load. Not sure how you ended up with two installations, unless one is from a very early version when the installer didn't have the uninstall capabilities... Note that, from your log files, FSUIPC6 is installed in the following folder: D:\Users\liamp\Documents\Prepar3D v5 Add-ons\ That is the default installation location, and is where the add-on.xml file has to go. You should really install in a different folder (e.g. c:\FSUIPC6 or c:\P3D Add-ons\FSUIPC6). Note that you can always determine the installation folder of the current running version by using the Open Folder button in the logging tab. So, to clean things up a bit, you should manually remove the second (unused) installation, then re-run the installer and install FSUIPC6 in a different location, outside of your documents folder and preferably outside of the P3D main folder (and not in a windows Programs folder!). Then you will need to copy across any lua, macro, dll, etc files that you use, as well as your FSUIPC6.ini file, to the new location. But your problem with the mouse action failure will remain.

The bush trips especially seem to provoke these CTDs. Again we are waiting for Asobo to address this. The load/save functions provided by the SimConnect API are still not working. This will hopefully be addressed in a future SDK release. Thanks! Although I'm sure its Pete that deserves most of the credit! John

Yes, as the problem is on their side. FSUIPC7 is a separate application and communicates to MSFS using the SimConnect SDK, provided by Asobo. If MSFS is crashing due to a 3rd part app, its a problem with the SDK and so should be reported to Asobo. There is currently a known issue with the simconnect sdk that can cause MSFS to CTD, which seems to arise when simconnect is under load or being used heavily or for long periods. This is why I suggest trying to start FSUIPC7 after the leg has loaded, to see if that improves things. John

No idea, sorry. Is FS9 the same as FS2004, i.e. using FSUIPC3? Way before my time I'm afraid (and certainly no longer supported!). You need to either run it and take a look, or check the documentation for FSUIPC3 if any exists...

All CTDs should be reported to Asobo via zendesk, including any event informtation from the Windows event logs and any crash dumps. Are you saving/loading the legs using MSFS? I presume so as flight load/save is currently not working via FSUIPC dur to issues with the underlying SimConnect functions. What happens if you start FSUIPC7 after the leg has loaded?

Yes, you can do that manually by editing the ini. If its calibrated, also copy across the calibration entry, or re-calibrate the added axis for that profile. But for any given profile, its probably quicker to just add it again via the assignments panel. Or just initially add your axis assignments to the general profile, and then import and modify as needed for each profile. Note also that you can create a new profile based upon an existing profile, which will then import the axes from that profile.

Its completely up to you how you define your general and profile specific axis. Just remember, that when you create a new axis profile, you can import the general axis section if you so wish. Thats all. Yes. The usual way of doing things is to set up your axis and buttons for the aircraft you most use in the general section (i.e. no profile). Then, for aircraft where the general settings don't always apply, you can create a new profile, import the axes assignments and then modify from there. John