John Dowson

Sorry, but I cannot help with other products that use FSUIPC7. You need to talk to LINDA, ACARS and SLC support for this. There is an issue with the pause state indicator in that build, due to changes in the 1.9.3.0 release of MSFS. I'm not sure if that would affect LINDA and ACARS, but you can try the following build where this issue has been corrected: FSUIPC7.exe

There is no way to disable controllers in MSFS. You can create a new 'empty' profile (all new profiles are created empty) and use that.

@IanAbel Could you try the attached version where it should be working again. Offset 0x3365 should now also correctly reflect when the sim is in the menus: FSUIPC7.exe

Can you try the attached version, in which offset 0x3365 should contain 1 when in the menus and 0 when in game. You may also want to read in conjunction with offset 0x0264, the pause indicator. I say this as the in-menu flag gets reset as soon as you go into the game, but this takes quite a while (up to a minute) and the sim is set to a pause state just before the in-menu flag is cleared and then unpaused when the 'READY TO FLY' state is reached. FSUIPC7.exe

Its not possible to do this reliably at the moment unfortunately. We are awaiting SDK updates to do this reliably. Thomas has pointed out that you can determine the menu/in-game status by looking at the Filename events. I'll look into this today and see if I can get offset 0x3365 correctly reflecting this status. You could check the stall warning flag at offset 0x036C.

Yes. Each time you start a lua function, it will be compiled and ran. This its why it is better, for many use-case scenarios, to have a lua pre-compiled and running (from the [Auto] ini section). and then waiting on events to activate.

Its not possible to do this reliably at the moment unfortunately. We are awaiting SDK updates to do this reliably. Not sure about "landing" weight. There is a sim variable for Max Gross Weight if thats what you are looking for, which is in offset 0x1334. I'll look into adding these to the offset area. I'll let you know when done. John

Ok, thanks for the update.

I guess its a false positive. I've just downloaded and tried it and its fine here, so download and try again.

Hi Keith, unfortunately the only event for batteries listed in the SDK/SimConnect is the Toggle Master Battery event. There is also a simvar ELECTRICAL MASTER BATTERY that you can use, via offsets 0x281C and 0x3102, but there are no individual events or variables for battery1 and battery2. That is strange! But I presume this is just a parameter to the toggle event, no? Nothing to do with offsets. Toggle controls are usually just that - a toggle control with no parameters. So does sending this control with no parameters (or a parameter of 0) toggle all batteries, and if you give a parameter (1-4) then it just toggles that battery? You can also give a parameter to the control in the assignments panel to test this. I'll take a look at this in more detail when I get a chance.

In FSUIPC7? When does the crash occur? Can you show me your FSUIPC7.log file please, and also check the windows event viewer to see if there is a crash report there, and if so please paste the contents.

@IanAbel I'll look into this tomorrow. This was working in the previous release, so looks like something must have changed in the recent update.

Sorry, what do you mean? FSUIPC7 is for MSFS only, and is being continually updated. See I add a comment to that topic when an update to FSUIPC7 has been released.

Different aircraft seem to be logging different events continually, and it seems to be getting worse with each successive release. There is an ini parameter that you can add to the [General] section of the ini to ignore these: As it seems that different aircraft log various different controls for no apparent reason, its probably worth making this ini parameter profile specific. I'll add this to my list to look into when time permits.

I will, but that was Pete asking!

Btw, for setting up reverse in MSFS, there is also a new control called 'Throttle Reverse Thrust Toggle'. This allows you to use your full throttle axis for reverse (when a set-up with no reverse range) when on the ground. For details, see May be useful or not, depending upon the aircraft and how you wish to use your throttle.

What do you mean by 'answer 14'? Why don't you just follow the instructions in that thread? What is 'DT'? What aircraft are you using? What is your actual problem? For throttle calibration, and axes calibration in general, you should review the section entitled THE EASY STEP-by-STEP WAY TO CALIBRATE YOUR CONTROLS in the FSUIPC User Guide.

First you can try activating event logging, to see if there is an event registered when you press the button in the UI. If so, you can try using that event. If no event is registered, then you can try mouse macros. There is no facility for timings in mouse macros. You would have to fire the macro on repeat for as long as the button/switch is held. This really depends on how the function is implemented in the aircraft/UI. As I don't have this aircraft, I cannot advise. Best to try it. Separate axis calibration (on the 4 throttles page) features reverse, centre, and forward ranges, so the reverse range should allow you to gradually increase reverse thrust. However, if there is a 'reverse' switch at the bottom of the thrust lever, its usual to program this to a throttle decrement (on repeat) when pressed, and a throttle cut when released. However, if you use this method then you don't really need a reverse range on your axis, so you should choose one method or the other really.

Yes, its a know issue with PMDG aircraft. There are many posts on this issue if you search. All FSUIPC does is call simconnect to save the flight, and you will get a similar pause when saving using the P3D facilities. You can try saving using the default key (';' I think) and you will see the same pause. There is no way around this, although some folks have reported improvements after updating firewall/anti-virus settings. Try searching (probably better in PMDG forums) for details, or try this: What some folks do with PMDG aircraft is to disable auto-save during take-off and landing. There was an additional control provided to allow this (i.e. toggle auto-save on/off when autosave activated). It can then be activated on, for example,. gear up/down, or a lua script could monitor height above ground and enable/disable as required.

Looks like I uploaded the wrong version, sorry - that version has a build date of 28/09 when it should be 30/09. Please try this one: FSUIPC7.exe Note that I have also released this version now, so its the latest official version.

Ok, good! If you do this, you can add to the User Contributions section. Cheers, John

But you requested 1 Byte at offset 66C0, so should be: BOOL = val; FSUIPC_Read(0x66C0, 1, &val, &result); Be aware that I've not used this myself, just going by what the documentation says!

Yes, you are 'doing it wrongly', as you are writing an uninitialised variable so the contents are undefined /garbage. You need to set the value (and type of 4 bytes, not a float64 which is 8 bytes!) of your test variable to contain an "unused" user offset vale (e.g. 66C0), together with the type. So, assuming your lvar is an 8-bit unsigned integer, you would need: int test = 0x766C0 and use that.

Good luck! Lots of reports of crashes with the new update, especially if using the VFR map. Note you can also disable 'Exit with FS' from the FSUIPC7 options menu. Then, if MSFS crashes, FSUIPC will remain open (and you will know that it is an MSFS crash and not related to FSUIPC7).

1. you need to write the value of the offset to 0D6C (together with the value type, as explained previously). You are writing an uninitialised value. 2. Your write of the lvar name is incorrect. As stated, it should be the the lvar name preceeded by a colon (':') for read 3. You are reading the result from 0D6C. This is incorrect. The result needs to be read from the offset that you wrote to the LOWORD of offset 0D6C in step 1. Please re-read the provided documentation.