I am considering creating some external GUI’s that allow the user to get/set SimConnect data (see below).
Would it be realistic to create a tray-icon program that reads/writes a directory, single get/set commands, using CSV or XML files?
Three file types would be used: test.get, test.put, test.out. The test.out file would be created by the task-icon program for my GUI to read the data sent from SimConnect; when it has been released from open-exclusive access.
Would something like this be realistic to use? Creating an interface like this would not be the fastest way of doing things, of course, but it would allow “any” programing language access to the SimConnect data using a file-based system.
Thoughts?
Sample TBM 930 AP GUI:
The desire to abstract away from SimConnect and make the interface with the simulator possible for any programming language is a good one, but doing it through writing and reading files to the file system is an old fashioned and inefficient way of doing it.
I think (but then I’m biased) that a much better way of interfacing with the simulator from any programming language is by using HTTP requests. They can literally be used by any programming language (or even a browser), have the scope to be transmitted across a network, etc.
There is a working example I have developed of this in my MSFS2020 Cockpit Companion (freeware, open source). This uses the Python-SimConnect library to interface with the sim but makes it available through HTTP requests from anywhere.
There is a “glass cockpit” example built on top but it is also flexible in that you can get any sim datapoint in JSON format by calling http://localhost/datapoint/datapoint_name/get, set any datapoint by posting data through HTTP to http://localhost/datapoint/datapoint_name/set and trigger any event by posting to http://localhost/event/event_name/trigger.
It also includes groupings of commonly used datapoint (eg navigation, autopilot) which can be called to reduce the number of HTTP requests.
I have seen your code, FittedBugle, and honestly it looks great! Thanks for sharing it freely.
Yes, I am an old-fashioned programmer. But, a very successful one at that.
The thing I keep seeing on the internet, and the junior programmers/power user’s posts that I read, are them struggling to work with getting/setting SimConnect data. My self included. My current compiler does not support HTTP (yes, its old; don’t ask! 
). I am requesting to get my current compiler versions Language Reference be sent to me to see if it supports HTTP gets/posts effectively. PureBasic does support HTTP calls and I may investigate that further since I also use that language.
Yes, using files is old-school but a file is a file is a file. And “anyone” can create or read a file with any compiler or text editor. Is it efficient? Nope. Does it work? Yup. Is anything hidden? Nope.
I am a K.I.S.S. programmer. Because my programs very rarely ever break and I am proud of that.
I am considering writing this tray-icon program to read/write files. But, can something like that handle the transfer of data back and forth with SimConnect using files? Because everyone these days are using SSD drives there really is no overhead involved doing it this way and the memory footprint is minimal.
Thanks for your quick reply and suggestions! I did have a look at the Python-SC library yesterday.
1 Like
Remember that flight simulator uses a virtual file system. WASM can only read and write to the virtual file system, but whether a windows application is allowed to read and write to the underlying physical files is an open question. I have not seen any documentation in the SDK that suggests files are a supported means of IPC, so even if it works today, such behavior should be assumed to be an implementation detail that could change (and therefore break) in the future. Even today, I wouldn’t assume that the virtual file system would pick up external writes to the underlying files in real time. Just from working in the SDK, it seems that this may not be the case (i.e., you have to force a reload to pick up updates in config files).
HTTP is probably a safer approach as it is fully supported by JavaScript. From the application perspective, it isn’t particularly complicated, but it is designed for sending text over the network, not IPC. It is likely going to be complete overkill–though depending on how and where in the stack optimizations for localhost happen, it probably won’t be unreasonable from a performance perspective.
Whatever you end up doing, I’d suggest creating an abstraction layer around your IPC mechanism so you can easily change it. From grovelling around in the WASI headers, I’ve seen function prototypes for sockets including UNIX (IPC) sockets, so I’m hopeful that we will have a supported IPC mechanism in WASM sometime soon.
1 Like
I was suggesting my data would be separate from MSFS and SimConnect. With no direct connection to the sim.
Simple get and put data. That’s it. In a directory “outside” of the sim.
