John Dowson

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

@bertranda ok, thanks for the update.

No, there are many buttons on the G1000 that are not working and/or currently unassignable. This has already been reported to Asobo.

But the largest gap in the logged elevator axis values only seems to be around 9 seconds, with most of them being a lot smaller (2-5s):

Hi Keith, those controls have not been exposed via SimConnect. Please see John

Your ID number is pid_b108, and your VID number is vid_044f. Did you find (and remove) anything in the registry under those strings? It is strange that the Windows Game Controllers indicates it is working correctly. Did you try to re-calibrate anyway? If this is a problem with all aircraft in both sims, it does sound like a registry or device driver issue.

Well, the log shows the movements as described - to full forward then straight to (near) full reverse, with no in-between values.... What do you see in the in/out boxes in the axes assignments tab for your throttle axis? I ask as it looks like your throttle is no longer sending the full axis range values. Can you also check that axis in windows game controllers? It may be that your axes has been switched to digital input somehow in the registry - see the following (even though your device isn't a Saitek one):

Check your USB power management settings. Well, first you should not need to reconnect, so best to solve that problem. However, FSUIPC should rescan the axis when you reconnect. The next time this happens, please show me your FSUIPC7.log file, together with your FSUIPC7.ini. Also, make sure you are using the JoyLetters facility if re-connecting USB devices. There was a new ini parameter AxisScanOnSimConnectOpen added in the October 6th build. However, I'm not sure this would help in your case, as it sounds like its not related to when opening SimConnect, but you could try this anyway.

Btw, for the A320, you can assign the throttle (to the THROTTLEn_SET controls) to the full axes range with no reverse zone. You can then assign a button (or key) to the Throttle Reverse Thrust Toggle control. Then, activating this control (when aircraft is on the ground) will allow the full throttle axis range to control reverse thrust. Toggling this control again will switch between reverse and forward thrust.

Those ines I highlighted are incorrect. To comment out lines in the ini file, use a semi-colon ';'. Please correct that, although I don't think this will fix your issue. Can you try with that original ini (with the above corrected), activate Axes Controls logging, load up the Neo and move your throttle through its full range, from idle to full and back again to idle (or into reverse, if you are using reverse zones). Than show me your log and tell me how you saw the throttle move in the UI.

You seem to have an extra folder in your path (FSUIPC4.975) - that bold text should be (at a guess): C:\Documents and Settings\hhm\Mis documentos\MiInet\Steam\steam\steamapps\common\FSX\Modules\FSUIPC4.dll So maybe you have specified the wrong path in the DLL.xml?