StreamDeck GSX interface sometimes not responding
Closed this issue · 14 comments
Hi,
i need some help or some ideas what might cause the following issue
- Im using PilotsDeck, GSX on the Fenix.
- Your Fenix Profile is used for PD, and Fenix2GSX... all of them are latest versions.
Today i had only 1 Flight on which the StreamDeck Buttons for GSX worked when pressed... on all other flights... the button are recognized by FSUIPC (i can the the triggered action on the FSUIPC Conole Output).... But it doesnt trigger the requested within MSFS... e.g. pushback directions or the choice of a gate after landing ....
it worked fine and without any issus until last week?!
if have no idea, why the triggered actions by pressing a button on the streamdeck are recognized by FSUIPC but not turned into an action... Fenix2GSX works fine bzw ....
I have no idea.... are any issues between "Fenix2GSX <-> PilotsDeck" possible or a change you made between the last version of Fenix2GSX and the one before (nothing listed in the changelog which could be problematic... but sometimes, something has sideaffects...)
Thanks a lot in advance
Maybe the issue can be closed ...
Found this in the fsuipc log .... would make sense if this is the reason for the issues..... i take a look into the lua files... (but they are up-to-date (thats why i asked for version 1.2 on flightsim.to ;) and theese are the 1.2 ;)
14985 Subscribed to InputEvents (30 found)
15032 LUA.1: Pax-String at Offset 0x4510:5:s
15032 LUA.1: Cargo-String at Offset 0x4516:6:s
15047 LUA.1: State-String at Offset 0x451D:16:s
15063 LUA.1: SimObjects\Airplanes\FNX_320_CFM\aircraft.CFG
15078 LUA.1: comparing 'fnx-aircraft-320' with 'SimObjects\Airplanes\FNX_320_CFM\aircraft.CFG
15094 LUA.1: no match
15110 LUA.1: comparing '787' with 'SimObjects\Airplanes\FNX_320_CFM\aircraft.CFG
15125 LUA.1: no match
15141 LUA.1: comparing 'FlyByWire' with 'SimObjects\Airplanes\FNX_320_CFM\aircraft.CFG
15157 LUA.1: no match
15172 LUA.1: comparing 'inibuilds-aircraft-a30' with 'SimObjects\Airplanes\FNX_320_CFM\aircraft.CFG
15188 LUA.1: no match
15250 LUA.1: GSX_AUTO - Script active
15782 LUA.1: GSX_AUTO - Menu-Line 0 at Offset 0x4300:48:s
15813 LUA.1: GSX_AUTO - Menu-Line 1 at Offset 0x4330:48:s
15844 LUA.1: GSX_AUTO - Menu-Line 2 at Offset 0x4360:48:s
15875 LUA.1: GSX_AUTO - Menu-Line 3 at Offset 0x4390:48:s
15907 LUA.1: GSX_AUTO - Menu-Line 4 at Offset 0x43C0:48:s
15938 LUA.1: GSX_AUTO - Menu-Line 5 at Offset 0x43F0:48:s
15969 LUA.1: GSX_AUTO - Menu-Line 6 at Offset 0x4420:48:s
16000 LUA.1: GSX_AUTO - Menu-Line 7 at Offset 0x4450:48:s
16032 LUA.1: GSX_AUTO - Menu-Line 8 at Offset 0x4480:48:s
16063 LUA.1: GSX_AUTO - Menu-Line 9 at Offset 0x44B0:48:s
16094 LUA.1: GSX_AUTO - Menu-Line 10 at Offset 0x44E0:48:s
16188 LUA.1: GSX_AUTO - Refreshing Menu (Startup)
16438 LUA.1: GSX_AUTO - Opening GSX Menu
16469 LUA.1: GSX_AUTO - Automatic Service Calls: Refuel and Catering
What Livery was that?
It is a bit strange the Path is only relative and not absolute in your Logs. Is that the MS Store Version maybe?
Try the attached Script. Does also contain a Fix not released yet (jumping to Taxi-In State due to Reposition).
(It as the Ending .txt to upload it, remove that! Also remember to change the Path in the File.)
GSX_AUTO.lua.txt
Well ....
MS Store Version, Livery is https://de.flightsim.to/file/33507/lufthansa-d-aiqs-w-cabin-fenixsim-a320-8k
But, it dont think it an issue with the lua file, or the naming conventions etc, because: Its working just once:
First Try.... running MSFS without Fenix2GSX started -> SD Buttons work
Second ... running MSFS with Fenix2GSX started -> SD Buttons dont work
Thrid try... removed Fenix2GSX AutoStart from FSUIPC.ini .. i thought after MSFS has been quit and restated, no Fenix2GSX will run on the third try .. but, it was running as a "background task" , the icon in the taskbar is unresponsvie, means i cant right click on it or left klick on it to get the window up in the foreground
(see this short clip)
https://github.com/Fragtality/PilotsDeck/assets/42810795/ed260569-7f0d-4e3a-97bc-2012c52340c1
Maybe it has something to do with my conclusion on the fourth try:
Fourth .... this time i made sure, no Fenix2GSX is running anymore before starting..... but .... nothing.......
As i said on my opening post: It just work once ....
There must be something remaining left after MSFS has been closed, something that prevents the SD Buttons for GSX to work when MSFS will be started again (without rebooting the PC)
(After rebooting... fifth try: Its working...)
I attached my FSUIPC logs ... one working, one non-working.
NON-WORKING_FSUIPC7.log
WORKING_FSUIPC7.log
The Difference is: when it is not working, the Script does not receive the Ready Event from GSX (EXTERNAL_SYSTEM_TOGGLE).
Don't know what the Cause of that could be - if that is GSX not working correctly and sending that Event or if it is FSUIPC not receiving that Event / calling the associated Lua Function.
Is your GSX Updated (2.9.6 is current)? Did you run a "Check" in its Installer?
I think its up to date .... GSX is the only piece of software i know or ever had installed that has a weird way to update .... i could run live update 24/7 on each new run it is downloading something .... but, the version is current.... on top i run the extra download file before after each live update run .... my only hope is, after mostly 3 rounds of downloading whatever its really up to date.....
ill give it a try...
Have you ever seen this coutl64_boot.log file ?
Its strange ... will ask in the fsdt forum
I never looked into it, if you mean that.
But of course I've saw it, since it belongs to the Changes made in 2.9.6
So I'm facing the exact same Issue - the GSX_AUTO Script not working properly because it does not receive the EXTERNAL_SYSTEM_TOGGLE Event. Persistently, even after Reboots. And not on the Fenix but on the HS787.
So it seems it is a general Connection Issue with SimConnect. Just disabling Fenix2GSX does NOT solve the Problem. It has something to do on with when the Addons are started and in which Order. So it seems just a Coincidence that closing Fenix2GSX does something for you. For me it helped to exit FSUIPC, wait, Restart Couatl and then start FSUIPC again.
I don't know if that is now an Issue of MSFS, GSX or FSUIPC. I don't think that either Support will find any Solution/Workaround/Fix. I'll just try different Orders & Ways to Auto-Start my Addons to find a Combination that works.
If I would need to bet ... it is GSX. I started it for a looooong Time via FSUIPC, since it always come up with the "infinite menu" when started via EXE.xml. So maybe it does something wonky again with this new Watchdog (couatl64_boot) ...
Yes, i was thinking about the right order as well today... when i restart gsx, then quit fsuipc it works... but, its not ideal because SD or PilotsDeck dont come back, so i have to restart SD aswell....
im with you it has something to do with gsx coutl64_boot ... but convincing virtuali isnt the easiest in the world ^^ ... it worked before (ok crashed sometimes, but not a big deal as long just to restart gsx and not FSUIPC, StreamDeck etc pp to get it back to work)
Yes, i was thinking about the right order as well today... when i restart gsx, then quit fsuipc it works... but, its not ideal because SD or PilotsDeck dont come back, so i have to restart SD aswell....
Depending on how long it takes, that might be the Case. But in most Cases it should be enough to go into the MSFS Menu for 1 Second and then back in order for PilotsDeck to come out of the Wait (...) State
im with you it has something to do with gsx coutl64_boot ... but convincing virtuali isnt the easiest in the world ^^ ... it worked before (ok crashed sometimes, but not a big deal as long just to restart gsx and not FSUIPC, StreamDeck etc pp to get it back to work)
I mean you could confirm it rather easily if you modify the EXE.xml to start couatl64_MSFS directly again and see if it makes a Difference
Ah dint know going to the menu gets PD awake again! thx...
It always has been inside my exe.xml
Ah dint know going to the menu gets PD awake again! thx...
No Problem, it is some kind of timing Issues in this very special Situation. Did not really look into fixing it yet, since it does not really impede normal Operations ^^
It always has been inside my exe.xml
couatl64_MSFS not anymore. It should have been changed to couatl64_boot with GSX 2.9.6 (see the Changelog Entry I posted)
FYI: Seems to be a FSUIPC Issue!
https://forum.simflight.com/topic/98295-new-fsuipc-update-kills-simconnect/
Just tried with the attached exe File and a ConnectDelay of 300 and it worked. Now I only have to fine tune that Value down, since that is too long for my System - I was already loaded at the Gate before FSUIPC really got active 😅
Thanks!
What makes it difficult that the value is a constant and sim loading times are not always the same.... maybe its the value can be set as a parameter when restarting (dont want to wait 300 (or whatever on a fsuipc restart while msfs is running...) ... will see...
The .11 Version was officially released by now.
The Loading Times are normally the same unless new Stuff is installed or the Scenery Index&Cache are cleared..
Sure it is about delaying the FSUIPC Startup, but not to the Point where the Session is already running. 300 was just a starting Value for a Proof of Concept. The second Try with 90 already was spot on.