John Dowson

@xkoote & @EisernUnion: i have found a bug in the WASM that could lead to a crash in some situations. I have corrected this in the attached version if you could try this please. John layout.json manifest.json FSUIPC7_WASM.wasm

Not without checking...I can do this later, but I am pretty sure that the behavior would be different in FSUIPC6 and FSUIPC7 as the way lvars are accessed is different, I suspect there is no specific handling for uninitialized lvars. Off hand, I think that in FSUIPC7, a default value of 0 is used, but in FSUIPC6 and earlier it will be whatever the gauge function returns, but I will check later and get back to you. John

First, you posted in the FAQ sub-forum where it explicitly states NOT for support requests. Please take care to post in the correct forum for support. I have moved your post for you. You should post/attach your FSUIPC4.log file if you have a CTD. However, if FSX is crashing after a few seconds, then this is usually due to a corrupt weather file. Try disabling weather by setting NoWeatherAtAll=Yes to the [General] section of your FSUIPC4.INI file. If this solves it then either your wxstationlist.bin file is corrupt, or one of the .wx files saved with scenarios is bad. To resolve this, delete all of the .WX files from your FS Documents folder (where your flights are stored), and the file "wxstationlist.bin" in your <user>\AppData\Roaming folder for FSX. If that doesn't fix it, it may be a simconnect issue and I need to see your FSUIPC4.log file and also your InstallFSUIPC4.log file. John

If you want to always run the script when you use a particular aircraft, then you need to use a profile for the aircraft and add an [Auto] section to the profile, i.e. [Auto.xxx] where xxx is the profile name (or just [Auto] if using profiles-in-separate-files). See the Advanced User manual, page 40, section Automatic running of Macros and Lua plugins. John

Sure - license sent via PM. John

License sent via PM. John

Please do not create more posts on the same topic. I have deleted your other post.

Did you update your VC++ redistributables, as the documentation states? If not, please do that. If you have done that, please let me know your SimMarket order number and I will check them here (do not post your key details!). John

Ok - but note that I don't need to see the WASM ini - there can be two of these (the one installed with the WASM in your Community folder, and your local settings in the AppData folder) and the values used will be logged in the WASM log anyway. Maybe also attach your FSUIPC7.ini file though. If presets stop working but everything else continues to work, it will either be a problem in the WASM or the WAPI. From other posts in this thread, I suspect that the WASM has crashed (although the crash report was for version 7.4.12). Maybe also check the Windows Event viewer to see if any crash Event is present. There has been little change in the WASM for around a year. I did update in the 7.4.13 release to add a new WASM ini parameter, but this was a simple update and should not cause any issues. So as the WASM has been stable for years I am not sure yet what has changed to cause this issue. I will also continue to try and reproduce here, and look into how to profile and debug a WASM. Cheers, John

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