I have issues with my external app when it is started by adding an entry to the EXE.xml file. The main issue is that when my application is started via this method, it runs approximately 13x slower than when it is manually started. Is MSFS starting the threads for these apps at a reduced priority level, and if so why? Can anything be done about this, or should I look into other methods of starting my application?
The second issue is that programs started via the EXE.xml are started far too soon, and it can take quite a while before my applicaction can acquire a simconnect connection. The time waiting for a connection seems to depend on the total start-up time (i.e. the time it takes for MSFS to arrive to the main menu)., which is again dependent on the number (and time taken) to start the Community add-ons.
This can cause issues as if my application cannot connect within a certain (configurable) time limit, it will close the connection and attempt to reconnect. A small number of re-connection attempts is not really an issue, but if it is attempting to re-connect many times (i.e. 30, 40 and above) then this can then starve SimConnect of available connections (as SimConnect connections in the connection pool are not re-used - a long standing issue with SimConnect!).
Would it therefore be possible to delay the start of programs from the EXE.xml until all Community add-ons have been fully loaded, or at least until MSFS is ready to respond to a simconnect connection request within a reasonable amount of time (e.g. 5 seconds should be plenty!).
Are you able to at least open Simconnect, even if you can’t do anything with it yet ?
If yes, are you calling the Simconnect Dispatch explicitly, so you are running a main infinte loop?
If yes, try setting up a Dispatch callback instead, and in your Dispatch, wait for the SIMCONNECT_RECV_ID_OPEN event, and do the rest of your subscription there when the event arrives.
After you received the OPEN event, start monitoring the CAMERA STATE variable, and don’t do anything as long its value is 11 ( Waiting ), so you don’t risk trying to call Simconnect during the loading screen, where it might not yet read to respond properly, because is still loading other modules and packages.
Your response seems to be related to another issue I raised, not this one… what has your response got to do with the performance degradation of applications started via the EXE.xml? Why would the general performance of an application (and I am not talking about the data reception rate here) be reduced just because the app has been started by MSFS? Do you do anything with the thread priority levels for such applications?
Sometimes yes, sometimes not. If I do not receive a response from the open call in a defined period, I close and reconnect. If I receive a response within the required time-limit, I then define my data, request sim events and the user object, and wait for the user object response to be retuned before I request data. Sometimes the user object that is not being returned within the required time-limit, and this is due to another issue I have raised (random simconnect disconnect issue). This can happen regardless of when my app is started, and is not related to the performance degradation I reported here.
I use both methods - an explicit call to process the request of the user object, and I then enter an infinite message loop for the main dispatch thread. There are no issues with my message processing.
I don’t see how this can change things - my dispatch loop is running and running fast enough to process responses. Why would starting my app manually and having it started via the EXE.xml make a difference here? I do not request any data until the SIMCONNECT_RECV_ID_OPEN event is received.
I also don’t see how this can help with this issue (which is related to the performance when external apps are started via the EXE.xml method). I do monitor the camera state variable, and use this to trigger the start of many things, but not the data requested. This is all done once the open response has been received.
In theory, I could request this first in a separate data definition, and request the remaining data once the camara state is non-waiting, but I fail to see how this can affect the performance degradation I see. Can you explain please?
Can you not delay the starting of programs from the EXE.xml until these other modules and packages have been loaded correctly to prevent such issues? But this would only help with the second issue I reported here, not the performance degradation issue which I don’t see how can be related to the start-up timing…
Re-reading your response again, I think it was related to the second issue I mentioned, not the first and most important - the performance degradation. For the second issue, simply delaying when EXE.xml programs are started would fix this. But this is only a minor issue - I can (and do) correct for this in my app by delaying the time between when my app detects MSFS and when it connects, and also adjusting the data stall rate (i.e. the time between requesting data and receiving a response before I take action). However, it would be an improvement if programs could be started later in the start-up process, as already mentioned.
You said your app is running a lot slower when is started from the EXE.XML, so my reply tried to answer that, because a reason why it “seems” to run slower, is not that is really running slower itself, but it might just Simconnect not ready to respond, which seemed confirmed by your report you had to add wait time before you could use it.
No, I never noticed ANY difference if my external Simconnect .EXE is started from the EXE.XML or not, zero. The one and only issue I found is that in some cases, the simulator won’t start automatically from the EXE.XML if the apps is run As Admin, which my app doesn’t need to begin with, so it’s not really an issue.
Neither I ever had any failure to first connect to Simconect: my app always connects at the first try. HOWEVER, if I try doing something before receiving an _OPEN event, it might fail, and even after I receive an _OPEN event, it can still fail if it’s still on the Loading page. This really depends how many other modules are being loaded, and how many packages in general, and on the PC speed as well.
Which is why, I suggested waiting for the Camera to exit from the “Waiting” ( = 11 ) State before doing anything significant with Simconnect. This method is more reliable than just waiting for some amount of time you can’t be sure of, because no matter how many tests you do locally, you’ll always find an user which installed an insane amount of package with a sim that takes 10 minutes to start, so it’s realty impossible to anticipate a delay time that would work everywhere. Hence the suggestion of monitoring the camera statre instead, possibly together with the “Flight Loadedf” event.
It is the general performance of the app that is slower, not necessarily the data reception. I notice this more in other threads, not the main message processing threads.
I can start my app before I start MSFS and I don’t have issue. Or after or even during the start-up process and there are no issues. This performance issue does NOT depend on when my app is started. It only happens WHEN it is started by MSFS, via the EXE.xml. This is why I presume this issue is related to thread priorities, and not simconnect message processing.
If running EXE.xml programs as admin, you would also have to run MSFS as admin.
Wow, that is interesting…if I try and connect as soon as my app is started by MSFS, or withing 30 seconds or so, I receive no response (at least not within the required time limit, which was defaulted to 45 seconds).
I know, I do not do anything with the simconnect connection until the _OPEN event is received. Once this is received, I set-up my data definitions and client event mapping. I then request the user object, and wait for a response to this before I request any data.
As I said, I do use the CAMERA STATE for many things, just not data requests (as requesting this IS a data request!). I also rely on receiving the user object BEFORE I request data, and I also use the sim state and flight-loaded events.
But I fail to see how this has anything to do with the general performance of my application. As I said, I am not talking about data reception with this issue, it is general performance. I see this mainly in other threads that I start, and these do not use simconnect (only my main thread does that, due to the long standing issue of SimConnect not being thread-safe). These threads are running a lot slower when my application is started via the EXE.xml method. I cannot see how this has anything to do with simconnect messages, and think it is more likely to do with thread priorities or thread property inheritance, which i am not too familiar with in a windows environment.
But thanks for your response.
John
P.S. Maybe I should have raised these two issues in separate support requests as there seems to be some confusion…sorry about that!
I have checked the performance again (of programs started via the EXE.xml) in the SU15 release and this is no longer an issue.
I still think programs started via the EXE.xml are started too soon though, as it can take quite a while to obtain a simconnect connection once started.