John Dowson

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.

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