John Dowson

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

Actually both of these methods do work - they just don't animate the switch. They do set the A-var (A:TURB ENG IGNITION SWITCH EX1) correctly. The animation of the switch is controlled by a B-var, and you currently cannot access B-vars either via standard controls or calculator code. There is a hack that you can use if you want to animate the switch - basically you edit the code and define an lvar that controls the b-var. To do this for ignition switch 1 (switch 2 will be the same, just change the numbers), you need to add the following code to the C510_interior.xml file (under Community\cockspur-aircraft-c510\SimObjects\Airplanes\cockspur-aircraft-C510\model). Open this file in an editor (e.g. Notepad++), scroll down to line 351 (comment line) and then paste the following text below the comment: <Component ID="FSUIPC_External_Control"> <UseTemplate Name="ASOBO_GT_Update"> <UPDATE_CODE> (L:FSUIPC_C510_Ignition_1, Number) s0 (A:TURB ENG IGNITION SWITCH EX1:1, Number) s1 l0 0 &gt; if{ l1 l0 != if{ 0 (&gt;L:FSUIPC_C510_Ignition_1) 1 (&gt;B:ENGINE_Ignition_1_Toggle) } } </UPDATE_CODE> <FREQUENCY>1</FREQUENCY> </UseTemplate> </Component> Next, add the following presets to your myevents.txt file (- in your FSUIPC7 installation folder - create this file if it doesn't exist): //Cockspur/Mustang C510 Mustang_C510_Ignition1_on#2 (>L:FSUIPC_C510_Ignition_1) Mustang_C510_Ignition1_norm#1 (>L:FSUIPC_C510_Ignition_1) You can then assign directly to those presets. If you would prefer a single toggle preset, use the following code: <Component ID="FSUIPC_External_Control"> <UseTemplate Name="ASOBO_GT_Update"> <UPDATE_CODE> (L:FSUIPC_C510_Ignition_1, Number) s0 l0 0 &gt; if{ 0 (&gt;L:FSUIPC_C510_Ignition_1) 1 (&gt;B:ENGINE_Ignition_1_Toggle) } </UPDATE_CODE> <FREQUENCY>1</FREQUENCY> </UseTemplate> </Component> and preset //Cockspur/Mustang C510 Mustang_C510_Ignition1_Toggle#1 (>L:FSUIPC_C510_Ignition_1) Ignition switch 2 is similar, with code: <Component ID="FSUIPC_External_Control2"> <UseTemplate Name="ASOBO_GT_Update"> <UPDATE_CODE> (L:FSUIPC_C510_Ignition_2, Number) s0 (A:TURB ENG IGNITION SWITCH EX1:2, Number) s1 l0 0 &gt; if{ l1 l0 != if{ 0 (&gt;L:FSUIPC_C510_Ignition_2) 1 (&gt;B:ENGINE_Ignition_2_Toggle) } } </UPDATE_CODE> <FREQUENCY>1</FREQUENCY> </UseTemplate> </Component> and presets: //Cockspur/Mustang C510 Mustang_C510_Ignition1_on#2 (>L:FSUIPC_C510_Ignition_1) Mustang_C510_Ignition1_norm#1 (>L:FSUIPC_C510_Ignition_1) Mustang_C510_Ignition2_on#2 (>L:FSUIPC_C510_Ignition_2) Mustang_C510_Ignition2_norm#1 (>L:FSUIPC_C510_Ignition_2) John

Sounds reasonably, but I don't think this will be that easy to implement. I will make a note to look into at some point, but not sure when I will have time. I already have quite a long list of new functionality to implement (mainly for FSUIPC7 / MSFS) and have very little time for this as support is still taking up most of my time. Regards, John

Not sure how much, if any, progress there is...! As I say, I can load that dll in WideClient but it crashes soon after, and I don't know why. I would like to see if you see the same though...and if that works in FSUIPC4 for you. That's ok - I don't need to see this. I still don't understand why your dll loads ok in FSUIP4 but not in WideClient (they use the same lua compiler). I will see if I can determine why, but still not sure how to go about this at the moment...

Btw, it seems that WideClient is crashing when using that luacom.dll I attached, shortly after or when the script loading the luacom.dll library is terminated. I also tried switching back to your version of the luacom.dll and now I see the same as you - it loads ok in FSUIPC4 but not in WideClient. I would be interested to see if you can use that luacom.dll, and also why this is different than the one you provided - maybe it is an older version? Anyway, please try that version and let me know how it goes, both with WideClient and FSUIPC4. This library is for using Microsoft's Component Object Model (COM) interface, not for handling COM ports, which is what the FSUIPC COM library is used for. Thee two COM libraries are therefore very different...! It maybe that using this library also requires that lua is also installed in Windows, which is why it didn't work for me before I installed it. I still don't understand why this is different in WidecCient though...

I am getting the same error you initially reported ("The specified module could not be found.") in both FSX and WideClient: How did you get the dll loaded in FSUIPC4? Did you write the lua program that uses the luacom.dll, or was that supplied to you? Could you attach that as well please (if allowed). There really is no difference in WideClient’s Lua facilities to those in FSUIPC (except where explicitly stated of course), so I’ve no idea why the 32-bit LuaCom.dll gives errors there but not with FSUIPC4. Do you know the lua version that the luacom.dll was built with/for? There seems to be a 64-bit fork of the luacom project, so I could try building () that. However, I would like to get the 32-bit version loaded by FSUIPC4 first.... Later: Some success....I installed the latest lua-for-windows package and took the luacom.dll from there, and used this to replace the one you provided. This now loads ok in both FSUIPC4 and in WideClient, so it looks to be a problem with that dll. Are you sure it is the same one that you are using with FSUIPC4? I have attached the one I am using (it is slightly larger than the one you provided, 168KB vs 164KB) - it is the one that comes with the 5.1.4 lua distribution: luacom.dll Can you please try with that version. Cheers, John

License sent. John

That is the best way to do it, otherwise you would have to clear/delete every profile-specific assignment via the UI. Once am aircraft has been assigned to a profile, the only way to remove it i by removing the aircraft name from the [Profile.xxxx] section. And if you want to remove the profile completely, you have to delete the [Profile.xxx] section together with all the other sections referencing that profile, e,g, [Axes.xxx], [Buttons.xxx], etc. Yes - they are comments that generated automatically. From the Advanced User guide: John

But that is for calibration WITH a reverse zone - the central 'Set' values are the idle position. Check for NRZ (top left of calibration panel) and they will disappear.

Not sure what you mean.... How are you assigning? Assign your throttle with Send direct to FSUIPC calibration using the Throttle1 and Throttle2 controls. Then go to the calibration. tab and calibrate with NRZ checked. If you then look at the out value sent, the minimum will be 0 at your calibrated idle position (usually around -16383). And if you have assigned your reverser button to Throttle Decr (on repeat), pressing and holding the button will activate the reversers. And the assignment to Throttle Cut on release will kill the reversers and go back to idle when you release the button.