MSFS C++ gauges nightmare

[mariomotta]

It's not really clear in what circumstances C++ gauge development makes sense over javascript.

I don't think there's a practical speed difference within the sim given the coding practices common in gauges (I have a PhD in computer science so I understand the diffference in execution model and that trivial instruction sequences execute quicker in WASM than JS) . My guess is C++ -> WASM gauge code will be deprecated in due course (shock, horror). Of course those with 'legacy' C++ gauge code will want to migrate rather then re-write but I don't think I would use C++ otherwise.

While I'm on a rant, the naming of the most basic calls used in gauge code in C++ and JS make me smile, i.e "get_named_variable_value()" and "SimVars.GetSimVarValue()". No-one thought just "SimVars.get()" ?

You answered by your self, i'm one of "those with legacy C++ code"
Furthermore guess that SimConnect is still a must for complex aircafts, does JS have SimConnect ?
cheers

 

[WarpD]

JS is about as useful as the XML "code" of FSX. It's coming on the 6 month release anniversary... please note the number of complex aircraft releases for FS2020 thus far. When I say complex, I mean full fidelity in the systems/avionics/flight dynamics. Not just how pretty it can look.

 

[B21-soaring]

JS is about as useful as the XML "code" of FSX. It's coming on the 6 month release anniversary... please note the number of complex aircraft releases for FS2020 thus far. When I say complex, I mean full fidelity in the systems/avionics/flight dynamics. Not just how pretty it can look.

Sorry I didn't understand your post at all. JS and C++ are very similar languages, and for gauge code they both run on the same engine actually designed for JS (i.e. the C++ is converted to WASM). I don't understand the systems/avionics/flight dynamics implications between the two.

 

[WarpD]

I don't understand the systems/avionics/flight dynamics implications between the two.

Try googling "can javascript read local files". On the surface, that might not mean much... but, for current navigational data (which is far more detailed than what comes with the sim, even FS2020), reading local files is necessary. That or a TCP/UDP network link via the internet (limited bandwidth won't like that!). Just one example.

 

[B21-soaring]

Try googling "can javascript read local files".

well that could have been a little less patronizing...
Can a C++ ->WASM gauge in MSFS access the local filesystem? That would be an important difference JS/(C++ -> WASM) that I didn't know. The JS can establish TCP/IP connections using the same calls as a regular web page (i.e. over HTTP). I'm wondering whether MSFS gauge JS can write to localstorage/cookies (i.e. again as a normal web page) which in the absence of local file access would be a major plus, but I'm not optimistic.

To add a little JS value here - I'm using two very limited hacky methods to READ local files in my HTML/JS gauges currently, both requiring the files to be in the gauge virtual file system:

1. I have a settings file (e.g. which allows gauge background units to be changed metric/English) but that is actually minimalist JAVASCRIPT so it can be imported into the HTML. A JS 'variable assignment' is wrapped around the 'property: value' sequence of values. The user has to be careful not to damage the "SETTINGS = [" at the top of the file, etc. but it's better then nothing.
2. Note that all files in the HTML/JS tree are in the 'web url' address space of the gauge, so you can get the whole file with XMLHttpRequest() IF it can be placed in the 'virtual file system' for the gauge code. Again not great, but better than nothing.

I don't currently need to write arbitrarily to the users file system, but persisting sim data would be really handy.

 

[mariomotta]

that could have been a little less patronizing... Can a C++ ->WASM gauge in MSFS read local files? That would be an important difference JS/(C++ -> WASM) that I didn't know. The JS can establish TCP/IP connections (using the same calls as a regular web page). I'm wondering whether MSFS gauge JS can write to localstorage/cookies (i.e. again as a normal web page) which in the absence of local file access would be a major plus, but I'm not optimistic.

There are countless examples how a "complex" aircraft needs SimConnect (ie: SSW FIAT_AERITALIA G-91):
- need to override the starting up spool to avoid that unrealistic turbofan spooling MSFS has
- need to override and change the drag pending on loading/drop external stores that MSFS actually ignores
- several other situations where default behaviours cannot replicate the "real" thing
and yes C++ compiled to wasm can both read and write files also in the VFS area.
Imho if you want just an "eye candy" model without realistic systems XML/JS are enough, but if you need to go a step forward SimConnect and C++ is a must.
cheers
/Mario

 

[B21-soaring]

The issue here is whether/when to use C++ -> WASM for MSFS gauge programming. Native Windows x64 applications using the SimConnect API are another thing entirely (and I wholly agree C++ or C# are great for those).

IMHO this thread is tending to conflate the advantages of native C++ application capabililities (e.g. accessing the local filesystem) with what you can do in C++ -> WASM gauges (which run on the same browser engine as HTML/JS).

So my reading of this is there are three advantages of C++ -> WASM gauge programming:

1. porting legacy code from FSX
2. if you are already a C++ programmer, e.g. using that for SimConnect, then you can use the same language for your gauges
3. the execution of the C++/WASM code should be quicker than JS

I don't see any evidence you can do something "more complex" in C++ vs JS within MSFS gauges, and I guess a fair comparison would list the advantages of the JS gauges.

 

[mariomotta]

May be you do not consider that SimConnect can be used "within" a gauge not only in an external connecting-game program.
SimConnect is necessary if you want change/control some sim vars, it cannot be done using JS or XML.
Just an example:
- how to deny controls mouvements or steering if you do not have engine running ? Actually it seems that all controls in MSFS seem to be mechanically linked, which is not on majority of modern airplanes.
So imho the lack of sim vars control is a major disavantage of XML/JS versus SimConnect.
Or i'm missing something ?
cheeers
BTW:
i agree that the majority of simmers do not care about systems, almost all will complain about not perfect model/textures but almost nobody will complain if controls can be moved with a dead engine, under this point of view may be using XML/JS can be much more easy and convenient.

 

[WarpD]

I don't see any evidence you can do something "more complex" in C++ vs JS within MSFS gauges

That is because you can't do anything complex in FS2020, at all. The "sandbox" that is currently defined makes that rather impossible.

 

[B21-soaring]

Ok here's my updated advantages of C++ -> WASM gauge programming vs. JS:

1. porting legacy code from FSX
2. if you are already a C++ programmer, e.g. using that for SimConnect, then you can use the same language for your gauges
3. the execution of the C++/WASM code should be quicker than JS
4. C++ -> WASM gauges can access the local file system (WarpD) - EDIT this turned out to be wrong
5. C++ -> WASM gauges can also access the SimConnect API (mariomotta)
6. C++ -> WASM gauges can read/write MSFS SimVars, unlike XML or JS gauges (mariomotta) - EDIT there was a misunderstanding here, Mario didn't know JS can read/write MSFS SimVars.

 

[kalong]

almost all C++ can done in FSX, it can be in MSFS too.
can draw GDI+,
now can draw via nanoVG, another cool program that include "touchscreen" display feature, such a challenge.

... (I have a PhD in computer science so I understand the diffference in execution model and that trivial instruction sequences execute quicker in WASM than JS) ...

I'm the guy that have no programming education at all. but I can do it. The important advantages is ourselves, "can I make it happen?"
Thanks to all fsdeveloper.com comunity ...

 

[B21-soaring]

Thanks kalong. Updated "reasons to use C++ for gauges vs HTML/JS" list:

1. porting legacy code from FSX
2. if you are already a C++ programmer, e.g. using that for SimConnect, then you can use the same language for your gauges
3. the execution of the C++/WASM code should be quicker than JS
4. can access the local file system (WarpD)
5. can access the SimConnect API (mariomotta)
6. can read/write MSFS SimVars, unlike XML or JS gauges (mariomotta)
7. can use the GDI+ Windows 2D drawing API (kalong)
8. can use the nanoVG 2D drawing API (kalong)

 

[WarpD]

C++ -> WASM gauges can access the local file system (WarpD)

That's not as useful as one might think. "local file system" means only files placed in a very specific folder for that addon. Other addons can not see that folder nor can they use the same "local file system". Every single aircraft would have to install it's own Nav data (as an example).

can use the GDI+ Windows 2D drawing API (kalong)

It can use a subset. The entire GDI+ library is not there. It is still a work in progress on their part.

Things WASM can not do:

1. It can not interact with the OS, at all. It resides in an extremely protective sandbox.
2. It can not provide network/internet access.
3. It can not provide access to dynamic link libraries.
4. It can not provide access to external applications.

I'm certain there's more I could come up with... but, it's an extremely restrictive sandbox.

 

[B21-soaring]

WarpD your current advice seems to be "don't do MSFS gauge development it sucks". I understand you need full Windows filesystem access and maybe TCP/IP socket support . Given the choices C++/WASM, HTML/JS, model XML, native Windows executable/SimConnect it looks like you're stuck with the last one and have to work out how to bridge from that executable to your gauge.

Because HTML/JS has network access via XMLHttpRequest, and C++/WASM shares the same underlying engine, it's probable some network communication will be possible in C++/WASM e..g. http post/get and *maybe* websockets.

A bright bit of news is HTML/JS gauges can store limited data between sim sessions, as in this fsdeveloper thread. Not general purpose file access, but still a useful key-value store which means HTML/JS gauges can allow settings changes (e.g. click to change a gauge background, alter a gauge volume) which can be stored across sim sessions. <- EDIT: this may be a false alarm and the key-value store evaporates when you exit the sim (see the thread...)

 

[WarpD]

WarpD your current advice seems to be "don't do MSFS gauge development it sucks".

Nope. My "advice" is to not assume that an aircraft from PMDG (as example) is going to be possible in the current SDK environment of FS2020. Truly complex aircraft are unlikely at this time. There are lots of OS calls being used in complex aircraft gauges that literally aren't possible in WASM (note I said WASM, not FS2020). Multi-threading isn't going to happen, as example.