John Dowson

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!

Why should it be? That just lust the controls available. Did you add the MobiFlight events by dropping the event files into your FSUIPC7 installation folder? Once you do that, you should see the MobiFlight events at the top of the controls drop-down menu. Currently you can only use the MobiFlight events, not the hvars, as I said.

Sorry, but what does this mean?

FSUIPC only recognises HID joystick type devices. If its another HID type device, you will need to use lua. There is a demo script provided in the lua axamples zip called HidDemo.lua. You can try that - you need to edit it to provide the VID and PID of your arduino, place it in you FSUIPC installation folder and have it auto-started from your ini's [Auto] section.

Just replace your current FSUIPC7.exe withthe new one, and it will pick-up the same FSUIPC7.key file that the previous version used. If you are running it from a different folder, then you need to copy across your FSUIPC7.key and FSUIPC7.ini file (+ any other files you may use) to the new installation folder (i.e. where you run FSUIPC7 from). Its easier just to replace your existing FSUIPC7.exe with the new one downloaded.

No idea what you mean by that, or if its even related to FSUIPC, sorry.

I am working on a WASM module for lvar and hvar access at the moment. I'm hoping to have a beta out in a couple of weeks, but it depends on how much time I have free to work on this. Support is currently taking up a lot of time, which doesn't leave me much time for new development... No idea about mouse macros at the moment. I'm not sure if the facilities are available yet, but I'll start looking at this one the lvar/hvar functionality has been released. John

As I said, you can't use them (i.e. hvars) yet (as far as I am aware). You can use the MobiFlight events though - check them to see if there is anything there that you can use. Installing the MobiFlight WASM is pretty straightforward. You have to download the MobiFlight connector app and install from there. There are instructions somewhere over on the Asobo forums. Once you have installed the WASM module (into your MSFS Community folder), you will need to download the MobiFlight event files and add them to your FSUIPC7 installation folder. Note that there is currently a bug in the released version of FSUIPC7, v7.0.4, where only one event file is recognised. There is a beta version in the thread I posted where this is fixed - you need to download and use that if using more than one event file. John

As I said in my previous post, it seems that the FBW mods are using lvars for this, so you will have to wait for lvar access, which I'm currently working on (when support doesn't get in the way!), John