John Dowson

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

You need to understand how profiles work w.r.t. axes assignments vs button assignments. For button assignments, general assignments are always loaded, even when using a profile, and then the profile-specific button assignments are loaded, replacing any assignments that are in the general profile. For axis assignments, if a profile axes section is present then only the profile axies are loaded. This is why, when you first create an axes profile, it asks if you want to import the general axes section. Once a profile has been selected for the axes for an aircraft, all axis assignments for that aircraft will be profile specific. You cannot add a general axis assignment when an aircraft is loaded that has profile-specific axes assignments. If you want to add a general axis, you would have to load an aircraft that has no profile axis assignments. For buttons, you can select or deselect the profile, depending upon where you want the button assignment to go. There are still many MSFS controls that work only when assigned in MSFS and have no affect when assigned in a simconnect client, such as FSUIPC. This is a known issue, and affects many controls/events, including the view and slew controls. For now, you either have to assign these directly in MSFS, or assign to keypresses in MSFS, and then assign your buttons/POVto those keypresses in FSUIPC. John

Its John. not Pete... As I said, how are you reading these values? Offset 088C is a 2 byte signed integer, and can therefore only hold values from -32768 to +32767. If you are seeing numbers larger than this, you are reading it as an unsigned 2 byte integer which has a range of 0-65535. You can verify this by logging the offset as both an S16 and an U16 using FSUIPC's offset logging.

How are you setting this value? What FS and version of FSUIPC are you using? And how are you reading the value? The maximum value of a 2byte signed integer is 32767 it looks like you are reading it wrong, maybe as an unsigned integer? The maximum value held in this offset should be +16384 (as described in the documentation).

Your log shows that the mouse action failed for those mouse macros: This must either be due to the mouse rectangle being invalid, or a problem with the FSLabs a/c. Can you redo the macros that are failing. Maybe just create a separate new macro file for those that are failing and verify that the rectangle ids are the same. If not, update your existing script with the correct rectangle ids. If the rectangle ids are correct, you need to contact FSLabs support to determine why they are returning an error.

You log file shows that you were not connected to MSFS. You need to have MSFS running and be connected before lua files are auto-ran. You do have a HidDemo.log file, but that must have been generated on a different run. So, please try again and make sure that you have MSFS running and always better to assign/calibrate with an aircraft loaded. Also, try the attached HidDemo.lua. In this script (based on the Alpha script) only buttons 32-64 are made accessible by virtual buttons, and the others (0-31) are still available in the usual manner. This saves some virtual buttons (for other uses) and prevents multiple buttons (teal and virtual) being seen at the same time. On the button assignments panel, when you press the button you will see the joystick letter (C for your throttle) and the button number if < 32. For the buttons > 32 asigned to virtual buttons, you should see a joystick number of 64, and button numbers starting from 0. John hidDemo.lua

The FSUIPC7.ini file is created the first time you run the application, if not already present. You can check the installation location by using the File -> Open Installation Folder... menu option. If you can't see the extensions, then thats due to your windows explorer settings. See the Addemdum in the Installation and Registration guide to fix this (last page).

If the events are being sent then you should be ok. Have you installed the MobiFlight WASM module into your Community folder? That's the module that handles the events on the FS side.

Ok, but it would be useful if you could explain how to help others who may have the same issue. No problem!