John Dowson

How long into the session did this occur? When this occurs, and AFTER you have quit MSFS, can you please show me/attach your FSUIPC_WASM.log file please. Also, pause the sim, exit FSUIPC7 and save/rename the FSUIPC7.log file (and show me/attach that), then restart FSUIPC7 - do you have the same issue? Can you also activate Debug-level logging in the WAPI (Log->WAPI->Debug) and the WASM (in the FSUIPC_WASM.ini file - see the WASM section in the Advanced User guide if you do not know where this file or the WASM log file is located). If you are running MSFS in devmode, can you also check the MSFS console window to see if there are any messages relating to the FSUIPC WASM module (i.e. if it crashed or not).

The output from the record to csv.lua shows this was actually running slightly faster on 7.4.13 compared to 7.4.11. A change from displaying immediately to taking around 2 seconds does seem a huge difference and I really have no idea what could be causing this change. I'm not sure what I can do here to look into this. Could you maybe try and determine where this delay is, i.e. in what lua functions. You could maybe start with lua plugin logging (Log -> Lua Plugins) as this will log every statement. This will slow lua down a lot, but if it is still a lot slower in 7.3.13 with this then this may reveal where the problem lies, otherwise you could add some ipc.log statements when entering/exiting each function and we can compare the time it takes for each function to execute in each version. If you send me the logs for each version I can check them here. One thing you can also try, if you have not done this already, is to change the WASM ini parameter LvarUpdateFrequency from its default value of 6Hz to VisualFrame. This will improve the rate that lvar updates are passed from the WASM to FSUIPC7. John

Please see the provided documentation - in the README.txt the section Problems installing or registering FSUIPC7 and in the Installing and Registering FSUIPC7 pdf the section Invalid Key Problems. John

This sounds quite strange. Can you attach your lua please and I will test here (although I'm pretty sure I won't be able to use your lua directly, I can mimic what it does). Could you also please test with the attached lua script - its a simple script that logs FSUIPC offsets to a file (and is also available in the example lua scripts provided). Can you run this lua for a minute or so both in 7.4.11 and 7.4.13 and post/attach the resulting log file (the log will be appended and so the results from both tests will be in the same log file). I am interested in seeing the time-stamps in this file (first column), and see if there is much of a difference in these between 7.4.11 and 7.4.13. If you set lua debug logging (Log -> Lua Plugins) you should see the timestamps between entries increase by a factor of 10-13 or so. There are no changes between 7.4.11 and 7.4.13 that could affect lua performance, as far as I am aware, so I find this quite puzzling.... John record to csv.lua

License sent.

There has been no change at all in the lua interface for a very long time. Slow lua has also been reported before - see: So I have investigated this before... What I found previously was that lua scripts (and possibly FSUIPC7 itself) was running a lot slower when FSUIPC7 was started via the EXE.xml method. This is why I changed the default auto-start method to use the MSFS.bat file in version 7.4.12. However, with SU15, I retested this and found that lua scripts were now running at the same speed when started via the EXE.xml method as when started via the MSFS.bat file (or manually started), so I switched the auto-start method back to using the MSFS EXE.xml file in the latest version, 7.4.13. So, if you are auto-starting FSUIPC7 using the default auto-start method, the EXE.xml, can you try exiting FSUIPC7 and then manually re-start it. Do you then get back to the original lua performance speed? If so, try switching back to the MSFS.bat auto-start method. Other than that, I cannot think of anything I can do to improve the performance or why it is sometimes running slower. Note also that lua will run a lot slower when lua debug logging is activated.

Could you please attach your FSUIPC_WASM.log file from when you had this hang - if still available. Please attach that the next time, and also enable WAPI Debug logging (Log->WAPI->Debug) as it looks like its something to do with the WAPI / WASM. Can you tell me when you are starting FSUIPC7? Your log file shows this was manually started, but you have quite a few reconnection attempts. Maybe better to update your InitialStallTime ini parameter to 15 (currently 5). Note also that your trial license has expired, so you will not have access to licensed functionality anyway. The event is an AppHangTransient event. I think this is more likely to do with your system that FSUIPC. As it is transient, if you leave it running. does it recover? Can you see anything related to FSUIPC in the MSFS console window (you need to enable devmode to see this)?

When you say "all planes", do you mean aircraft with a propeller? This is standard behavior (for prop planes) - see, for example, here: https://www.boldmethod.com/learn-to-fly/aerodynamics/why-you-need-right-rudder-on-takeoff-to-stay-on-centerline-during-takeoff/ So basically that is how prop. planes behave - you should not have this issue with Jets. If you do not like this realism, you would need to set auto-rudder in the MSFS assistance options. John

That is strange - I don't get that here. If Windows Defender reports an error, I would normally report this, but as I don't get this at the moment (and I am up-to-date), maybe you can report this here: https://www.microsoft.com/en-us/wdsi/filesubmission/ John

License sent via PM. License sent via PM. John

That is not quite correct. What I mean is that for the intermediate positions, you need to define the same range twice, once with Up and the increment control, and another time with Down and the decrement control. So you need 6 ranges - one each for the top/bottom (one with Up,/increment, the other with Down/decrement), and two each for the two intermediate positions, one with Up/increment and the other with Down/decrement.

These ranges sound very weird...for example, for range 1, how can you enter in down from a 16383 value? And also your ranges 1 and 5 overlap. Maybe your axis is reversed? i.e. bottom position positive, top position negative. For such axis, then the opposite of what I said applies about the top / bottom ranges. As I said, your top/bottom ranges only need to send one control (incr or decr) when entering either up or down, all other ranges need a control sent on both up and down.... Anyway, glad its now working. I have also just got a license through for this aircraft from Just Flight, so I can install and take a look in more detail, but this will have to be at the weekend. John

But why? Note that you are using ranges in the reverse way than me - your range 1 is the top range, and is equivalent to my last range, and your range 3 is the bottom range (unless your axis is reversed, in which case you should reverse it anyway....). So check you are sending the correct incr/decr on up/down control respectively, depending on if it the start or end the range... I'm not sure what the issue is if the flaps and wing sweep really are two separate controls. This was/is confusing as your were talking about flaps events to control the sweep earlier, but then reported that they were controlled via lvars (or by using mouse macros). If they really are distinct controls, what I said earlier should work, although not having the aircraft I cannot check and verify here. I have asked Just Flight for a press-copy/developers license to investigate this. If I get one, I can take a look in more detail. Otherwise, I am not sure there is much more to add to what I have already said. John

Then use four ranges...no matter how many ranges, the procedure, irrelevant of the control, is the same: - for the first range, you would assign to a decrement control when entering the range in Down - for the last range, you would assign to an increment control when entering the range in Up - for all other ranges, you would assign to an increment control when entering the range in Up, and a decrement control when entering the range in Down Think about it!

The OP for that post was using lua scripts via FSUIPC7, so that is/was an FSUIPC issue. If your callouts are nothing to do with FSUIPC7, I cannot help. If your callouts are via MSFS (and not FSUIPC7), then I really cannot help with this - use the Asobo forums, as I said, If using FSUIPC7, please make sure you are using the latest version, 7.4.13, released a couple of days ago. John

That really depends on how and what those altitude alerts / callouts are triggered by - can you explain? Are you referring to MSFS functionality, in which case you should probably ask on the Asobo forums, or are you using FSUIPC7 in some way for these alerts / callouts? John

Are not the flaps and wing sweep controls independent then? Can you try assigning your flaps lever to just the flaps set control, and remove the events sent on ranges. you can maybe also try to calibrate your flaps to the detents, as shown in the user guide. Doing this, is this not sufficient for the flaps lever control? For the wing sweep, assign the axis to (unused) and define 3 ranges (for the 3 positions), lets call them 1, 2 and 3. For range 1, you need to send the F3_Sweep_Decr macro when entering the range in Down. For range 2, you need to send the F3_Sweep_Incr macro when entering the range in Up. and the F3_Sweep_Decr macro when entering the range in Down For range 3, you need to send the F3_Sweep_Incr macro when entering the range in in Up Can you try this please and let me know how that goes.

Note also that separate on/off presets are good for assigning to a switch or sticky button, but for a standard button or key assignment, you may be better off using toggle presets: M_LH_Fuel_Toggle#(L:switch_fuel_left, bool) ! (>L:switch_fuel_left, bool) (>K:TOGGLE_FUEL_VALVE_ENG1) M_RH_Fuel_Toggle#(L:switch_fuel_right, bool) ! (>L:switch_fuel_right, bool) (>K:TOGGLE_FUEL_VALVE_ENG2) John

👍

If it is running, you will see a message box to that effect. No - it isn't getting that far. But the first time you ran it, it uninstalled your current version, no? So you must have seen something. When you did this, did you give the UAC panel permission to run the installer? Seems like there is a windows issue where the UAC permissions isn't being displayed to run the installer. No idea why this is. Can you right-click the installer and go into the Properties and check the settings there. If you can't see anything, can you show me a screen-shot of the Security tab, and maybe also Compatibility and General tabs. I'm away for a couple of hours now, I will check later today. Maybe also try googling as to why a UAC permissions panel fails to display. Do you have an account that can be elevated to admin privileges?

There are no specific logging functions for lvars. To see what lvars are available, and what values they currently have, just list them (Add-ons -> WASM -> List Lvars). Did you send the offsets to the log file? As your next post indicates that these lvars work, I would expect there values to change. Try listing them. So that toggles an lvar value and triggers and event. I don't understand that - there are no such lvars as C510L_Fuel_1 or C510L_Fuel_2, so those presets will create those lvars and set the value - is that what you want? Otherwise, simplify to the following, which matches the gauge xml code: M_LH_Fuel_On#0 (>L:switch_fuel_left, bool) (>K:TOGGLE_FUEL_VALVE_ENG1) M_RH_Fuel_On#0 (>L:switch_fuel_right, bool) (>K:TOGGLE_FUEL_VALVE_ENG2) M_LH_Fuel_Off#1 (>L:switch_fuel_left, bool) (>K:TOGGLE_FUEL_VALVE_ENG1) M_RH_Fuel_Off#1 (>L:switch_fuel_right bool) (>K:TOGGLE_FUEL_VALVE_ENG2) John

That is nothing to do with FSUIPC, and is only an informational message. Do you not see any errors, or anything relating to the FSUIPC installer? Did you check your AV? Please do that. So you don't see anything when you run the installer? The first thing that should happen is that windows UAC should ask permission to run the installer - do you see that? Anything else?

Stops when? Or are you saying that it runs the uninstaller, to uninstall the previous version, and then stops? If so, it sounds like it is crashing for some reason. Can you check both the windows Event Viewer for any crash reports (under Windows Logs -> Application), and also check any anti-virus software that could be blocking the installer. What folder are you trying to install into (or where was your previous version installed)? Have you extracted the installer from the zip file? John

What do you mean by 'offset log'? There is no such thing. There is the myOffsets.txt file, which is not a log, but a list of simvars (or a-type variables) to add to offsets. You may be able to add lvars to this, as lvars are now supported by the SimConnect SDK, but I haven't tested (or documented) this yet so I am not sure. To add lvars to offsets, you should use the [LvarOffsets] section of the ini file (see Advanced User guide). Sorry, what does this mean? Do those lvars work to control the fuel valves or not? Btw, it is a good idea to test lvars before using them, using the provided facilities (e.g. Add-ons->WASM->Set Lvar...,).

Well, they won't as you never pitch down for than 20 degrees. I released the next version of FSUIPC7 last night, so the pressure is off, and I am going to have a few days off (well, not off, but more relaxed!). But I don't really have anything else to say on this subject that I haven't already. I don't understand why your original code doesn't always display to one dp (it does here), but I am not going to worry about that. Use any of the three options - your original code, original code + conversion to 1dp, or my code. They are all pretty much the same except for the difference I have already pointed out. Cheers, John