John Dowson

Not pedantic at all, more like a bug - I will look into this and update in the next release. looks like I'm trimming before removing comments, when it should be after... John

I have no knowledge on x-plane, but for smooth braking on a button in FSUIPC, regardless of version, see the following: John

This is way before my time, but I think that it is obvious that you cannot use a cfg file from 2004 in 2020.... Also changing from FSUIPC3 (FS2004) to FSUIPC7 (MSFS2020) is not an easy transition.. . That is basically 20 years apart, you cannot expect things to work the same way after so many years. I suggest you upgrade and just try things. There is a trial license for FSUIPC7 available in a post pinned to the top of this sub-forum if you would like to try it. John

Yes. and this issue has been known for a long time. There is already a thread on this in the Asobo forums...

When you get a lua error, the line number is given - just remember to check the previous line as well as the one given, as the error may be there (or even before!).

On line 14 (and 18) you have ipc.exit when it should be ipc.exit() It is a function and you are missing the brackets, so it is being interpreted as a variable, and thereofore an assignment is expected, hence the error (i,e, as its a variable, it needs to be followed by an '=' sign, but it is followed by 'else' instead).

I am not 100% sure, and it may depend on how you are sending this data, but I don't think FSUIPC will send any controls when the in-menu/dialog flag is set (offset 0x3365) and/or the ready-to-fly indicator (offset 0x3364) is non-zero. I don't think the CTD will be related to this, but there is no harm in trying - but maybe use offset 0x3364 together with 0x3365. Maybe also easier to use FSUIPC's offset logging facilities to log the values of these offsets (instead of FS-Interrogate), and if you also log events you can see when these are being sent (ir received) and what the values of those offsets hold at the time. John

This is interesting and explains why some key events sent via external apps (i.e. sent using the MSFS SimConnect SDK) sometimes don't work whereas the same (or similar) event assigned in MSFS do. However, FSUIPC know nothing about this key event mapping - it just sends the key event to MSFS using the MSFS-provided SimConnect SDK. It is therefore an issue with the SDK that events sent using this do not go through the same path as the ones sent internally. There are two ways to get around this. 1. use the Input Event directly. Direct access to Input Events was recently added to the SDK and Input Events are available for use (via assignments, offsets or lua) in FSUIPC7 since version 7.4.0. You can also list the available Input Events for the current loaded aircraft using the Log -> List Input Events menu option. Note that not all B:vars (which are the Input Events) may yet be exposed by the Input Events interface. MSFS have indicated that they intend to make all available, but this may not be the case. If the Input Event isn't available, then you will have to use the 2nd method, as it is not possible to control B:vars via calculator code (i.e. using a preset) for some reason... 2. If no Input Event is available/exposed to control the B:var, the only way to control/assign to this externally is by hacking the xml code. The idea here is to introduce an lvar whuch is checked in an update component (on a timer) and used to set the B:var. This is explained in various posts here, and also in the description of some HubHop presets, e.g. TBM930_BLEED_AIR_OFF. Also see https://forum.simflight.com/topic/97903-cockspur-mustang-c510-starter-and-ignition-was-fsuipc7-wasm-submenu-shows-disable-only/?do=findComment&comment=589316 John

As I said before, there is no access to B-vars directly - you have to hack the xml files to add an lvar (and timer) to control a B:var - I have showed how to do this in other posts, and there are also examples on the MF Hub-Hop site (e.g. see the details for the preset TBM930_BLEED_AIR_AUTO). Even calculator code cannot be used to trigger a B:var directly (although I have seen some AAOs snippets that try to do this....) However, there seems to be a close relationship between B:vars and Input Events - in fact, B:vars ARE Input Events (see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm) - but maybe not all B:vars are available as actual Input Events (or via the Input Event interface). So, I prefer to use the term Input Events rather than B:vars, which you can access via the GUI for assignments, via offsets, and also via Lua. So any FSUIPC client can access them via offset 0x7C50. Please note that the prefix FSUIPC uses for Input Events is 'I:' and not 'B:'. For the actual B:vars themselves, there is not and never will be any direct access (e.g. via calc. code) as far as I am aware, and you will only ever be able to use these via the corresponding Input Events interface. I have also read somewhere (in the Asobo forums) that future MSFS releases will provided access to more B:vars via the Input Event interface, with the aim to provide access to all - at which point the distinction becomes irrelevant! All a bit confusing really....

Thanks @AirPanther. However, note that @Brahms is using FSUIPC7 so the offset for APU_EGTNeedle is 0x64E8 (still a FLT32, 4-bytes) - the PMDG offsets in FSUIPC7 are not exactly the same as in earlier versions. I did check the 'Offset Mapping for PMDG 737-700' pdf document but missed this somehow... I will move this topic to the FSUIPC7 sub-forum where it belongs. Cheers, John

Even less to worry about if using a helicopter, as no aileron trim!

Try asking about this on the Horizon Simulations discord channel...

I wouldn't worry about it if it was a one-off and isn't causing any issues.

Are you using an MS Store or Steam installation? In Steam, you can disable Steam Cloud completely, or on a game-by-game basis. I have this disabled in my steam account: There is probably something similar for MS Store installations, but you need to check. What does this mean? John

What do you mean by 'flashing issue'? Can you please explain what this is. Do you still enter/leave full screen mode? Alt+Enter is an MSFS hot-key and I can't see how FSUIPC can be involved. If you exit FSUIPC7 and use Alt+Enter, do you see the same?

Offset 0x2EA0 uses ELEVATOR TRIM POSITION, and is an 8-byte floating point number (FLT64), and is the deflection in radians. Offset 0x0BC0 uses ELEVATOR TRIM PCT, and is a 2-byte integer (S16). You can use either, depending on the units you want to use, Usually you would use 0x0BC0, as this uses a standard axis range (-16383 to + 16383), but you can also use 0x2EA0 if you want to use radians. Just different ways to skin a cat, as you say... although my wife would be very annoyed if/when I use that phrase....! But, as always with MSFS2020, things are not that simple. You may find some aircraft that use/respect one of these simvars but not the other. In such cases, use the one that works, However, I can't think of an aircraft that does this off-hand, but I think there are some that use/respect neither, and are controlled by lvars, input events (aka b-vars) or more complex calculator code (usually implemented via a preset). But you need to look at this on an individual or aircraft basis, and only when standard controls or offsets do not work as expected. John

No apologies necessary!

Ok. Are you using the same FSUIPC6 installation for both P3Dv4 and P3Dv5, or do you use two separate installations, one for each?

The first and second windows calibrate the AXIS_THROTTLE_SET, AXIS_PROPELLER_SET and AXIS_MIXTURE_SET controls, whereas those on pages 3,4,5 calibrate the individual axis controls AXIS_THROTTLEn_SET, AXIS_PROPELLERn_SET, AXIS_MIXTURn_SET. If the aircraft supports the use of both controls, you can assign to either and calibrate in the appropriate section. Some aircraft allow the use of both, but others may only respond to one. The calibration for individual engine controls provide more functionality (ie. w.r.t reverse range) if needed. The THROTTLEn_SET, PROP_PITCHn_SET and MIXTUREn_SET controls are the older controls, and FSUIPC excludes these from calibration by defaultm but you can allow calibration on these controls by unchecking this box. I am not sure why it is like this - it will be for historic reasons way before my time...I would just leave these as is, and not use those controls, unless absolutely needed. MIXTURE_SET is automatically mapped to AXIS_MIXTURE_SET, and PROP_PITCH_SET is mapped to AXIS_PROPELLER_SET (see page 44 of User guide), so no need to exclude these. Not sure about THROTTLE_SET though, as that isn't documented. Not sure if this is mapped or calibrated or not (on page 1) without checking further.... These are just the ini parameters that store the state of the check boxes you mentioned in your last question. They will only have an effect if/when assigned to the older THROTTLEn_SET, PROP_PITCHn_SET and MIXTUREn_SET controls. John

FSUIPC4 only detects a maximum of 32 buttons (0-31) natively in the button assignment panel. To use buttons 32-34, you need to use a lua script to convert these buttons to virtual buttons. Scripts for both the Alpha and Bravo, together with instructions on use, are available here: John

Hmm, strange. The splash-screen size/position is controlled by the following in the MSFS.bat file (under your FSUIPC7 installation folder), and should be sized/positioned to your screen size: if (w == 0) w = screen.width / 2; if (h == 0) h = screen.height / 2; window.resizeTo(w, h); window.moveTo(screen.width / 2 - w / 2, screen.height / 2 - h / 2); You could try manually setting a size instead, on lines 15 and 16 of the same file: Or maybe the image is being cropped to that size rather than reduced, I will take a look when I have more time.... You could also move the text further to the left, by changing this on line 73 (e.g. try 50%😞 left: 55%; John

Ok, great! Ok, so that makes sense (i.e. no assignments). Ah, ok - I wasn't sure which of your throttles the assignments were using. Seems like you have no assignments to L (Throttle - HOTAS Warthog) then. For future reference, you could have switched these by just switching around the L/M letters in the [JoyNames] section, rather than changing the letter in each assignment. Anyway, your files look good - glad its all now working again! Cheers, John

But what is loading that dll and what is giving that message? It is not FSUIPC. I can only help with FSUIPC. And there is no point responding without answering the questions I have, especially when I have no idea what you are talking about.. Please respond to my questions if you want assistance with this. John

Btw, I haven't changed anything yet for your 'VPC Panel #1' devices (2 of them) or your 'Landing Gear Lever' - do you have any assignments to these, and if so what (i.e. which letter or id were they using)? FYI, I mapped the devices as: D & G: rudders A & F: yokes C & K: tillers L: throttle B & H: stick If any if that looks incorrect, let me know.

Can you try with the following ini. Using this, start FSUIPC7 and check each device, and let me know any devices not recognised, and the device number/letter of any device without its correct assignments. Also attach all 3 files again please. FSUIPC7.ini