John Dowson
-
Posts
11,999 -
Joined
-
Last visited
-
Days Won
241
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by John Dowson
-
-
Just now, xkoote said:
To be fair. I did one flight in the Dc-6 and one in the MD-11 (Yes, I'm Douglas at heart 😉 ) and I got no crashes. Will test this out tomorrow on my next bout.
It is actually quite difficult to crash the sim with this bug. The problem was that when certain events are received (i.e. an lvar update), the code wasn't exiting that code block for that specific request and was continuing to process the same data as another event. The behavior (i,e. a crash or something else) after it exits what the event that is processed then would depend on what was in the memory addresses being referenced - in 95% of the cases, this would be rubbish/unintelligible and the additional event processed would not do anything, but if this additional event was processed, meaning that certain data read in the event had certain values that were recognised by this subsequent block of code that processed events, then this could result in either an additional non-requested event happening, or more likely a CTD as the event would be trying to access data in memory addresses not available or allocated. Basically, it only happens occasionally and is very difficult to reproduce, but it was certainly a bug and the one that I think has been causing this issue.
Of course, if you still get an issue with this version I will look into it again, but hopefully this updated WASM will fix this. I will probably release this in aa week or so anyway, as it certainly fixes a potential issue.
John
-
16 hours ago, DaveSCUSA said:
The above toggles only work in one direction, turns the valve on but not off with the second push.
I have tested those in the C510 now and they work perfectly here, so I think you must be doing something wrong. If assigning to a key press, make sure that you have checked No repeats!. Otherwise, you can use logging to see what the problem is.
John
-
12 hours ago, DaveSCUSA said:
I have given up on the Mustang.
Again? Then why post more questions in this topic, which is for assignments in the Mustang.
12 hours ago, DaveSCUSA said:Sometimes the key presses work sometimes they don't.
This should not happen - you need to use logging to see why this is happening.
12 hours ago, DaveSCUSA said:I have switched to the C700 Longitude. The above toggles only work in one direction, turns the valve on but not off with the second push.
Confusing - do you mean that toggle only works in one direction in the C700 Longitude, or in the C510? If you have questions on the C700 Longitude, please find an appropriate topic or create a new one. I will check that toggle in the C510 shortly and report back (can't do it now as it seems my MSFS is now stuck while 'checking for updates'...).
13 hours ago, DaveSCUSA said:I understand the above in principle. But could you explain:
C700s_ANTI_COLL#(L:LIGHTING_STROBE_1) ! s0 (>L:LIGHTING_STROBE_1) 1 l0 (>K:2:STROBES_SET), I don't understand the role of S0 and I0. What number is set into the >K:2:STROBES_SET?
As O have said, I am no expert in calculator code, but the 's0' will store the value !(L:LIGHTING_STROBE_1) in register 0, and the s0 will use that, so it looks like two numbers are passed to K:2:STROBES_SET, 1 and !(L:LIGHTING_STROBE_1).
13 hours ago, DaveSCUSA said:C700s_Elec_Stby_Pwr_On#(A:ELECTRICAL MASTER BATTERY:3, bool) ! if{ 3 (>K:TOGGLE_MASTER_BATTERY) } 0 (>L:XMLVAR_STBYBattery_Test), in this case is it asking if A:ELECTRICAL MASTER BATTERY:3 is not true.
That is the conditional test, and when not true it executes '3 (>K:TOGGLE_MASTER_BATTERY)', then always executes ' 0 (>L:XMLVAR_STBYBattery_Test)'.
The MSFS documentation on calculator code is now a lot better - see
https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm
and for passing multiple parameters to key events (and simvars with multiple indeces), see
https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimVars/Simulation_Variables.htm#SimVars13 hours ago, DaveSCUSA said:These things can get kind of tricky.
Yes, and I am no expert in these matters. FSUIPC just provides access to these features, which are provided by MSFS. Therefore the MSFS documentation should be consulted for calculator code implementation, and the best place to discuss calculator code and presets for various aircraft would be the MobiFlight forums (MSFS2020 channel), not here.
11 hours ago, DaveSCUSA said:PS - A question I forgot to ask. Does including an LVar in a preset define the LVar in the Sim as it does in the model behaviors?
Not sure what you mean by 'including'. If you try to write to an lvar that doesn't exist, it will be created. If you try and read from it, then I do not know (and wouldn't expect) if the lvar is created or not - I would expect to read a nil value. But all FSUIPC does is sends any preset/calculator code to the WASM and then executes it.
John
-
Can you disable the starting of the MSFS2020_AutoFPS.exe program and re-test without that being started (just put a ; before the RunIf.
I don't expect this to make much of a difference but worth a try.If you get the same performance drop, can you disable the WAPI (Add-ons->WAPI->Disable) and see if that makes any difference. Also try re-starting after this change.
Otherwise I have no idea why you get such a drastic drop in FPS. Looks like the main thread use is doing a lot more work. and also the GPU which I don't understand (FSUIPC does not use the GPU) - this may be due to the MSFS2020_AutoFPS.exe program.
You could also try moving FSUIPC7 off of the main core, core 1, using the ThreadAffinityMask ini parameter. You would need to calculate the affinity mask to use for your system (online tools available for this).
Other than that, I am not sure what I can do about this if this is only affecting the one aircraft. I will take a look on my flight PC to see what the performance is like there later today or over the weekend.
John
-
2 hours ago, Luke Kolin said:
Sorry I wasn't more clear. I am not using Lua, I'm using offsets 0x0D6C and 0x0D70.
Ah, ok. Would have been helpful to say that at the start...
I would have to check the code for that offset to see that happens if the lvar doesn't exist, but I would think that this is not handled. it just calls the next level function (whatever that is) to get the lvar value and lets that handle the case where it doesn't exist and then just writes the value returned to the offset. I can check the code if needed, but better to just test and see what you get.
2 hours ago, Luke Kolin said:I'll try and make a test case where I manually set an LVAR, read it, then read an LVAR I know does not exist via the 0xD6C/0xD70 method.
Ok. But why are you using offsets to read lvar values? If doing this in code, maybe better to use the WAPI API directly (or one of its wrappers) rather than the old FSUIPC SDK. But that is for MSFS only, so I guess if you want compatibility for both FSUIPC6 and FSUIPC7 then you would have to use offsets.
John
-
18 hours ago, Luke Kolin said:
This is helpful context. If an LVAR has not been created when I request to read it, then get_named_variable_value would return an undefined result?
No. As I said, the MSFS documentation for get_named_variable_value returns 0 when the variable doesn't exist (see https://docs.flightsimulator.com/html/Programming_Tools/WASM/Gauge_API/get_named_variable_value.htm). However, you are not using this function directly, are you ?
If you are reading the lvars via lua, the ipc.readLvar documentation (for both FSUIPC7 and FSUIPC6) states:
QuoteThe value returned from readLvar is numeric, or nil if the variable is not available, and from readLvarSTR will be a string or nil.
Is that not the case?
Otherwise, how are you reading lvars? There are various ways that lvars are read, and what you get when the lvar doesn't exist may depend on the interface you are using.
Sorry, but I don't understand why all these questions on something so basic. If things are not working according to the documentation, please provide an example and I will look into it. Otherwise, follow the documentation.
John
-
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:
Quote63890 *** EVENT: Cntrl= 67185 (0x00010671), Param1= 1 (0x00000001), Param2= 0 (0x00000000) BEACON_LIGHTS_SET
63890 *** EVENT: Cntrl= 67307 (0x000106eb), Param1= 1 (0x00000001), Param2= 0 (0x00000000) WING_LIGHTS_SET
63890 *** EVENT: Cntrl= 67166 (0x0001065e), Param1= 2 (0x00000002), Param2= 0 (0x00000000) TAXI_LIGHTS_ON
63890 *** EVENT: Cntrl= 66975 (0x0001059f), Param1= 0 (0x00000000), Param2= 0 (0x00000000) CABIN_LIGHTS_ON
63890 *** EVENT: Cntrl= 66975 (0x0001059f), Param1= 1 (0x00000001), Param2= 0 (0x00000000) CABIN_LIGHTS_ON
63890 *** EVENT: Cntrl= 66975 (0x0001059f), Param1= 2 (0x00000002), Param2= 0 (0x00000000) CABIN_LIGHTS_ON
63890 *** EVENT: Cntrl= 66968 (0x00010598), Param1= 0 (0x00000000), Param2= 0 (0x00000000) PEDESTRAL_LIGHTS_ON
63890 *** EVENT: Cntrl= 67233 (0x000106a1), Param1= 1 (0x00000001), Param2= 0 (0x00000000) LOGO_LIGHTS_SET
63890 *** EVENT: Cntrl= 67171 (0x00010663), Param1= 1 (0x00000001), Param2= 0 (0x00000000) NAV_LIGHTS_OFF
63890 *** EVENT: Cntrl= 67170 (0x00010662), Param1= 2 (0x00000002), Param2= 0 (0x00000000) NAV_LIGHTS_ONAnd 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.
20 hours ago, Luke Kolin said:We have been getting some random results and curious if there is an expectation of a zero value or just random memory contents.
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 secondsI 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
-
17 hours ago, Luke Kolin said:
do you know the expected behavior if we attempt to read an uninitialized LVAR?
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
-
2 hours ago, DaveTorkington said:
Setting up a shortcutkey to activate / deactivate the .lua file via FSUIPC7 is straightforward.... I'm not sure if there's an idiot proof way to activate the script only with a particular aircraft but I'll do some reading up.
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
-
1 minute ago, Bintz said:
May I get a trail key please? Thanks
Sure - license sent via PM.
John
-
37 minutes ago, shivamatri100 said:
Can I get trail key?
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
-
17 minutes ago, xkoote said:
I have the same issue of Preset assignments dropping out mid-session.
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
-
5 hours ago, Zatoichi said:
Bought from Sim Market (opened ticket with them) but it says the info is not valid.
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
-
1 hour ago, Dominik said:
I start MFSM2020 then manually start fsuipc v7.4.11 everything works great. I close fsuipc and start v7.4.13 refreshing values on MCP becomes slow. I start v 7.4.11 again and everything works great. I don't change anything in lua code or other settings. If it's not fsuipc's fault then it's very strange. But if you say so then it has to be so.
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
FSUIPC 7.4.12 Stop working during flight ?
in FSUIPC7 MSFS
Posted
👍