Any chance for Node.js support?

[JoeriSmits]

Hi,

I'm a Node.js developer and would love to work directly with simconnect. Currently I run a python solution as child process to communicate with python but this is not ideal.

[mpaperno]

Hi, thanks for the suggestion.

I don't really know much about Node.js bindings, nor have I used Node very much, so bear with me...

Is there any practical "generic" solution for running .NET assemblies in Node? Like https://github.com/tjanczuk/edge (but no updates since 2018 there?).

Barring that, I briefly saw something about using C++/CLI for creating Node bindings, so that would be similar to the current "WASimClient_CLI" code I imagine. If you can point me to any current references, that would help.

I'm surprised there's no SimConnect "binding"/client for Node!

Anyway, I'm open to the idea. It would be preferable to avoid as much duplication as possible/practical of course.

[JoeriSmits]

@mpaperno Thanks for your response! I was also surprised there was no node.js simconnect which is recent. There are some but all are not maintained for years. I spent a few days trying to run an assembly in Node.js but no joy really. I'm not that experienced with .NET. Edge got patched and is still maintained but under a different name: https://github.com/agracio/edge-js

[davidlav]

Hi, came here looking for the same question regarding Node support as I would also love to develop applications to communicate with the sim, but in JS/TS as I'm not a Python or "C language" person.

If a direct Node binding is difficult, I was wondering how big of an ask it would be for your server to expose a Web API that a Node process could communicate with via localhost in order to trigger events/subscribe to simvars with something like websockets. Axis and Ohs does something similar (page 101) I believe.

My goal would be some sort of API that would allow me the ability to implement something like the X-Touch-Mini-FS2020 MIDI controller interface in Node, rather than Python, in which I could trigger K and H events and arbitrary RPN scripts (like Mobiflight events) and listen to A and L var changes.

[mpaperno]

Hi David,

Funny you should mention a Web API... I was thinking along the same lines. On one hand it would be an extra "abstraction" layer so not the best for raw performance. OTOH it would let clients use any language and run on any OS. Plus it would be a natural for making Web-based UIs.

I was also thinking something websockets-based for the actual transport layer. With a protocol/API on top which would essentially mimic what WASimClient does now. And yes I've read through some of the AAO docs and like some of those ideas too... using a standard transport like WS (to essentially replace SimConnect) is a great idea. I wish I could communicate directly with the WASM module w/out SimConnect, but alas there is no direct socket access in that limited "ecosystem."

On the topic of Node itself, I did look into it a bit, and, well... a "native" integration doesn't seem very straight-forward at all. Simplest would probably to write a C-style DLL wrapper and then another Node layer to re-implement all the DLL functions natively in JS.

Ultimately to support all sorts of other scripting languages natively, and this relates to #5 (Go support) as well, it would probably make most sense to implement something using SWIG, which is like a descriptor layer for the C/C++ code, which can then be used to generate native bindings for other languages. It looks very promising, but I haven't had a chance to actually try it yet... definitely a learning curve there.

So, also to @JoeriSmits and @MMontalto, as far as me implementing something, I guess it's a question of priority... not sure what people would prefer really, native or something network based. Open to suggestions!

Cheers,
-Max

[davidlav]

Thanks for the thoughtful reply Max!

A websockets-based network API would be so incredibly useful, and fill a void that, to my knowledge, is only filled by a single payware application (AAO). Having a free and open alternative that anyone could then build (free and open) applications on top of in a language/platform-independent way would be a genuinely big deal I think for the entire ecosystem.

Performance-wise you're right, it's not as great as a native binding, but for many use cases (like replicating something similar to X-Touch-Mini-FS2020 where you're essentially passing through button and knob events and reading simvars in order to turn LEDs on and off), having a slight amount of latency or delay is hardly a deal-breaker, and would still be infinitely better than the current landscape.

[davidlav]

And in case you hadn't seen it, I just noticed at the bottom of the SU11 Beta (1.29.22.0) release notes from two weeks ago the line:

- It is now possible to make HTTP request through Wasm. See documentation for more information

https://docs.flightsimulator.com/flighting/html/Programming_Tools/WASM/Network_API/Network_API.htm

So I guess this is a new feature they're just now turning on (I hadn't realized it wasn't even possible before now).

[mpaperno]

Hi David,

Thanks for your earlier input... I agree with all that! :)

As for the new "network" API... unfortunately this note in the docs pretty much kills any hope of using it for a reliable & fast transport layer...

It is important to note that there is a limited amount of WASM requests that can be processed at the same time (for now it is limited to 3). Also keep in mind that those handles are shared by every WASM module running at the same time, meaning that you have to think ahead and be careful to not make too many requests.

We may do up to several data exchanges per ms right now... granted they're single threaded but still, with 3 total per simulator... doesn't sound very performant. At least SimConnect is fast, if somewhat annoying to use at times.

Also from what I can tell the WASM module can only request a URL, not act as a server, so I'm not sure how a client would even initiate a connection.

But yes, my hopes went up when I saw that... actually I first saw a bunch network socket related stuff in the C library they include in the SDK for building WASM modules... until I looked inside and realized all the low-level socket stuff is disabled, leaving just enough for what their "network API" allows. :-/

Thanks,
-Max

[davidlav]

Appreciate you looking into it. What a bummer, oh well!