Please restore all Simconnect_text missing functionality from FSX, which could
be used to create interaction and provide feedback to users, not related to
panels and gauges. All the following features were widely used in FSX and are
all missing or incomplete:
- Menus (with sub menus) that used to appear under the “Addons” menu that could be created dynamically through Simconnect, which might now appear as extra entries in the Ingame panel toolbar.
- Menus unrelated to a Ingame panel that would present the user with a list of choices and return with the result, temporarily mapping the numeric keyboard from 0 to 9.
- The informational text messages, which right now is the only feature that works, but is very incomplete, since they always appear as “Tips”, their style cannot be customized in any way, and there’s no way to control their duration.
That feels like a step backwards compared to the flexibility of being able to
create a custom in-game panel, which is already available and has a rich API.
Is there something about doing this via SimConnect specifically that has some
value I’m missing here? -Matt | Working Title
There are plenty of usage cases when you might want to create a menu directly
with Simconnect, for example:
- You could conjure a menu on the fly, without having to create an In-game panel first, so you won’t have to take a slot in the toolbar.
- In FSX it’s possible to create sub-menu entries, which again would help with cluttering the toolbar. It doesn’t seem to be possible to create a hierarchy with in-game panels.
- Menu creation through Simconnect would make it easier/more efficient to access it from WASM.
- There’s no way to create a quick text feedback that would disappear automatically. It would be enough to just extend the current “Tips” call, to make it a lot more useful.
Also, the real problem is the “rich API” is not officially documented. This
will probably deserve a new thread/suggestion.
I can think of several limitations of in-game panel though: - It occupies a
space in the toolbar, and need manual activation, so it’s not suitable for
stuffs that is only relevant for a short period (e.g. showing landing rate,
notification). - It has very limited connectivity to outside world comparing
to out-of-process SimConnect plugin. So if we want to use out-of-process
SimConnect, we need to reinvent a way to communicate between the panel and the
executable. This can incur unnecessary effort of both developers and users for
simple stuffs.
JS panels can communicate to the outside world via WebSockets, which is much,
much more robust than the SimConnect client data system. -Matt | Working Title
Web sockets are only available between JS and external .EXE. A WASM module
would still require to use Simconnect so, if Simconnect had such calls, one
could choose between having an unified method used both in WASM and EXE, or
different methods, if he feels they are better. Also, it still won’t fix the
main issue of having to have a full blown In-game panel, which might not be
needed. You think it’s not a problem today but, what about in a few years, if
dozen of apps need to create a quick menu or a message box, are they ALL
supposed to have their own panel Toolbar ?
This is what things might look like in a few years if we stick exclusively to
in-game panels 
Right, I was responding only to the comment about limited connectivity to out-
of-process executables, which I was addressing. -Matt | Working Title
Don’t we all love this ;). But yes joke asides, I really hope we don’t come to
this just to be able to have a nice notification message, or a simple Yes/No
prompt.
I think having JS-based panels is definitely the way to go - an option to
simply generate them on-the-fly (in addition to on the toolbar), and provide
support to sub-menus would be a perfect compromise. Furthermore, once an
efficient data bus and more complex data types are supported than the existing
LVar limitations (mentioned here:
<https://devsupport.flightsimulator.com/idea/264/support-strings-and-structs-
in-lvars-and-allow-rea.html>), then communication with WASM gauges shouldn’t
be an issue. And, as Matt mentioned, websockets (and javascript fetch calls)
are always available to communicate with external programs and services.
Hello, Restoring this feature isn’t in our plans anytime soon.