John Dowson

First, you posted in the Download Links sub-forum where it explicitly states NOT for support requests. I have moved your post to the correct forum for this question, which has also been asked many, many times before... Check the error 2 down from the one you highlighted. This will be an MSFS CTD. When this happens, you also get an fault (not a CTD) in FSUIPC7 as the FS has quit unexpectedly. If you check your FSUIPC7.log file, you will see that FSUIPC7 exited as MSFS was no longer available - and you may also see some SimConnect errors before this. If MSFS CTDs, report to Asobo. I cannot help with this. John

👍

See what the following lvars hold and how they change when you set TOGA: XML_Airbus_Throttle1_TOGA XML_Airbus_Throttle2_TOGA There are also the following, but probably less useful: TOGAPush TOGARelease If the XML_* variables hold the correct TOGA state, you could use those...

Ah, sorry - I think I misunderstood.... You have the TOGA button working, but the offset is not updated and so the motorized throttle doesn't see it... If that is the case, you need to determine if there is a different simvar or possibly an lvar that is updated instead. Once this has been found, you can either add that to a spare FSUIPC offset and use that, or you can add to an offset and spoof offset 0x080C to the value of the new offset. Try listing the lvars to see if any look appropriate. I will also take a look at some point to see if I can see anything... John

Many standard controls and offsets don't work with the PMDG 737 - you need to use either custom controls (using the Rotor Brake control) or presets. Presets may be easier, and looking at https://hubhop.mobiflight.com/presets/ I can see the following which you can try: PMDG_B737-7_AUTOTHRUST_TOGA_L_BTN PMDG_B737-7_AUTOTHRUST_TOGA_R_BTN Or assign to the Rotor Brake control, with a parameter of 68401 for the left button, and 68701 for the right button. To use the Rotor Brake control with the PMDG 737, see this FAQ entry: John

Could you try the attached version, v7.3.9c. This fixes a CTD caused in the WAPI (WASM API( that can occur when several config data updates are received in quick succession, usually caused by lvar creation in the WAPI/WASM. I don't think this is the cause of your CTD but worth trying. I have not been able to get a CTD with this version so far... Could you also enable debug logging in the WAPI, by adding the following to the [WAPI] section of your FSUPC7.ini file: LogLevel=Debug and show me your FSUIPC7.log file again if/when you get a CTD. John Later: beta version removed, some issues...I will repost at some point...

Stick with the current script - when updated on an event, the offset reverts back to 0 (when parking brake set) after a few seconds, and so needs to be continually updated. I did however experience a FSUIPC7 crash, and after restarting had difficulties accessing lvars. I will investigate. John

I am pretty sure they were for me...show me your FSUIPC7.ini and I will take a look (tomorrow now).

FSUIPC numbers buttons from 0, whereas windows starts from 1... FSUIPC certainly registers a release...but what button(s) are you talking about? What are you trying to do? What problem? I have a few other settings/configurations that I would like to try - didn't have time today, but will take another look tomorrow... I can also show you how I used this to prevent reversers activating from the throttle detent when reverser not activated. John

Ok, that shows the lua was sleeping when the crash occurred, so I doubt that is an issue. So it doesn't crash every time? How come the lua plugin log wasn't still active in that log? Yes - I wrote that script a while ago as an example. I will update to use an event when I get a chance and repost.

So this only happens with the FVW experimental? As I said: It shouldn't, but maybe try activating logging for Lua Plugins and send me a log with that. You can also try temporarily disabling it (just rename the lua file before you restart FSUIPC7) to make sure. That lua could also do with an update - it should really use event.lvar rather than an infinite loop with a delay...

No, sorry, but this has been reported before, but not sure what can cause this...

So, FSUIPC7 does not auto-start? If that is the issue, see the post I reference in my first comment on your issue. This I don't understand...why would FSUIPC7 auto-run the 2nd time but not the first? Each time you start should be the same as the last...and why restart MSFS and not just run FSUIPC7? Your use of the word load is what is confusing...and when you say 'restart it' do you mean MSFS or FSUIPC7?. And what happens the third or on subsequent attempts to run MSFS? The MSFS menu is only (obviously...) available if FSUIPC7 is actually running... All the information is in the User manuals or in the posts I have referenced... But I still don't understand your issue... Could you tell me EXACTLY what happens when you run MSFS - do you see an FSUIPC7 splash screen? If not, it is not auto-starting, and if this is the case you should try to start manually by double-clicking the FSUIPC7.exe. What happens when you do that? If it runs ok then, then your issue is with auto-start and you should refer to the link I posted on this issue. Otherwise, it could be a problem running FSUIPC7 - which is documented in the README. But please explain your issue, without using load. A program either runs when you start it or not - do you have FSUIPC7 running? If it is in your system tray, it is running.

Also, did you auto-start FSUIPC7 with MSFS, or start it manually, an if so, when? Does it crash again if you restart FSUIPC7? If so, can you show me the log, as well as your FSUIPC7.ini. After a few tests, it seems ok here. Maybe also check that you are using the latest experimental release. Can you also let me know if this is the only aircraft/version in which this occurs, and maybe switch to the stable or development version temporarily and check with that version.

Not sure if I can do anything if this is just with the FBE A320 experimental version, but I will switch to that and take a look. Looks to be using something new called SimBridge - are you using that as well?

From Saturday for 9/10 days... The log you attached shows the lvar names were received - when this happens, a message should be logged in the FSUIPC7 main window with the number of lvars/hvars/presets loaded, and the WASM menu items should be enabled. I can't see how the menu items cannot be enabled once the lvar names have been received... Make sure the user is checking after this message is logged... 7.3.9b. John

Does this only happen with the FBW A320? If so, which version (dev, stable or experimental) are you using - and is it up to date?

So this just happened the once? Your log shows that the WAPI interface was not started. I'm not sure why this happened - the next version will have additional messages relating to the WASM/WAPI - you could try this (attached) and show me your FSUIPC7.log file if this happens again. The WASM is the module in your Community folder that runs with MSFS, and the WAPI is the interface in FSUIPC7 that communicates with the WASM. The WAPI is now enabled by default if the WASM is installed, and your ini file shows this is enabled anyway: [WAPI] EnableWAPI=Yes So I'm not sure why it didn't start... John FSUIPC7.exe

No, they are completely separate and will not interfere. I run FSX, MSFS, P3Dv4 and P3Dv5 all on the same machine with different versions of FSUIPC. You can only have one FS/version of FSUIPC running at a tune though. John

For the auto-start issue, and if FSYUPC7 is not just auto-starting and then closing, please see If FSUIPC7 closes after starting, please show me your FSUIPC7.log file. John

You are using an extremely old (and unsupported) version of FSUIPC7 (7.0.3). The latest version is 7.3.8 - please update. Also, if you think that FSUIPC is crashing, I need to see your FSUIPC7.log file, John

Can you check that you have the following in your FSUIPC7.ini file and if not add it: [WAPI] EnableWAPI=Yes The WAPI is now enabled by default, but if that section isn't there then the presets will not be loaded. I will fix this in the next release.

This sounds like the rudder axis has been changed to a digital on/off axis in the registry. See the following FAQ entry to resolve this: John

I think that depends on the dll. There seem to be various solutions around for using dlls with lua - for example, see https://stackoverflow.com/questions/2835716/how-do-i-call-functions-inside-c-dll-from-lua https://blog.devgenius.io/how-to-add-your-c-library-in-lua-46fd246f0fa8 https://lua-users.org/wiki/LuaProxyDllTwo I don't see why this wouldn't work in an FSUIPC7 lua script, but best to try it - there is a trial license available at the top of this sub-forum if needed. John

No, that is just a warning - you should be fine as all your 11 devices are identified correctly. Maybe try using presets first - there are presets available for most most Rotor Brake controls which are easier to use. check the preset link I previously provided (has a good search interface for finding presets). John