John Dowson

Sorry for the delay. I have checked this here now and can see the problems you are having. I have found the best way to assign the flaps and wing sweep to different axes is as follows: 1. For the flaps, define four ranges for the axis for the 3 distinct positions (the axis itself is unused) - you need the same two ranges for the central position as you are assigning different controls to the Up and Down. My axis is reversed (i.e. shows 16383 at minimum position and -16384 at maximum rather than the other way around) and so my Up/Down assignments will also be reversed compared to normal axis (that goes from -16384 to +16383). I have created 3 ranges: +9000 to +16383: send Flaps Decr when entering from Up (sets Flaps 0 from flaps 4680)) -3500 to +3500: send Flaps Decr when entering from Up (sets Flaps 4680 coming from 9360) -3500 t0 +3500: send Flaps Incr when entering from Down (sets flaps 4680 coming from flaps 0) -16384 to -9000: send Flaps Incr when entering from Down (sets flaps 9360 coming from flaps 4680) These are my resulting ini assignments: 2. Similarly, for the wing sweep you also need to set 4 ranges and assign similarly to the flaps axis but use the wing swee up/down mouse macros: This seems to work pretty well mostly. However, you do get issues if you move the wing sweep axis when the flaps axis is not in the correct position and vica versa, moving the flaps axis when the wing sweep axis is not in the correct position. There is not much you can do about this with these assignments - you could maybe use lua to prevent such issues, but I think there would always be issues if/when your hardware levers mismatch the positions of the levers in the VC. Of course, it is not possible to do this (i.e. move the wing sweep lever when the flaps lever is not in the correct position, and vica-versa) in the VC, but there is nothing to stop you doing this with your own levers, and if you do then this is when mismatch problems can occur. Cheers, John

I thought I had updated this but my comment seems to have gone... Anyway, I checked this and the additional locks were added way back in the 7.4.0 release, so i don't know why things are slower. Looking in more detail, in may not be just the lvar reads. I will look into this further when time permits, but I can't see any changes between 7.4.11 and 7.4.12 that could cause this, except maybe with library updates (the MSFS SDK and the windows VC++ redistiubutable libraries), which I cannot do anything about. John

Not that I know of, and there should not really be any issues with different windows 11 versions - the network protocols used by WideFS should not change on windows updates as this would break many things... Check your network configuration - especially the Workgroup name. Please see the section Configure your Network in the WideFS User guide. Have you tried setting the ServerName or ServerIPAddr parameters, as well as the Protocol? I am still running 23H2 here on my Windows 11 laptop (as well as Windows 10 and Windows 7 on other PCs), so cannot verify with 24H2 at the moment,

Yes - in the offset functionality for lvars, if the lvar doesn't exist, then nothing will be written for read requests and write requests won't be processed either. The result offset is not set to zero as the lvar doesn't have a zero value, and, as I have said, I do not think that lvars can be uninitialized, at least those not created via the Gauge API. I can update the documentation to state the behavior when the lvar doesn't exist. Understood, and thanks for the kind words. John

Go to fsuipc.com and download and install the FSUIPC WASM module, the one with this description: Standalone FSUIPC WASM module. For users who need the FSUIPC WASM module for 3rd party cloents and don't have FSUIPC7 installed. Download, unzip and copy or move the fsuipc-lvar-module folder to your MSFS Community folder.

No, sorry, as you have already requested/used a trial license.

👍

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

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

Again? Then why post more questions in this topic, which is for assignments in the Mustang. This should not happen - you need to use logging to see why this is happening. 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'...). 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). 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#SimVars 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. 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

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

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