John Dowson

This is not correct. Multi-line lvar macros have the following format (from p39 of Advanced User Guide): So lvar macros can only operate on one lvar. However, you can overload your assignments by editing the ini file. So you would assign one button to one macro, then identify the line in your in. It will be something like: 9=PT,10,CM4:1,1 -{Macro MU2_Start: L:C441_STARTER1 set}- (although the numbers and button letters will of course be different) To overload your button, you can copy and edit this line, so I would add 10=PT,10,CM4:2,1 -{Macro MU2_Start: L:C441_STARTER2 set}- (where '10' is the next free assignment index number, and 1 changed to 2 to activate the 2nd macro entry in the file). Then, when pressing the button. both macros would be triggered. Note however, when you overload a button press by editing the ini, when you go back to the FSUIPC assignments panel, you will see the controls greyed-out (which indicates an overloaded assignment). Sorry, can't help you with this. Maybe someone else who has this aircraft can help, otherwise try asking on the forum/support for the aircraft. John

Hi David, Macro files, as well as lua files, etc, all go in the FSUIPC6 installation folder. This is the folder you select during the installation process, regardless of whether you use the 'add-on.xml' or not. If you use the 'add-on.xm' install method, then this (i.e. the add-on.xml file itself) will necessarily be created under <your account>\Documents\Prepar3d v5 Add-ons\FSUIPC6 folder, but this is not necessarily the installation folder. This will be the default installation folder for new installations, but it is recommended to change this so the installation folder is distinct from the 'add-on.xml' folder. For existing installations (i.e. when re-installing) , the default installation folder will be the folder that in which you previously had installed FSUIPC6 (or FSUIPC5). In ALL cases, if you don't know where your installation folder is, then you can use the 'Open Folder' button in FSUIPC's Logging tab, which will open Windows Explorer on your installation folder. As I said, people seem to be confused as the installation folder and add-on.xml folder are not necessarily the same, but usually are as the defaults are accepted blindly - and no one bothers to read the Installation guide! John

Hi Tasso, note also that you can also use 'reserved' areas for custom offsets if you are not using the feature they are reserved for. So, for example, if you aren't using Project Magenta, you can use the area starting from 04E0 (88 bytes), if you are not using PMDG aircraft you can use starting from 0x6420 (512 bytes), etc. John

Note also that you can use the IgnoreThese ini parameter (in the [Buttons] section) if its causing issues:

Hi Keith, Check your FSUIPC7.ini file. The [JoyNames] section should contain a list of your devices with both the JoyID number and letter assigned ('M' will be the letter assigned to the device). Then it wasn't pressed or MSFS wasn't running (or FSUIPC7 not connected). However, if you have button logging active when in the buttons & switches assignment panel, you should see a log message like this: In that line, the 1 indicates the joystick id, and the 8 the button number.

But also test with 50% or 75%. If this is graphics only and not affecting the model, then you should either see no change (i.e. <100% = 0) as we suspect, or (maybe) still see the same as if it was 100%.

That's just the graphics/visuals, not the model. I suspect that the model value would still be 0 (as Thomas says) when the graphics show < 100%. Do you notice any affect when you have, say, 50% carb heat? And if so, is this any different from 100%?

It may be possible in an actual Cessna, but as Thomas has stated: MSFS doesn't support for CarbHeat any other than ON or OFF (1 or 0). To support a carb heat axis or values other than on/off, MSFS need to implement this. You therefore need to raise a new feature request with Asobo/MSFS.

Maybe you could also show me your add-on.cfg file, located under <your account>\AppData\Roaming\Lockheed Martin\Prepar3D v5. The P3D auto-discovery should pick-up the FSUIPC add-on.xml file and update this file accordingly.

Hi Mario, ok, glad its working via the dll.xml install method. Do you have any other add-ons installed? I can only think that there must be some sort of ordering issue during the loading of the dlls. You could try (temporarily) switching back top the add-on.xml install method (just re-run the installer). If you could activate SimConnect logging, as shown in this post: Then start P3D, and show me the SimConnect log file produced. Thanks, John P.S. Also, when you re-install via add-on.xml method, please choose an installation folder outside of both your Documents folder (especially if using OneDrive) ) and your P3Dv5 installation.

Can you also check if you have any ant-virus software running that is maybe preventing the dll from being loaded? Let me know how it goes when you install using the other (i.e. dll.xml) install method. I don't think activating SimConnect logging would help at the moment.

Its always installed as an add-on. However, there are two install methods - add-on.xml (the default) and via the dll.xml. To use the second method, just re-run the installer and de-select the 'add-on.xml' checkbox when choosing the items to install. I'll let you know shortly...

Ok, then FSUIPC isn't even starting. You could try this. But I would like to know why its not loading it via the add-on.xml method. I''ll need to see your P3Dv5 loading logs...I'll get back to you on this.

Do you have an FSUIPC6.log file (in your installation folder: C:\Users\Admin\Documents\Prepar3D v5 Add-ons\FSUIPC6)? If so, can you please show me that. No. Its the same version, you just get a discount as you have already purchased a license for FSUIPC5. That's your installation log which just shows a successful install. You could also try re-installing the P3Dv5 client - no need to uninstall or re-install FSUIPC6. John

There are no standard offsets for COM3 active/standby, but check the PMDG 777 SDK documentation to see if they hold the information there.

Hi David, I'm not sure about cutout at 60%, but there are a few things you could try before resorting to lua. Your mouse macro is I guess something like this: <n>=<name>=RX<id>, 3 Where '3' is a mouse left click. You can try duplicating this macro, giving it a unique number and name, the same <id> but using '13' for a mouse left release. You can then assign this new macro to the button release on the same button as the press for the original macro. This would then send the mouse click release when you release the button. Worth a try. You could also try a both actions (i.e. press and release) in the same macro, but there may be an issue with the timing if this is done, but also worth a try. ,If the 'cutout' is automatic in the sim when you give a single mouse button press/release, then it should work if you do the same via a mouse macro (so maybe just try this first!). There's no point in looking at lua if you don't actually know what to send to tell it to 'cutout'. Also, check that you haven't set repeat on for the button. By the way, have you tried logging events to see if any known events (or controls) are used when you start? If so, it may be better to use these instead. Otherwise, maybe the aircraft provides some lvars for this - there is a control (or lua script) you can use to log these. John

It shouldn't matter what the sim is set to, the values sent by FSUIPC should be used directly. Some folks have achieved better sensitivity by manually editing the ini to extend the value range of the axis. However, this does mean that the axis can no longer send the full value range, but would also give you more control. To do this, you need to manually edit the ini and change the high/low value. So, for example, this is my elevator calibration setting: Elevator=-16384,-400,400,16383 So changing to something like Elevator=-20384,-400,400,20383 Would increase the 'expected' range, and so reduce the sensitivity, especially when using slopes. You could try this technique (with different values) to see if this improves things.

Yes, it seems to return all airports except those that are closest to you! Yes, it seems that the latest release introduced this bug - but the release note stated that this functionality had been fixed! I'll report to Asobo.

This functionality is still in FSUIPC7. However, its currently not working now FSUIPC7 is an exe (rather than an embedded DLL). The problem is that FSUIPC7 does not receive a QUIT message, so is not notified when MSFS exits and so cannot initiate a save. I think the lack of a QUIT message has already been reported to Asobo, but I'll check. However, I doubt this will be possible now FSUIPC7 is an exe, as it would mean that MSFS would have to wait for all external clients to exit correctly before closing down.

Just checked the list received from MSFS and it seems to contain each airport around 30 times! This is why its finding the same airport 6 times as the closest 6. Could you try adding the logging I mentioned in the previous post to see if you also get the same airport 6 times - if so, I'll report to Asobo and see if I can add a temporary fix to ignore the duplicates.

Sounds like an issue with MSFS not updating the GENERAL ENG COMBUSTION variable when the engine is shut down. I'll check this (tomorrow) and raise a zendesk ticket with Asobo if this is the case. I'll let you know.

FSUIPC receives a list of all airports in the aircrafts "reality bubble" from MSFS, then calculates the distance of each from the aircraft, and then populates 0x0658 with the nearest 6 airports. FSUIPC uses the SimConnect function Simconnect_RequestFacilitiesList to get the list of airports. This has recently been stated as being "fixed" in the latest MSFS release (1.9.5.0), however the SDK documentation for this function still lists this as 'bad response' and 'all facilities lists are empty', so I'm still not 100% sure this is fully working yet. I've just taken a quick look and there seems to be various issues. I am getting plenty of airports through from SimConnect (36974 in total!), but many don't seem quite right (e.g. invalid ICAOs). Also, it seems that FSUIPC7 is only determining the closest one, and then repeating this 6 times in offset 0x0658. To check the full list in that offset, you can go to Log->Custom, and enter x20. You should then see the complete list of the 6 nearest airports (in your log). Not sure what's going on yet, I'll look into this more tomorrow. But, the offset should contain the 6 closest airfield (as determined by FSUIPC) from the list of airports in the aircrafts reality bubble as received from MSFS. John

Yes, this was added in the September 14th release. However, there are still various issues: - not all keys are recognised. See the SDK documentation (SimConnect -> Status of Input Events) to see which keys are currently supported - FSUIPC only receives the numpad keys when numlock is off, rather than when numlock is on. This has been reported to Asobo. I have also added a new ini parameter UseAlternativeNumpadKeyMapping : (from ) Of course, you can always activate logging for 'keys & buttons' to see which keys are recognized from MSFS/SimConnect.

Hi @pilotjohn Those last logs are pretty interesting, thanks. Getting closer to the issue... I wouldn't bother with this now - remove if you have added (although it won't make much difference). Please try the following build, and keep logging of extras active: FSUIPC7.exe Let me know how it goes with that version, and post your FSUIPC7.log again if you get a crash. No need for the SimConnect logs for now. Thanks, John

Yes, I'm currently updatimg the User manuals and they should be ready shortly. For the time being, most of the information in the FSUIPC5/6 manuals is still relevant, so if you are new to FSUIPC you can use these - see I will be releasing an installer for FSUIPC7 shortly (i.e. next 3-4 days) that will include the documentation (although not all updated). Its best to just try them and see what works for you. Flattening in the centre is usually the way most people prefer. Depends on the settings. By default, FSUIPC7 exits with the sim, so you have to restart when you start the sim. To change this, you can turn off the option Exit with FS, and then FSUIPC7 will just sit in the system tray rather than exiting. Of course, the ideal solution is for FSUIPC7 to start automatically with the sim, but this is currently not possible with MSFS. John