I appreciate your willingness to help, but it’s not the reliability of the auto-launch that I take issue with.
First of all, I don’t appreciate that the installer now silently adds an executable that is auto-launched. It’s not mentioned in the patch notes, nor in the updated manual as far as I can see, and would have gone unnoticed for a while if the exe.xml process wouldn’t be as broken as it is. I assume this was a simple oversight, because even from a supportability perspective I think you’d want to inform your customers of this new requirement upfront.
I agree that having one “tiny” additional exe does not make a dent in the amount of processes that are being scheduled every second on my CPU already. But in my opinion it’s the precedent for plane developers in general that this sets.
As I m not a fenix owner, I don’t really know if it s the same file involving for both cases (here we are speaking about a tiny file not a whole application.
It’s not the same file, and that’s kind of the issue. Currently there are a handful of aircraft that use external processes. Some have a reasonably good reason to do so (helicopters were not supported by the sim SDK so far) which I hope can be overcome as the sim becomes more capable. In these cases the choice was to either have an exe or no reasonably realistic helicopter at all.
The reason in case of the Caravan that you were given by Nicholas seems to be performance (“We decided to put a lot of the shared code in an external application for performance reasons”). I appreciate the fact that this plane is more complex than your average GA plane, but there are already some fairly complex airliners in the sim that manage performance without an .exe. I also find it a bit curious, as my CPU is not very beefy and had no issues with this plane previously. Also looking through the thread it does not seem like this was a major issue for most users (especially compared to something like the Carenado PC-12, which seems to be a real performance hog).
Performance is something that every developer faces, and I know that with WASM running on the main thread the CPU budget is limited and trying to fit complex systems is not trivial. But I don’t think that the solution here is for every developer to just sidestep that limitation by introducing executables for every plane.
If devs really reach the limits with the optimizations they can do there are other options. Asobo already agreed that having multi-thread support for WASM is something they think is worth looking into, so maybe they need to be reminded of this again. (https://devsupport.flightsimulator.com/idea/246/support-multithreading-for-wasm-gauges.html)
Am I weird or “foolish” for caring about these things? Maybe. And I also assume that I’m in a minority small enough to not convince any developer to change their mind about this, but I cannot with good conscience support this. I don’t want to start MSFS in 2026 and wonder why my exe.xml is a mess and some plane is not working again because one of these 60 external processes was either not properly installed/started or crashed again.
