John Dowson

I just installed and tested this aircraft here (on my development laptop), just sitting on the runway at EGLL and I get a very low framerate for this aircraft - only around 16. If I start FSUIPC, this drops to 13, so I do get a drop of 3fps which is more than expected, but nothing like the 30-40 FPS drop that you see. I will also check on my flight PC later. This aircraft does seem to emit a lot of events when it is just sitting there doing nothing - mainly STEERING_SET, NOSE_WHEEL_STEERING_LIMIT_SET, LIGHT_POTENTIOMETER_SET and various LIGHT_POTENTIOMETER_x_SET events, and it even events like these lights ones that are emitted every 70-80ms or so: And there are about 1600 of these every second. This may account for a drop by a couple of FPS I guess, but no more. Anyway, show me your logs and also test with the MSFS FPS monitor and tell me what you see there (no need for pictures!). Which clients do you use with FSUIPC7? Do you get the same FPS with FSUIPC7 and the client programs you use running as when FSUIPC7 is running but not any client programs? John

This sounds very strange... Is this the new A320Neo Enhanced (free add-on) released in SU15? If so, I haven't installed this yet - will install and take a look here to see if I get the same. Could you show me / attach your FSUIPC7.log and FSUIPC7.ini files. They should be quite small but you will have a very low upload limit as you are new to the forum (it will increase the more you post), so you may need to compress/zip them first. Btw, those pictures are pretty useless - they don't show anything (I can't see what those boxes are never mind read the numbers!). For FPS monitoring, activate the MSFS Display FPS option, under the Debug menu (you need to activate developer tools for this). John

All lvar values are stored as doubles (within FSUIPC), so its not possible to set a nil/null/uninitialized value. In FSUIPC7, a default value of 0.0 is used when the lvar/value is first created, but I think you can't read the value until the initial value is received, so that will be whatever is returned from the get_named_variable_value function of the Gauges API. Similarly, in FSUIPC6 and earlier it will be whatever the get_named_variable_value function of the Gauges API returns, but a value of 2.2250738585072014e-308 (DBL_MIN) may be returned if the lvar doesn't exist. If its random then I guess that is just what the get_named_variable_value function returns for uninitialized lvars. But I don't think that lvars can be uninitialized... As far as the MSFS documentation goes, it says they are set to 0 when created, so I would expect all lvars to be initially 0, and not random. And I would expect the same in P3D. Cheers, John

Looking in more detail at the PMDG737Zapis.lua function, it looks like the difference in time to complete one iteration of the loop is due to the time taken to read an lvar. In 7.4.11, in takes around 15ms to read an lvar's value (ipc.readLvar), whereas in 7.4.13 it is taking around 47ms, so its around 3x slower. As you are reading a lot of lvars, around 100, this 30ms difference adds up, hence the difference in the time it takes for one loop iteration in the different versions. I believe I added some additional checks/locks in the WAPI between these versions (I will check) to prevent multi-threading issues. These additional locks will certainly slow things down slightly.. I can review these changes to see if I can relax them a bit, but other than that there is not much I can do about this unfortunately. I would consider re-writing the PMDG737Zapis.lua script if I were you... it seems to be doing a lot of work in each loop - can this not be split-up and separated into different functions or scripts?

Looking at your scripts and logs, it looks like: - your functions in the PMDG737.lua are taking roughly the same amount of time in both 7.4.11 and 7.4.13. - there seems to be a two second increase in the time it takes for one iteration of the while loop in PMDG737Zapis.lua the first loop in 7.4.11 takes approx 17, seconds, and subsequent loops approx 12 seconds the first loop in 7.4.13 takes approx 19 seconds and subsequent loops approx 14 seconds I can take a look in more details at the PMDG737Zapis.lua to see if there is anything there that could cause such a delay, but I think it might be a small increase in time for each line executed, and as there are so many lines in the while loop in this script, it all adds up to quote a bit. I can check the timestamps of the log of this function execution at some point to verify this, but will take some time... This would be easier if you could supply separate log files for the lua scripts, i.e. Log-> Lua Separately The PMDG737Zapis.lua script doesn't look very efficient - what exactly is this script doing, and why is it executing so much in an infinite loop? And why are you communicating between your scripts using files (and why do these files have a .lua extension - they are NOT lua files, better to change these to .txt or .tmp)? You only seem to be sharing numbers - why don't you use FSUIPC offsets? I have also gone through all the changes between 7.4.11 and 7.4.13 and can see nothing at all that should affect lua perfomance. I can only think that an update of the windows libraries has caused this. but there is no way I can confirm this. Have you tried 7.4.12 - does that have similar performance to 7.4.11 or 7.4.13? If you don't have this version, you can download from here. It would be useful to know in which version this performance degradation actually occurred. John

@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.