John Dowson

There were a few fixes in this area in the SU1 [1.3.23.0] update recently released: Fixed several time-related issues such as ZULU/CLOCK SET events not behaving as expected Fixed SimVars ZULU DAY OF WEEK, ZULU DAY OF MONTH, ZULU MONTH OF YEAR, ZULU DAY OF YEAR, ZULU YEAR So hopefully this issue is resolved, although I haven't tested/checked this yet. I will check this again sometime next week. John

Both of those log files and after 4 and a half seconds and were attached when FSUIPC7 was still running (or had crashed?), and don't reveal much.... Can you please always exit FSUIPC7 before attaching files (or let me know if it crashes or doesn't exit cleanly). Maybe you can also try with the logging console open (Log->Open Console) and tell me what the last message logged is when the memory/performance issues start. Also please use the attached beta version (7.5.3b). I have modified to not try and read the aircraft.cfg file if it cannot be opened (which is unfortunately most if not all of the time in MSFS2024 due to streaming), and there are also the following changes in this version: - allow helicopter-specific axes to be suppressed/disconnected via offset 0x310A - allow lua ipc.control function to take two parameters for the control - delay auto-start of WebSocketServer until offset 0x3308 populated (i.e. once connected to MSFS) - allow use of Input Events in macros John FSUIPC7.exe

Ok. Those files look food now. Please use/try the attached FSUIPC6.ini and you should be ok. Any issues, please show me the files again. It also seems that the GUIDs of your devices have changed a few times (probably due to windows updates), and when this has happened you have re-assigned. If this happens again, you should correct the [JoyNames] section so that the assigned letters are using the new GUIDs and not re-assign to the new letters. Or post your files here the next time and I can show you what you need to do when this happens. John FSUIPC6.ini P.S. You are using version 6.2.1 - the latest and only supported version is 6.2.2. There are only minor changes in this version, but please update at your convenience.

LueValue is documented in the Lua Plug-ins document, and also mentioned in the event.param documentation in the Lua Library document. I can see that the LuaValue is missing from the list of valid controls in the documentation for offset 0x0D70, but I think this is an omission error - it is certainly available. So you can use that offset to trigger the LuaValue via MobiFlight if you want to do it that way. That is strange as the logic for the increment/decrement is exactly the same as the non-event based version. You can use FSUIPC's lua debugging facilities to see what is happening. John

No - please dont disable anything. They are not the cause, it is a camera state or event order change that is causing these lua scripts to be stopped and restarted. And this is most probably not related to the memory/performance issue. Only make the recommended logging changes for now.

I presume you mean 7.5.2... What does this mean? The two icons that the FSUIPC installer installs on your desktop only start MSFS2020 and MSFS2024 only (unless using the batch auto-start method, which you aren't). Do they start the respective MSFS versions? When each MSFS version starts, does FSUIPC7 also auto-start? If not, then auto-start is not working - see the following FAQ entry: Do you need to be running as an admin? Always better to run with standard privileges if possible, but if running as admin then everything must be ran as admin - MSFS, FSUIPC and all client programs. Note that with the READY, the programs will not be started until an aircraft is loaded and ready to fly. If you want them started earlier, when MSFS is still in the menu system, use the keyword CONNECTED instead. Any further questions, please attach your FSUIPC7.ini and FSUIPC7.log files, not your InstallFSUIPC7.log file. There is no issue with your installation. John

I've been testing here and cannot reproduce - memory use never goes above 35MB and CPU usage is always between 1.5 - 3%. When are you starting FSUIPC when this occurs? i.e. what is the exact state of MSFS - in start menu, in main or other menu, plane loaded and ready to fly, plane loading, ....? It would be ideal if I could reproduce this here (so more information on when this occurs is helpful) but failing that the logs from when this happens, with the additional logging activated, would be useful. Thanks, John

By the way, I have the X-55s and this is how mine are detected in the log: i.e. each one detected with a single GUID. Your log shows the stick with 2 GUIDs and no GUID for the throttle: This is usually due to having installed saitek drivers and maybe additional software, so please remove those (or don't run any additional saitek software when using FSUIPC).

This is very strange: i.e. you have two different devices (x2215 and xA215) from the same vendor (x0738) that have the same GUID (E942D3A0-E721-11EB-8002-444553540000). GUIDs are allocated by windows and should be unique... Do you have any additional software or drivers installed for your devices? If so, please uninstall and delete any specific drivers, especially any Saitek drivers, and let windows install its default drivers. And do not use any additional saitek software when using FSUIPC. Also, please do the following: 1. Take a backup of your registry, using the windows Registry Editor 2. Unplug all your devices 3. Download and run (i.e. double-click) the following regedit script: removeDevices.reg This will remove the current registry entries for your devices 4. Reboot your PC 5. Reconnect your devices 6. Run P3d and FSUIPC - just start it, load an aircraft and then exit 7. Show me / attach those 3 files again. Do not make any further changes at the moment John

That is interesting - which one? And how did this cause this steering/rudder issue? Thanks - its going to be a slow process.... hopefully I will be able to keep these forums read-only for quite a while so I can transfer the information over an extended period and after the new discord support is active. John

Could you add offset logging for offset 026D as U8, set WAPI->Debug level logging and Extras logging and show me another log file from when you experience this issue. Thanks, John Later: also please add offset logging for 0258 as U32

The changes in 7.5.1 and 7.5.2 were minimal and I don't see how any of those changes can cause such issues. At what point (i.e. how long after FSUIPC was started) did you take that task manager screenshot? Your log shows a strange issue after around 2.5 minutes when the lua autos were killed and input events stopped and then requested: Do you know what caused this? Input Events are also stopped and re-requested at around 6 minutes: and the lua autos restarted after 9 minutes: All that seems strange... And later, after FSUIPC had been running for over and hour and a half, there are a lot of device scanning entries, starting here: which go on for 10+ minutes, and the log ends after 2 hours 7 minutes. So you kept FSUIPC running for the entire session even though you experienced these memory/performance issues at the beginning? When you get this issue, what happens if you exit and restart FSUIPC7? It does look like there are some issues with FSUIPC starting/stopping things when it shouldn't, and this is probably due to changes in either events. order of events or camera state changes in MSFS, and is most likely due to MSFS2024 updates and not FSUIPC updates (although you can go back to 7.5.0 if you want to confirm this). I will look into this, but I will probably require more logs with additional logging set. I will get back to you once I have investigated. John

Yes, I thought there might be performance issues... When a lua script is ran, the thread has to be created and the script compiled before it can be executed, This gives an overhead of 50ms+ (depending on hardware and available resources). When a lua script is triggered via a rotary (or on button/key repeat) the calls to start the lua can come before the previous lua has finished, and when this happens the previous lua invocation is killed and the next one started. This can result in nothing happening (as the scrip is continually being killed before it does anything) and a backlog of dying threads consuming resources. There are two things that you can do about this. The first, is to adjust/increase the LuaRerunDelay ini parameter. Default value is 66 - try incrementing by 20 until you reach a value where it works smoothly (although probably too slow...). You could also try setting the LuaAffinityMask ini parameter (undocumented) to an affinity mask to move lua thread execution off of the main core which may improve performance and allow a lower value to be used for the LuaRerunDelay ini parameter. The second, and better solution, would be to re-write the lua script to have it always running and re-act to events, which removes the thread creation and lua compilation overhead. It looks like you are currently writing a 'feed value' to offset 0x0D6C and then running the script which reads this value. Rather than doing this, you can have the script auto-ran, and rather than start the script with the Lua command, you send it the feed value using the LuaValue command. To auto-tun the script, you use the [Auto] (or profile specific [Auto.xxx]) ini file section - see the Advanced User guide, Here is the previous script adapted to be triggered via the LueValue command. -- -- function to convert to BCD -- function convertToBCD(freq) local cleanFreq = freq:gsub("%.", "") -- Remove decimal (e.g., "109.2" → "0920") local decimalNumber = tonumber(cleanFreq) -- Convert to number if not decimalNumber then return 0 end -- Return 0 if conversion fails local bcd = 0 local shift = 0 -- Convert each decimal digit to BCD format while decimalNumber > 0 do local digit = decimalNumber % 10 bcd = bcd + (digit * (16 ^ shift)) -- Use base 16 shift instead of bitwise left shift decimalNumber = math.floor(decimalNumber / 10) shift = shift + 1 end return bcd end function updateNav1(feed_value) currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) if feed_value==10 then -- if turned right, the left encoder (MHz) sends the value 10 to offset 0x0D6C -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached if tonumber(currentNav1) >= 1700 then newNav1 = currentNav1 - 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 + 100 end elseif feed_value==20 then -- if turned left, the left encoder (MHz) sends the value 20 to offset 0x0D6C -- the following lines decrease the MHz value by 1 MHz and wrap the frequency around, adding 900, when 108.95 MHz is reached if tonumber(currentNav1) <= 895 then newNav1 = currentNav1 + 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 - 100 end elseif feed_value==30 then -- if turned right, the right encoder (kHz) sends the value 30 to offset 0x0D6C if string.find(currentNav1, "%d%d95") then -- this line checks whether the frequency ends with 95 and ... newNav1 = currentNav1 - 95 -- ... if so, substractss 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without increasing the MHz value. else newNav1 = currentNav1 + 5 end else -- if turned left, the right encoder (kHz) sends the value 40 to offset 0x0D6C, which for now is "else" if string.find(currentNav1, "%d%d00") then -- this line checks whether the frequency ends with 00 and ... newNav1 = currentNav1 + 95 -- ... if so, adds 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without decreasing the MHz value. else newNav1 = currentNav1 - 5 end end newNav1_BCD = convertToBCD(tostring(newNav1)) -- convert to BCD ipc.control(65708, newNav1_BCD) -- sending BCD to FSUIPC end event.param("updateNav1") ipc.log("Nav1 ypdate lua script now running") John

Ok, thanks for the update. I wonder what caused this though...very strange! John

I have no idea - try the aircraft support...but if you have a working solution, I would just be happy with that... Sorry but most of that doesn't make much sense to me (I would need to see log and ini files for each test to make sense of this), I don't have this aircraft and I really cannot spend any more time on this as I have far to much to do at the moment....these forums are shutting down at some point this year and I need to move everything across to www.fsuipc.com and set up a discord server for support. I therefore have no time to look into this, especially as you have a working solution..

To be clear, something like the following, although this is untested: -- -- function to convert to BCD -- function convertToBCD(freq) local cleanFreq = freq:gsub("%.", "") -- Remove decimal (e.g., "109.2" → "0920") local decimalNumber = tonumber(cleanFreq) -- Convert to number if not decimalNumber then return 0 end -- Return 0 if conversion fails local bcd = 0 local shift = 0 -- Convert each decimal digit to BCD format while decimalNumber > 0 do local digit = decimalNumber % 10 bcd = bcd + (digit * (16 ^ shift)) -- Use base 16 shift instead of bitwise left shift decimalNumber = math.floor(decimalNumber / 10) shift = shift + 1 end return bcd end feed_value = ipc.readUB(0x0D6C) -- depending on which rotary encoder is turned and into which direction, MobiFlight sends a feed value to offset 0x0D6C currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) if feed_value==10 then -- if turned right, the left encoder (MHz) sends the value 10 to offset 0x0D6C -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached if tonumber(currentNav1) >= 1700 then newNav1 = currentNav1 - 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 + 100 end elseif feed_value==20 then -- if turned left, the left encoder (MHz) sends the value 20 to offset 0x0D6C -- the following lines decrease the MHz value by 1 MHz and wrap the frequency around, adding 900, when 108.95 MHz is reached if tonumber(currentNav1) <= 895 then newNav1 = currentNav1 + 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 - 100 end elseif feed_value==30 then -- if turned right, the right encoder (kHz) sends the value 30 to offset 0x0D6C if string.find(currentNav1, "%d%d95") then -- this line checks whether the frequency ends with 95 and ... newNav1 = currentNav1 - 95 -- ... if so, substractss 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without increasing the MHz value. else newNav1 = currentNav1 + 5 end else -- if turned left, the right encoder (kHz) sends the value 40 to offset 0x0D6C, which for now is "else" if string.find(currentNav1, "%d%d00") then -- this line checks whether the frequency ends with 00 and ... newNav1 = currentNav1 + 95 -- ... if so, adds 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without decreasing the MHz value. else newNav1 = currentNav1 - 5 end end newNav1_BCD = convertToBCD(tostring(newNav1)) -- convert to BCD ipc.control(65708, newNav1_BCD) -- sending BCD to FSUIPC John

The script looks overly complicated to me...not sure you need to be adding/removing the leading 1 so often, and rather convert to string to add/remove, you can just add (or remove) 10000 to the string value, and as lua is non-strict on types, you can just be lazy when adding/subtracting. i.e rather than: currentNav1 = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1_string = "1" .. string.format("%04X", currentNav1) -- convert decimal to string currentNav1_string_number = tonumber(currentNav1_string) -- convert string to number if currentNav1_string_number >= 11700 -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached then newNav1 = currentNav1_string_number - 900 else newNav1 = currentNav1_string_number + 100 end newNav1_string =tostring(newNav1) -- converting the decimal to a string, so that the leading 1 can be cut newNav1_cut = newNav1_string:sub(2,-1) -- cutting the leading 1 simpler would be currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached if tonumber(currentNav1) >= 1700 then newNav1_cut = currentNav1 - 900 -- currentNav1 will be converted to a number implicitly else newNav1_cut = currentNav1 + 100 end -- -- etc -- Then to send: newNav1_BCD = convertToBCD(tostring(newNav1_cut)) -- convert to string before calling function ipc.control(65708, newNav1_BCD) -- sending BCD to FSUIPC Not a big deal though - just FYI. Also, even though the aircraft does not have standby frequencies, they are most probably still available in the model. So what you can also do, which may be easier, is: 1. Set standby frequency to be the same as the active frequency 2. Inc/dec the standby frequency as desired using the standard FS controls 3. swap the active/standby You can even compress 1 & 2 and just read the current active frequency (in Hz as easier!), change the value to the new required frequency, set that as the standby frequency and then swap. Regards, John P.S. Also a good idea to declare your function(s) at the top of the script and mot embedded in the logic - this aids readability!

You can have it but it won't do anything because, as I said, it is the FS axis events that are calibrated, and this can be done before sending to the FS (done when using 'Send direct to FSUIPC calibration') or when the event is received by FSUIPC (and this event can be generated by FSUIPC when assigned with 'Send to FS as normal axis', or can be generated by the FS or other software, depending in the priority level it is sent at). So what does it use below 10kts? If you are using a preset for rudder and have calibration set up on rudder and this is having an effect, then what must be happening is that the preset is being executed and this is generating the FS rudder control/event (in the FS) which is then being received by FSUIPC, is being masked (i.e. blocked), but the value received is calibrated and then resent back to the FS (using the same event). But this surprises me, as I thought that the standard FS rudder controls don't work...if they do, why don't you just assign to those? When the aircraft is static, do you see the rudder move (external view) when you use the preset? If so, the preset must be working at all speeds, no? And if you activate logging for Axes Controls, do you see any rudder events when using the preset, and if so which one? Do you see any movement when assigned to Axis Rudder Set or Rudder Set (under 'Send to FS as normal axis')? And when assigned like this, can you set up monitoring for the lvar L:INPUT_RUDDER (see documentation on how to do this via the ini file) and see how that changes?

The ! symbol is the logical not operator so !TRUE is FALSE, and !FALSE is TRUE (or, in RPN, TRUE! is FALSE, and FALSE! is TRUE. So the expression (L:someLvar, bool) ! (>L:someLvar, bool) flips/toggles the value of the lvar, i.e. changes it from TRUE to FALSE or from FALSE to TRUE. John Also explained here: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm

👍

There are no changes in the 7.5 release that could cause this, and that was released at the beginning of December now...have you had this issue since then or have you only recently updated? You can try an earlier version to confirm if you like, e,g, https://fsuipc.com/download/Install_FSUIPC7.4.17.zip So your throttles are not assigned in FSUIPC? Can you be more explicit please - what do you mean by 'but will only slide back halfway'? And what do you mean by 'On single engine aircraft, only throttle 2 works'? In a single engine aircraft, there is only one throttle (throttle 1).... That message is informational and just letting you know that that preset isn't available for use as the name has too many characters. It is not being used (it is not even available for use!). Also looks like you manually reloaded the presets as that message is logged twice. Can you please activate logging for Axes Controls and test again, and show me / attach both your FSUIPC7.log and FSUIPC7.ini files. Just load the aircraft, move the throttles through the full range and back again, and then exit before attaching files.

Just from 1 to 0? Not from 0 to 1 to 0, or from 1 to 0 to 1? As it auto-resets, it should change to 1 value then back again (or to 0 then back again)... Maybe try: DU_MasterBright_Bright#(L:INI_CKPT_LT_DU_MASTER_BRT_INC, bool) ! (>L:INI_CKPT_LT_DU_MASTER_BRT_INC, bool)

Can you attach your FSUIPC ini and log files, as well as your WideServer.log, WideClinet.log and WideClinent.ini. That will ar least give me an idea of your set-up. And please let me know how the avionics on the client PC is configured - are you using any other additional software? If you have not assigned/configured in WideClient / FSUIPC (and if ButtonScanInterval is set to 0) then these devices (whatever they are) must be assigned elsewhere, no? i am confused as to why do you think this is related to WideClient / FSUIPC if your client controllers are not assigned in FSUIPC...

Yes, that sounds correct, as that lvar is documented as a BOOL. I have no idea why it isn't controlling the brightness. When you inc/dev the brightness in the VC, do you see the lvar change value (and reset)? As I said earlier, you should ask on the InBuilds support forums as I do not have this a/c.

The only way they can be coming from WideFS is if you have set it up to do this and have assigned in FSUIPC. If that is the case, remove the assignments. Also, if you set ButtonScanInterval=0 in WideClient, it will not forward any button presses to FSUIPC, and so cannot possibly trigger anything there. What hardware to you have attached to your avionics PC, and how/where are they assigned? If you have not assigned in FSUIPC, why do you think it is coming from there? WideClient only talks to FSUIPC, not the FS.