John Dowson

I don't see any preset available for this. You can ask the guys over on MobiFlight discord server (MSFS2020 channel) if they can help with a preset for this, or take a look yourself at the switch behavior (using the MSFS development tools provided) - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ I don't have the Fenix so cannot look into this, sorry. John

FSUIPC should always exit cleanly really, and if not you should report and show me your log file. Please activate logging for Extras, and attach a your log file if it is not closing properly. But if its not in the task manager, its not running.... FSUIPC creates a named mutex when started and removes this when exited. It could be that the mutex is not being destroyed for some reason, which will give you the message "There is a copy of FSUIPC7 already running. This process will now exit." if trying to start it again. There is also no point in posting about any issues if you are not attaching the files so that I can investigate. I may require additional logging and more files, but it is always a good idea to attach at least your FSUIPC7.log file when you have a problem which at least gives me some basic information that I can use.... There is one known issue that can cause shutdown issues, which is when running lua files that have a com connection, but there are also known ways to handle this. John

Then it is EFB2 that needs updating. EFB2 is probably checking offset 0x3308 (or maybe offset 0x3124) for the simulator version. Previously that held 13 for MSFS2020 and was populated on FSUIPC7 start-up. Now it holds 13 for MSFS2020 and 14 for MSFS2024 and is only populated once connected to MSFS. You should check for an update to that for MSFS2024. John

Thats interesting, thanks. I was going to report this week but I will now wait for the update. I will just add a comment to that for the time being. Cheers, John

@LukaszMusiol Please try the attached version, 7.5.1a (beta). In this version I have added an additional control "Rescan Connected Controllers" (1157). John FSUIPC7.exe

If its ok with that version but not working with the latest release, could you send me/attach the log files from both as well as your FSUIPC7.ini and I will take a look. John

Only a limited number of simvars are added to FSUIPC offsets, and oxygen mask test certainly won't be one of them - there doesn't even exist as a simvar for this as far as I am aware, What aircraft are you using? First look to see if there is a preset available for this, and if so you can use that. If its a PMDG aircraft (or one that has custom controls), then also look at the aircrafts SDK to see if anything is available. If you let me know what aircraft you are using I could maybe advise further. John

Sorry but can you please five your topics a more appropriate title... I will update it... 7.4.18 attached below - save and remove the .7418 extension... John FSUIPC7.exe.7418

Please note that Pete retired over five years ago - no point in tagging him, especially for FSUIPC7 issues. Why did you attach a WASM log file? that just shows that MSFS was running for only 6mins12 seconds, you didn't even start a flight, and the WASM exited when you closed MSFS, as it should. I am not sure what your issue is, if any - first you talk about button presses not being recognised, and the title of this topic is 'closing but not closed', whatever that means. If FSUIPC is not exiting properly please show me / attach the FSUIPC7.log file from that session and explain what you did / how you closed or exited. There really is no point on posting log extracts. John

This is normal. Many MSFS aircraft, especially complex add-ons, seem to continually be emitting certain events, and these events are different for each aircraft. FSUIPC just reports what is being sent to the FS. You can ignore such events by using the DontLogThese ini parameter (best used in a Profile section, as such events are aircraft-specific, but otherwise in the [General] section if not using profiles). Please see the Advanced User guide for details on this ini parameter. John

Ok, thanks for letting me know and reporting this. There is not much I can do though. Hopefully they will update and add an exception for this. Cheers, John

Forgot to update that - done now, thanks. John

If FSUIPC7 doesn't see the device again, then its not getting any notification from windows. Not sure if there is much I can do about this, and I am not going to add anything automatic to do this other than what it does at the moment, which is re-scan when windows informs it of a new device being connected or re-connected. I could add an additional FSUIPC control that, when activated, will re-scan for devices. You could then assign this new control to a keypress when the Tarantula loses connection. Would this be ok? By the way, you posted in the main support forum. For any/all issues with FSUIPC7, can you please use the specific FSUIPC7 support sub-forum. I will move this post. John

They are input events, not custom controls. To assign a key press to control input events, you have to check the Select for Input Event checkbox. Also a good idea to check No repeats! for most input events. John

Looks like your WASM is crashing. This is a known issue documented here: I thought I had disabled continual lvar scanning in this release but looks like I included the wrong ini file. I will rebuild the release and change this (tomorrow now, but will be same version). Just change the following parameters in the FSUIPC_WASM.ini file located under ...\Community\fsuipc-lvar-module: LvarScanFrequency=0 LvarScanDelay=8 John

Yes - please see the section called FSUIPC7 Hot Key in the FSUIPC7 User manual.

This sounds like windows is putting the device to sleep. To prevent this, you need to uncheck the 'Allow the computer to turn off this device to save power' in the Power Management settings of your USB Hubs in the' Device Manager. Windows also has a habit or resetting these settings.

Do you mean that the 'Assignments' menu is not visible? If so, this means that you are using an unregistered version. If you previously registered, then you probably re-installed in a different folder. If you are using the trial key. oy has probably expired. Otherwise, please explain what your issue is in more detail. There is no change in assignments between 7.4.18 and 7.5.0. John

Maybe... There are certainly issues to consider with live weather when adjusting the sim time, and I am not sure how MSFS handles this. There are also issues with live traffic - I am also not sure how this is handled if you are changing the current time... Historical weather is certainly available, but I don't think this is available for traffc! Presumably live traffic is turned off if you change the time, or maybe you can't change the time if using live traffic (and maybe weather)...

Could you send me or attach the update files (presumably FSUIPCuser64.lib, UIPCHello.c and UIPChello64.exe) and I will include them in the next release. Saves me some time having to look into this...thanks. John

I turned off on-line services (weather and AI traffic) and after doing this I can set the zulu hours and minutes in offsets 0x023B and 0x023C. Setting the hours seems to work (i.e. it goes from day to night in the sim) but the offset gets reset but the sim stays in night for some reason, And, as with offsets 0x0238 and 0x0239, setting the hours resets the minutes, and setting the minutes resets the hours. Very strange...! This works as expected in MSFS2020 (where setting zulu time also updates local time and vica versa), so its definitely an issue with MSFS2024. I will report to Asobo.

Also offsets 0x0238 and 0x0239 (which use the CLOCK_HOURS_SET and CLOCK_MINUTES_SET events) also have issues in MSFS2024 whereas they work ok in MSFS2020. I can set the hour, and it seems to work. However, when I then set the minutes, the hours go back to its original value, but the minutes are updated. In fact, setting one seems to reset the other (back to zulu values), and the zulu times are also not updated.

Really? That is interesting - how are you setting the local minutes? I have checked offsets 0x023B and 0x023C and writing to those in MSFS2024 doesn't change the hours/minutes, as reported here. I have also tried switching to use the CLOCK_HOURS_SET and CLOCK_MINUTES_SET events (they currently use ZULU_HOURS_SET and ZULU_MINUTES_SET) and they don't work either. Checked in MSFS2020 and they are still working there. There is not much I can do about this at the moment except report to Asobo. I will update the Offset Status document for FSUIPC7 to mark these as read-only for MSFS2024 for the time being. John

No - no tengo tiempo para esto, lo siento. Si quieres ayuda, debe hacer lo mismo que todos los demás: explicar su problema y publicar/adjuntar archivos. John

No, no point. This is nothing to do with FSUIPC if your devices are controlled by the Cpflight plugin. Has that been updated yet for MSFS2024? I only support FSUIPC, not CPFlight. John