John Dowson

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.

Sorry, I left those in by mistake... This is your [JoyNames] section - please delete the entries in bold: Every device should have 4 entries - a name and GUID entry with a number, and a name and GUID entry with a letter.

First, try logging the offset to see if it is actually being used. The aircraft model is probably not using the CABIN SEATBELTS ALERT SWITCH simvar which is what that offset holds. Check to see if there is anything else available - usually an lvar or input event. If so, you can use that, and also add it to a spare/free offset if required. You can even spoof the reading of offset 0x341D to the new offset if needed.

0x0D6C is 4 bytes, not an unsigned byte. But this is absolutely not necessary and even detrimental - please remove that. It is writing to offset 0D70 that triggers the action. This makes me think that you are not quite understanding the change to use events and LuaValue. Previously, MobiFlight started the script with the Lua command, and the script read the value from the offset. What should happen now is that the script is always running and waiting for a signal. This comes by calling LuaValue on the script, and the parameter to that call is the feed value. If you are still invoking the script with Lua, then you are killing the running script and restarting it and not passing in a value. So, please check how you are invoking the script from MobiFlight - this MUST be with LuaValue, and the parameter/feed value written to offset 0x0D6C first. And the log file doesn't show much as there is no lua plugin debugging information. So please add that, or you can also add some ipc.log statements to log what is happening. So first try and determine what is happening - is the correct feed value actually being passed to the script? If you need further help (but please try yourself first...), attach the files with the correct debugging enabled. As you have lots of lua scripts running, better to also log lua plugins separately, and also attach the plugin log, as well as the plugin itself.

Ok, but I wouldn't recommend this. Better to sort out issues with the EXE.xml auto-start if possible. And when using either, if you get any connection issues or too many retries (check your FSUIPC7.log file if you have issues - in many cases, this will indicate where the issue is...) then look at tuning the FSUIPC start-up parameters (described in the Advanced User manual, and there is a FAQ entry for this in these forums). That is fine. I am actually thinking of making CONNECTED the default for starting programs, and add a new option EARLY (or maybe START) to start programs after FSUIPC has started (i.e. the current default). This is because that it looks like quite a few add-ons don't handle the connection stall times, timeouts and reconnection gracefully, which can starve the FS of further simconnect connections if not handled properly. So always better to start such programs after FSUIPC has obtained a connection. No problem. Saludos, John

Ah, ok - that is useful to know. No point attaching screenshots though really - the quality is too low to see anything and files and description of the issue are always preferred. What does this mean (3d)? The log shows a close-down message: So it looks like the FSUIPC main thread is hitting a race condition. Very strange, especially as you are the only one reporting this. Could you show me / attach your FSUIPC7.ini file please (although it may be in one of the zip files already attached...). I am going to need to see more logs with additional logging activated, but not sure what yet...I will get back to you tomorrow (or maybe Sunday)... John

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.