John Dowson

The download link, as well as your license details, will be in your receipt email, and also available in your SimMarket account. You can download from fsuipc.com, or here : Its late now, but tomorrow I can PM you a license/key file if you cannot find your license details (but check your account!). Regards, John

Where is this from? From your simcars program? If so, try running without that. If its fine without that, it is the simcars program that is causing this issue, and you need to contact them for support. John

Your FSUIPC4.log file shows that FSUIPC4 exited as the sim had stopped, not crashed. Are you sure that that is a log file from when it crashed? All it shows is that FSUIPC exited after 1m49s, as FSX exited.

I have removed whatever that was you included at the end of your post. Please attach your FSUIPC4.log file, and also check the windows event viewer and post any crash information that you see there. Such crashes are usually due to a corrupt weather file, although I need to see your files and crash log to confirm. This type of crash has been reported hundreds of times, and the solution to first try is well known (delete your used wxstationlist.bin file, and possibly other weather files, and let that get rebuilt). Check other posts on this issue for further information. If that doesn't work, show me your FSUIPC4.log file and windows crash event information. John

The specified size/position for ext/wnd windows is only used the first time the window is created - the position/size is then stored in your FSUIPC ini file, under the [ExtWindow] section, and this overrides any position/size specified when the window is created. If you want the new size/position to be used, delete the entry for this window under [ExtWindow]. It is implemented this way so that users can move and resize any such window to their preferred position. You can move and resize such windows by using the arrow keys to move, and ctrl + arrow keys to resize, when the window has the focus. The new size/position is then remembered for the next session. So the size/position coordinates in the creation are only ever used the very first time the window is created. Hope that makes sense. John

Ok, that's good then. If you want to get the visual working, you would have to look at the code that is associated to the pull/push button operation (using the MSFS developer mode behaviors window) and see what is used to control the animation, Detailed instructions can be found here: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/. However, if this was easy to do (e.g. was using a h:var) then this would already be in the preset. I suspect it will be using a B-type variable, which are (currently) only controllable using a hack - for an example if this (controlling a b-var using a user-defined lvar), see

License sent.

Does it have the desired affect, i.e. switch between managed and selected mode? It could be that just the visuals are not working, Looking at the altitude push, it just decrements the value of the lvar L:S_FCU_ALTITUDE: (L:S_FCU_ALTITUDE) -- (>L:S_FCU_ALTITUDE) You could also try listing the lvar values to confirm that the code is being sent and is working, As I don't have the Fenix I cannot really help much further if FSUIPC is sending the code for the preset as it is defined. You can try the MobiFlight discord server, who drive the community effort for this - use the MSFS2020 channel.

Sorry - just back from a short holiday. Glad you solved your issue - yes, you need at least SP1. John

Can you try adding this to the [Buttons] section of your FSUIPC ini file: EliminateTransients=Yes This may be what you are looking for - from the Advanced User guide: Cheers, John

That is strange...I thought the issue with this CDU was that the buttons don't send a press and release, they alternate, as discussed here: Or maybe that is a different issue? Alternatively, if you are using mouse macros, please see the following post: If none of those apply to your problem, can you please show me your FSUIPC ini and log files, the latter with logging for Button & Key operations and Events (non-axis controls) activated and showing your issue. Why does your current method only work with the one aircraft? Cannot you use the same method for other aircraft also using LINDA? There is no way to do this unless you use lua scripts to control everything. But there are many FSUIPC users with this CDU and I have not heard of this sending multiple inputs before, so I would like to verify that this is actually the case and this is not caused by the other known issues with this device.

License sent.

Why don't you try reading the documentation....

Installing FSUIPC6 does not change P3D in any way - it just creates an add-on.xml file so that P3D can load the FSUIPC6.dll. If you do not allow this to be loaded (by clicking 'No') then FSUIPC6 is in no way involved in the CTD. And if you uninstall FSUIPC6, then it certainly isn't doing anything. and it will not have changed P3D in any way. It is therefore something else that is causing this. Check the windows events viewer to see what module is causing the crash, and try searching for this on the P3D support forums as well as on avsim. Also check your GC card driver to make sure this is up-to-date and when the last update was installed - you may need to revert to the previous release. ...and you shouldn't be manually editing the add-ons.cfg file, as that is controlled by P3D.. You can activate/de-activate add-ons from the P3D add-on management panel, if you wish to do this. You always have to manually allow add-on activation when a new add-on is picked-up via the add-on.xml method.

Looks like there may be a locking issue, which I will look at in a few days, when I get back home. However, your log shows that lvars are still being created after the intial lvars have been received. For complex aircraft, you need to allow more time. I suggest you increase the value of the WASM ini parameter LvarScanDelay - from the Advanced User manual: I suggest you start with a value of 10-12 (seconds) and increase if you still get issues - or increase the current value by 5-7s if you have already changed this. Also note that you should set this in the FSUIPC_WASM.ini file located in the WASM persistent storage location, not in the one under your Community folder as this will get overwritten (and therefore reset) the next time you update. See the WASM section in the Advanced User guide for details. John

Yes, of course - that is the whole point of profiles. You just set-up a different profile for each aircraft. See the provided documentation on using profiles. A profile is loaded automatically, based upon the aircraft name. Basically you just need to check the 'profile-specific' checkbox in the assignments panels. Note that general button & key assignments are inherited, if not overwritten, by profiles, but axis assignments are not.

I am not entirely sure what you mean when you say 'convert offsets into an axis'. Offsets can hold axis values, for both reading and writing. So, if you have a value in a (user-defined) offset that you want to use for an axis value, you can just write this value, possibly with some adjustment/calibration, to the offset that holds the axis value that you want to use it for, or, alternatively, use that value to send the appropriate axis control/event to the FS. Your post is confusing as I am not sure if it is steering or throttle you are trying to control. There are already many posts on motorized throttles, so maybe check them out. Otherwise I will be back at home in a couple of days and I can look into this further if you can provide more information and clarify what you are trying to achieve, Regards, John

Yes, it is possible using a lua script. You would need to monitor the brake position offsets (0x0BC4 & 0x0BC6) using event.offset, and then write/update your offset depending upon the value for each brake. John

Please read, or at least consult, the provided documentation before asking such questions - this is all explained in the documentation (WASM section in Advanced User guide). The events.txt file is installed (by default) and contains the MobiFlight presets (see https://hubhop.mobiflight.com/presets/). If you are defining your own presets, you should add them to the myevents.txt file. You can add them to the events.txt file, but this file will get updated/replaced when you re-install/update FSUIPC7 and you will lose them. I still don't understand what this means.... The GENERAL ENGINE STARTER ACTIVE (indexed) simvar is provided by the MSFS SDK and is NOT used to turn the starter buttons on/off, as it is read-only. It just tells you the state of these buttons. See https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_Engine_Variables.htm : GENERAL ENG STARTER ACTIVE:index True if the indexed engine (see note) starter is active. NOTE: This is available in multiplayer to all near aircraft. See here for more information: Note On SimVars In Multiplayer. Bool As I said a week ago:

👍

No - these are distinct simvars. The GENERAL ENGINE STARTER ACTIVE simvar is a read-only boolean that indicates if the indexed engine starter is active. If you want to read the value of this simvar, then you can add this to a spare (free for general use) offset. You can do this using the myOffsets.txt file - see the Advanced User guide for details. Not sure what this means...

License sent.

The only fix for this issue is to install the combined (2015, 2017, 2019, 2022) VC++ redistributable package, as stated.

I am currently on holiday and will reply when I am back, on Wednesday. However this: No - if you look at the presets: you should see that it should be ipc.writeLvar(“FSUIPC_C510_Ignition_1", 2) to turn the ignition on ipc.writeLvar(“FSUIPC_C510_Ignition_1", 1)vto turn the ignition off Otherwise, if you have defined the presets, you can use ipc.execPreset instead.

Trial licenses sent. Please be aware that I am now on holiday. Any more requests for trial licenses will be processed next week (Wednesday 18th October) John