John Dowson

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

I think you mean log file, not ini... This is not a problem - but the current max allowed value is 8192, so if you need the additional higher event numbers then set it to that. But be aware that this parameter defines the maximum allowed number of custom events which are loaded from event files (*.evt). There is no real need to use these anymore but this is still provided for backwards compatibility. What you may need to increase is the MaxCustomControlNumber ini parameter, which defines the custom control number range allowed by FSUIPC. This does need to be increased for some aircraft. Cheers, John

Maybe also see

Yes, there are only 4 standard throttle controls/events. However, if the aircraft has 6 engines, then aircraft should provide a way to control them which FSUIPC can use, such as lvars or input events. You can try FSUIPC7 before purchasing, to see if it suits your needs. There is a trial license available in a post at the top of this form. John

Maybe, I don't know though - why not just try it? I don't know if lua supports "0b" for binary, but should be easy to write a quick script to test / check this. Me neither - it would be in the general Lua documentation, not in FSUIPC's documentation. But I would think that it would be 0b, and if that doesn't work then it isn't supported. John

Could you please add the following to the [General] section of your FSUIPC7.ini file: TestOptions=x800 LogCustom=x16 You also have a very high value set for MaxNumberOfCustomEvents (12288). The maximum value for this parameter is 8192. Shouldn't be a problem (I will test here), but you should reduce that - or is there a need for it to be so high?

Yes, as is the FSUIPC offset documentation for offset 0x0D70 (which is where that comes from). As I said, this is an omission error but it works - as I keep saying, you MUST use LuaValue, and not just Lua. Please read the FSUIPC offset documentation if using FSUIPC offsets (via MobiFlight). But using what - Lua or LuaValue? It is not error logging (errors are always logged), but debug logging you need. This will show you every line executed in the lua script. Event.param does not monitor for value changes, but is called whenever LuaValue is called on the script, using the parameter provided, which when called via 0x0D70 will be the value in 0x0D6C. The ONLY thing you need to try is using LuaValue to call the script.

Ok, that is interesting. This would imply that the Discord app now uses keyboard scanning to detect keys rather than windows messages. Thanks for the update. John

Was that also the case with the first log file you attached? That was from a session over 2 hours long, shows continual logging from the main thread, and also shows that FSUIPC exited cleanly after detecting that MSFS had exited. So looks very different from those last two logs. I will get back to you later with additional logging to try.

I have moved this post to the FSUIPC sub-forum. TrackIR does not use FSUIPC. This is usually because you are using the same aircraft but with a different livery, and you are not using sub-strings for your aircraft profile names. When you create or add an aircraft to a profile, the full name/title is used, which can include the livery name and tail number. So if you load a different variant, it doesn't match the previous name and you have to add it again. Yo resolve this, you should always edit the ini file and shorten the aircraft name used in the [Profile.xxx] section to the shortest string that matches all the variants for that aircraft. See the documentation for further details. If that is not the issue, then please attach your FSUIPC6.log and FSUIPC6.ini files the next time this occurs (and please exit P3D/FSUIPC before attaching files). @Paul Henty I don't check your forum often, so if you see a post there that should be in one of the other support forums you could tag me when you respond to the OP and I can move the post to the correct place.

Just run the installer.... You can install in the same location as for MSFS2020 (i.e. one installation for both versions) or you can install a separate version for MSFS2024. See the installation manual for details.