John Dowson

I have also just noticed that you are running FSUIPC7 with elevated privileges: Why is this? Are you running MSFS with elevated privileges? Everything needs to be ran at the same privilege level, and always better to run with standard privileges unless absolutely necessary.

Oh...and when you re-install, after the uninstaller has ran, double-check that the fsuipc-lvar-module folder has been removed from your Community folder. If not, manually delete that before continuing with the installation. The uninstaller may not be able to remove that due to your permissions issues.

Of course I did - but that tells me nothing. What tells me what is happening is your log files. Screenshots are useless so no point posting then unless specifically requested. The firs log file you attached was also useless as it showed that FSUIPC7 didn't even connect to MSFS. The second log file is the only useful bit of information you have so far provided, which shows that there is an issue with the WASM. Since then, I have been trying to determine if the WASM is actually running. If it is not running, that is your issue and we need to determine why. If it is running, then I need to see the FSUIPC_WASM.log file to diagnose the issue. If no log file (presume you mean the FSUIPC_WASM.log file, AND you are looking in the correct folder) is generated, then the FSUIPC WASM module is not running. You can also verify this in MSFS2024 itself: activate DevMode and under the Debug menu select/check Display WASM Debug Window, and then in the Modules selection select fsuipc-lvar-module (FSUIPC7_WASM.wasm). Then select the tab Module Section. What is the status there? As I said, I have no idea why this is - this is something peculiar to your system and something you must resolve. This could also be what is causing your issue, as the WASM may not be running due to permissions issues. Did you run the FSUIPC7 installer as Administrator? If so, this is not needed and may be the issue. Why don't you try re-installing? Just download the latest installer and run it again (not as admin). It will then ask to uninstall the current version (agree to this) and re-install. Then check the permissions on the file again. If you get the same issue, then sorry but I have no idea what is happening and there is something strange going on in your system related to permissions that you need to resolve. I cannot help with this. No, it is correct. But there are two auto-start methods, via the EXE.xml and via the .bat file. One of the bat files you attached shows that you were using the bat file auto-start method, and you have also modified this to start some other programs: That is why I asked.....

How are you starting this lua script? Can you also attach your FSUIPC7.ini please, and also another log file but with logging for Buttons & Keys activated as well as Lua Plugins. But why don't you use the lvar logging facilities provided in FSUIPC7? This will log to the log file and optionally also to an ext window. See the section Logging Lvar Updates in page 48 of the Advanced User guide. Yes, the simconnect display facilities are not available in MSFS.

Yes, with the PMDG aircraft you can use either custom control numbers (preferred) or the Rotor Brake control method - there are FAQ entries for each method. I don't know if the FSL aircraft support custom controls (I will check when I have time), but if the Rotor Brake controls are logged, then I would try assigning to those, using the parameter logged. Please just try this to see if it works and let me know. If not, let me know one button/switch that you are trying to assign and I will look into that here. John

Sorry, forgot to update this thread - see

I have no idea - just look at the FSUIPC_WASM.log file, if there is one - this will tell you if the WASM is running and if that ini file is being read. If you have no log file (in the WASM persistent storage area, NOT under your Community folder) then the WASM isn't running and that will be your issue. Why not? Did you read the documentation? If so, what isn't clear about that? You CAN modify that file, but it is NOT recommended, and you should use the one in the WASM persistent storage area (which is NOT there by default - you have to copy the one from the Community folder location to the persistent storage area and then modify it from there). This is all explained in the documentation. There is no file attached, and there is no point attaching it either. Attach the FSUIPC_WASM.log - that is the file I need to see, preferably with Debug logging activated, but any existing one would to do start with.... Also, why are you using the bat method of auto-start rather than the default (and preferred) EXE.xml method? Why are you starting other programs from the MSFS2024.bat file? It is better to use the facilities provided by FSUIPC to start other programs (and use either the CONNECTED or READY keywords, depending in the program). See the section Programs: facilities to load and run additional programs in the Advanced User guide.

That is strange... but I don't know what you mean by 'Could this be the issue?'. You (or the account that you used to install) are the owner. I cannot help with permissions issues on your system - try google. BUT, you don't need to edit/change that file, and it is not recommended to modify that file anyway as any changes will get overwritten the next time you install. Please read the section WASM module ini file and parameters in the Advanced User guide (page 51) where it says: It is recommended to leave this file as is, and copy to your persistent storage area and modify as and when needed from there.

Sorry, but this is confusing. Is the dll in the modules folder or not? If not, you can manually install it if someone can supply you a copy of the dll, and you would have to manually update FS2004 to load the dll. This is way before my time I'm afraid and have no access to anything regarding FSUIPC3 (it is free and unsupported). Again, I have no idea, If FSUIPC is installed and loaded by FS2004, and the only issue is that it is unregistered, then you can try manually creating the key file. Create a file in the FS modules folder (where the FSUIPC dll is located) called either FSUIPC3.key (or maybe just FSUIPC.key) with the following contents: [User] Name=free user Address=fsuipc@free.com FSUIPC=Y8ZGSUWHTIQ2 John

That is a far better log! But I don't understand why you keep attaching the bat file though - that is installed by the installer and I have that here. It is not needed. That log file shows that there is an issue with the WASM and that the initial lvars were not received. Please show me / attach your FSUIPC_WASM.log file, and check that the WASM isn't crashing - this seems to be more frequent in MSFS2024 than MSFS2020. Also set Debug level logging in the WASM (via the FSUIPC_WASM.ini file) - see the Advanced User guide if you do not know where these are. Also see the following FAQ entry on the WASM crash and how to prevent: John

If that is what FSUIPC sees, that is what windows is reporting. First, try calibrating under windows (game controllers). That will determine the values that FSUIPC sees. But if that is the range you see in the assignments panels, you can calibrate those to the full range using FSUIPC's calibration facilities. Better to assign using 'Send direct to FSUIPC calibration', but you may also be able to calibrate when using 'Send to FS as normal axis' (although I am not sure about this when using ProSim). Also, please check in ProSim. I don't use ProSim (although Pete does, the original author of FSUIPC)m but was under the impression that ProSim provides its own assignment and calibration facilities these days, so you may be worth switching to them, or at least checking that they are not interfering. Ask about this on the ProSim forums (or maybe try a different rudder axis control to see if that helps). John

Sorry but it is difficult to understand what your issue is. Is this with software that you have written using Paul's .Net client dll? If so, when you get the issue, can you still use lvars via FSUIPC or using the WASMClient? Basically you need to determine if the issue is with your software or if the WASM has crashed. So please do that. If the issue is with your software and you are using Paul's .Net client dll, I cannot help you, and you need to post in Pail's .Net dll client forum: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ That is also a question for Paul's forum. Many of your posts are very difficult to read and it takes a lot of work just to try and understand them. I understand that this may be a language / translation issue, but please take care to post in a format that is at least readable...e.g. at least no scroll bars please.... And this is VERY important: One of your FSUIPC clients is requesting lvar updates (via WAPI ini parameter LvarUpdateFrequency) - you should remove that/set to 0 and let the WASM control all updates. You MUST make sure that any/all clients are NOT requesting lvar updates as this should be controlled by the WASM, not the client(s). John

The source is provided so you can recompile it with the latest compiler. However, I did recompile this recently (for FSUIPC7), so I have attached this below. Sorry, but I just don't have the time to provide an example. I have never used most of the provided SDKs and they are provided as-is, and most donated by other authors. You need to first write the new value to a user offset (e.g. 0x66C0) using FSUIPC_Write, then write the offset address used + the value format (as described in the offset status document) to offset 0x0D6C (again, using FSUIPC_Write), and then the lvar write request, which would be "::ASD_SWITCH_EXT_POWER", to offset 0x0D70 (using FSUIPC_Write), and then call FSUIPC_Process to apply. Note that the only supported SDK is the .Net / C# one provided by Paul Henty - there is a sub-forum for this interface: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ UIPC64_SDK_C_version2.zip

Your log file show s that FSUIPC wasn't even connected to MSFS and was attached when FSUIPC7 was still running: Nothing is going to work if FSUIPC7 is not connected to the FS. And please, ALWAYS exit FSUIPC7 BEFORE attaching files. How long does it take for MSFS2024 to get to the main menu after starting? You may need to trim the start-up parameters - see the Advanced User guide or the followig FAQ entry: If FSUIPC7 cannot get a connection, this is usually due to other badly behaved add-ons using up all available connections. What other add-ons are you using? Also, please at least check your log files if you have issues, and always check them before sending them to me. That one is useless.

Rather than using LuaValue and event.param, switch to using flags. Change the event.param call to use event.flag, and add 1 call for each flag used (the flag replaces the feed_value/ ipcPARAM value): -- -- 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(flag) currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) if flag==1 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 flag==2 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 flag==3 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.flag(1,"updateNav1") event.flag(2,"updateNav1") event.flag(3,"updateNav1") event.flag(4,"updateNav1") ipc.log("Nav1 update lua script now running") Then write the flag value (1,2,3 or 4) to offset 0x0D6C, and use the LuaToggle control when writing to offset 0x0D70. John

I can see the issue - I will do some testing here and get back to you, John

Check your InstallFSUIPC7.log file. You will probably see that the installer detected a steam version as you have a UserCfg.opt file in the location used by a steam installation. If that is the case, uninstall FSUIPC7, delete or rename the steam UserCfg.opt file and then re-install and it should detect the MS Store version. The FSUIPC7 installer determines the version based on the location of this file, and checks for Steam first. Also, please give your posts and appropriate title, and nothing generic such as 'please help'. I will update this time. John

No, sorry - I don't have the Fenix. Is it the same aircraft or a different version for MSFS2024? Is this for all assignments? How have you assigned - using presets? Are you using the same or different installations of FSUIPC for MSFS2020 and MSFS2024? Have toy looked at the logs to see what is happening? It could be due to many things (e.g. is the WASM installed in MSFS2024?) and you should check further and at least provide more information, including logs (with appropriate logging activated) and ini files. It could be the configuration, but it could be that the aircraft uses different controls in MSFS2024.

You will need to use one of the C SDKs. To update an lvar, use offsets 0x0D70 and 0x0d6C

You can start MSFS via steam or however you like. The default auto-start is via the EXE.xml file, although you can select to auto-start via the bat file. By default, the desktop icon(s) installed by the installer just show a splash crean and call steam to start MSFS. If you are using the EXE.xml auto-start and dont want to use the installed desktop icon to start MSFS, you can opt not to have this installed by unchecking the checkbox at the end of the installation process. John

The easiest way to control an lvar (in P3d with FSUIPC5/6) is to use a macro - see the documentation. John

This video is interesting, and shows how to get the visuals working using Spad.nect and vJoy: You can also use that to set-up with FSUIPC and vJoy using vJoyOffsets. which would be mapped to a vJoy axis that is assigned in MSFS. Its a bit of a fudge, as you have to assign a vJoy axis in MSFS, as well as two buttons. You then assign in Spad.next/FSUIPC to control the vJoy axis and buttons. The throttle axis would write its value to an FSUIPC offset (mapped to the vJoy axis), and the prop-pitch range assignments also trigger the vJoy buttons via offsets. I could set that up here and let you know how that works if interested. That set-up uses a Bravo (which I also use on my flight PC), so it has detent buttons on the throttle & prop axes to move into reverse and cut-off. The set-up would be different if the axes being used didn't have detent buttons (as my X55 throttle I use on my dev set-up). You would either have to use a separate button or maybe an additional axis range to do that. Also, as that post is also a couple of years old, it is not clear if that set-up would still work, but I suspect so as it basically uses MSFS to control the visuals.

Testing further, the FUEL_Manual_Override input event works fine to control the manual override lever. However, I get very strange results when trying to use the ENGINE_Throttle, input event on an axis. Sending any positive value, however small, seems to set the value of 13% and just switches the throttle to the feather side, with 0 switching it back to the taxi side. Basically it is the same as setting the ENGINE_Throttle_Feathering input event to 1. So looks like the throttle visuals still can't be controlled correctly. As well as sending 8192, try setting the unput event ENGINE_Throttle_Feathering to 1 which should move it to high idle.

Currently all simvars are requested during initialsation, after FSUIPC has obtained a connection to the FS. The problem with such a feature is that the whole way that simvars are requested would need to be change, as this would have to allow for updating the data definitions (plus the internal data structures that map simvars to offsets) dynamically, which would be a huge change. This is probably possible but would require a complete re-design of how this currently works, and I just don't have the time (and probably never will) to consider such a change. You should consider just distributing your myOffsets.txt file with the application, or write or update that file when the app is installed. Of course, there is always a possible issue if the offset was already being used for another purpose. But this would apply when the simvars are requested via offsets as it applies when requested via the myOffsets.txt file. There is another method that can be used to get the value of any simvar - write the value to an lvar and read the lvar. This involves an extra step in writing the simvar to an lvar, which can be achieved via executing some calculator code of the form: (A:someSimvar) (>:L:mySimvarLvar) and then read the value from the lvar L:mySimvarLvar. But doing this, you would need to write the a:var/simvar value to the lvar every time before you read the lvar to make sure that it holds the current value, and there would be a slight delay before the updated lvar value would be available in FSUIPC. John

Have you tried the input events: ENGINE_Throttle : range 0-100 FUEL_Manual_Override : range 0-100 ENGINE_Throttle_Feathering: 0 / 1 ? I set-up a few buttons to test these, and these DO control the visual position of the throttle and manual override lever: This is just for testing, but shows that the visuals can be controlled. The TBM930 throttle has always been tricky to set-up using a standard throttle controller, and you probably also need to assign a few buttons, maybe for switching to feather and also to engage reverse and enter cut-off. You can most probably achieve something reasonable using a lua script. and assigning your axis to an FSUIPC offset and then embed the throttle logic in the lua script to send on the appropriate input events and FS controls as needed. I will take another look at this, but I will need to understand and review how this throttle is supposed to work first. Could you at least share your current assignments and I can use that as a starting point. John