John Dowson

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

Are you using the latest beta of FSUIPC7 which has added support for MSFS2024? If not, please update to that version. See If using that version, please post any issues in that topic until I release this version officially, and make sure to at least include/attach your FSUIPC7.log file. John

Yes, as these devices are not assigned in FSUPC, in fact you have no assignments at all, it cannot be anything to do with FSUIPC. Your MCP and Efis are not even detected by FSUIPC. The log file you attached when FSUIPC7 was running and ends after 3-4 seconds and shows nothing. Please ALWAYS exit FSUIPC before attaching any files. John

¿Puedes decirme cuál es el error? Además, adjunta tu archivo FSUIPC7.log. ¿Estás usando un add-on para el StreamDeck? Si es así, comprueba que se haya actualizado para MSFS2024. Consulta:

No need for a screenshot. This sounds like your device has gone to sleep (as the button press is not recognised) - check the USB hub properties in device manager. Otherwise, please show me those files with the logging activated.

Both log files look ok and show that FSUIPC7 was running and had not crashed. When this occurs, can you operate in the FSUIPC7 main window? i.e. does Alt+F open the main window, and can you then open the assignments windows and use those? If so, can you see the assignments you have bound to the switch? Is the switch/button recognised? The WASM log looks ok, and shows that that didn't crash. You do have a few reconnection attempts at start-up, although this is nothing to do with the issue you are having, To prevent these, can you please set/update to the following in your FSUIPC7.ini (in the [General] section): DetectToConnectDelayAuto=90 InitialStallTime=45 StartUpTuningDoneVersion=-1 For your issue, can you please activate logging for Buttons & Keys, Events, Extras and WAPI Debug level logging, and the next time this occurs first open FSUIPC7 and the assignments window and press the button (presumably not recognised?), then exit FSUIPC7 and send me/attach your FSUIPC7.log and FSUIPC7.ini files. Then restart FSUIPC7 and try again. Does it now work? Presume so (from what you said), but if not, please then exit MSFS and show me / attach your FSUIPC_WASM.log file. Also please check the power settings on your USB devices and hubs, and make sure Allow the computer to turn off this device to save power (under Power Management) is disabled. Windows has a habit of resetting this setting for some reason... - John