Images with MSFS JavaScript or c++?

[Cactus2456]

Hello,

Is there any way to make images show up in a guage in msfs using javascript or c++?

Thanks!

 

[=rk=]

WebAssembly

docs.flightsimulator.com

 

[Anthony31]

Yes, see the MSFS SDK/Samples/Aircraft/GaugeAircraft for a C++ example which does exactly that.

Having made a javascript and c++ gauge I'd go with c++. I found it easier to work with plus, the samples are right there which makes it even easier.

 

[Cactus2456]

Ok, thanks

 

[DragonflightDesign]

Capabilities:​

• The Windows API is not supported.
• C++ exceptions are not supported.
• C++ threads are not supported.
• The GDI+ wrapper is very incomplete.

Is why I won't go anywhere near it. I won't sy that it's useless - it's obviously not quite that bad - but IMO it's not that far off it.

 

[=rk=]

Web assembly is intended to be a more secure alternative to dll's, so you'd want to consider your compatibilities at that level, but I saw a website where a guy had taken the gauge aircraft sample and made one of the gauges into a portal for a live web page. Another gauge was a working video game, Tetris or Missile Defender, or something.
OK, blow this up and put it on the outside of a SimObject and now you can advertise future products. You could provide news and media space for hire, flash mob synchronized liveries, you could have a giant image of your own head in the clouds, vlogging real time and visible in all your sceneries. I just see some interesting potential for it.

 

[DragonflightDesign]

I agree Rick - it is more secure because it's running as a sandbox - but while the SDK is incomplete and until those problems above are solved, it's too much like beating my head against a brick wall for me to be interested. Once the current project is finished and there is an SDK 1.0, my intention is to see if it is possible to use a web assembly module as a portal to the sim and do everything else outside the sim. I suspect the answer is already Yes.

 

[B21-soaring]

I'm guessing you guys are more familiar with C++ than HTML/JS/CSS but 100% of Asobo gauge code is in HTML/JS/CSS. C++ was big for gauges in FSX but not in MSFS. I think the argument for C++ is strongest when it's an external executable, to avoid the restrictions Asobo places on gauge code, but that's fairly clunky for a typical aircraft project.

MSFS gauge support provides pretty much standard HTML/CSS/JS support, i.e. as a totally basic intro:

* The layout of the gauge is defined as an 'HTML page'

* That HTML can be formatted with CSS

* You can define a JS script that receives events from the sim or the model XML or the user interation on the gauge, and then manipulate the HTML/CSS same as any other web page.

If your gauge layout contains <div class="frog"></div> and your CSS contains .frog { background-image: "frog.jpg" } then the picture of a frog will appear in your gauge and you don't need any JS. WIth one line of JS you can translate or rotate that image, which is how every gauge works (also with one line of JS you can update a number displayed in the div).

Many gauges can be almost as simple as this, e.g. a radio is just a couple of buttons, plus numbers updated in a couple of divs. You can write far more complex gauges such as the PFD / MFD displays but mostly this is (a lot) more of the same.

 

[=rk=]

lol C++/webassembly is an extremely odd choice to put an image on a page.

"An image on a page," seems a somewhat pedestrian application, for the potential of web assembly. For your image, let's go ahead and substitute tonight's menu. Care to order, from the cockpit, video conference style? How about watching the Kentucky Derby, from Churchill Downs.

Easter Seals fund raising celebration? Color your landmarks pink for a week. Stream "Jaws" to the movie screens in all your airliners. Run a geocaching tournament through your "events" gauge. Synchronize liveries to take an aerobatics tournament-demonstration to the next level.

Isn't DARPA working on a type of camouflage, that mimics ambient conditions? You could simulate this, with on-the-fly updates. One of you smart guys could probably automate the entire process.

Simultaneous live updates with streaming capability, onto any 2d surface in the sim, seems like it would be a game changer, imo. Plus, it's another option for gauges.

 

[B21-soaring]

=rk= I think you're confusing "C++ Windows binaries" with "C++/webassembly" which compiles to a tiny subset of Javascript and runs on the same browser engine as the other gauges. You gain relatively little by using C++/webassembly for MSFS gauges and become somewhat disconnected from the mainstream gauge support which is in html/css/js.
I'm not certain but I suspect 100% of MSFS aircraft have HTML/CSS/JS gauges (I would be surprised if even 1% of gauges are webassembly, and those would be FSX ports), so suggesting webassembly to the OP for such an ordinary gauge requirement is pretty questionable.

 

[=rk=]

Actually, I'd gotten the idea from the SDK. Microsoft's example, GaugeAircraft, includes a set of WASM gauges. I know this because I ran that tutorial as part of my exploration.

The SampleWasmModule.sln solution will allow you to compile the code with Microsoft Visual Studio 2019 in order to create the SampleWasmModule.wasm WebAssembly module which will then be loaded by the game.

SDK Documentation

docs.flightsimulator.com

The only other tutorial for GDI+ gauges, also uses WASM. You can see above that we'd already discussed the security of dll's so there really is no confusion and I've seen no examples of ported gauges in my searches. Ported airplanes usually use aliased panels.
Searching "html gauges" in the SDK returns right back to the GaugeAircraft page and while the default aircraft all have .html gauges, the SDK seems to be all about WASM, when it comes to developing gauges. Check for yourself.

 

[B21-soaring]

You're definitely right the SDK docs are spectacularly incomplete but I wouldn't base much strategy on that. I think we have a hypothetical argument in favor of C++/webassembly on one side and hundreds of thousands of lines of html/js in real MSFS gauges on the other... Asobo don't seem to have developed any C++ gauges and most FSX C++ guys seem to criticize the C++/WASM support rather than actually use it.

My most recent html/js gauges can be seen here:

- Surely if C++/webassembly is to be recommended there will be good examples in real MSFS aircraft somewhere?

 

[=rk=]

It can't be any plainer than the SDK. If someone refuses to confirm that something is "recommended," how could that person possibly be mistaken.

Is there any way to make images show up in a guage in msfs using javascript or c++?

Can be satisfied by taking the GaugeAircraft sample and replacing the demo image, with a desired image, ok? This seems pretty simple.

Now I look at your "procedure" and I for one, am absolutely dead in the water, sorry to be so dumb and still developing. What I can make of it, looks very, very similar to the breakdown of WASM in the SDK, but since you won't read that document, or explore those tutorials, we're not able to relate on that level.

FYI, entering the conversation with conclusions about "us guys" and what we must know or not know, gives an impression one's mind is firmly made up.

I think we have a hypothetical argument in favor of C++/webassembly on one side and hundreds of thousands of lines of html/js in real MSFS gauges on the other...

Ok, let's be clear that this is something you "think." You are comparing comments in a forum, that is quickly adding scores, if not hundreds of lines, to it's position, as a single entity, against "lines of code," as some sort of multitude, in rebuttal. Please stop the nonsense. You actually have quite a few arguments in favor of WASM and you'd know them if you looked into the SDK. I am not "advocating" WASM, I answered a forum post and I provided personal anecdotes to support the idea.

I'm sure the OP is glad to learn your ideas, as well and I hope you can feel free to articulate them, without forcing everyone to abandon the SDK.

 

[Anthony31]

I don't know how to write to a file (to save aircraft preferences) with html/css/js. I'm not familiar with html/css/js but from the brief look I had it seemed it wasn't really possible (for security reasons) and then I lost interest in trying to find out if it was.

I also don't know how you would access simconnect with html/css/js.

But I know MSFS does some sort of conversion on WASM gauges. There's always a delay in booting the program whenever I update the WASM and MSFS writes some .dll .lib and .pdb files into the AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\packages\[Package Name] folder

 

[ErnieAlston]

Surely if C++/webassembly is to be recommended there will be good examples in real MSFS aircraft somewhere?

AFAIK Aerosofts CRJ is C++/WebAssembly so there is at least one good real MSFS example out there. I recently saw Leanardo's MD80 recent MSFS progress and from what I could tell it appeared to be WASM gauges. I would be shocked if PMDG isn't going in the WASM direction as well for their more complex airliners.
That seems to be one of the best justification for it, porting legacy apps from FSX/P3D without having to effectively rewrite their entire application again. I would suspect that's the reason WASM support exists at all as Asobo/MS was concerned about legacy developers. But once they let the WASM genie out of the bottle they may never be able to put it back. IOW if enough legacy devs start making C++/WASM addons (PMDG, FSLabs, QW, TFDi etc) they may need to provide more WASM support in the near future (more access to sim internals, threading, web calls, and maybe some limited access outside the sandbox (well I'm gonna keep that dream alive)). There is a fair amount of C++ documentation because much of the C++ FSX documentation was still applicable for webassembly, they did also provide some working examples in C++ (w/GDI+ wrapped around nanovg code) in the SDK.

The key html/js benefit IMO is almost all the default code is visible, There is scant documentation, but there are tons of examples to look at and learn from (either in the in-sim default gauges or the various open source group githubs that have sprung up). That does seem to be the better way to go for someone completely new to making FS addon gauges, if you're not welded to C++ and can get past the lack of documentation.

But of course the html/js code being visible to everyone, it may not be as attractive to payware developers who would likely want some way to
protect their IP. So if someone new thinks they might go payware somewhere along the line its something to consider.

 

[=rk=]

I've been trying to utilize the default HTML gauges with little success. Previously, I'd been able to assign a "$" prefixed material to my target polygons and so far that hasn't worked, even if I try to use the default names, so I've had to work with the default polygons, by isolating them with MCX. This provides a gauge graphic, which I can superimpose onto my cockpit model, all that works fine, but after a build, the gauge is both inverted and reversed. (Edited to add image.)

Microsoft offers the Garmin G1000 as a stand alone addon, with no obvious way to integrate it using the simulator interface and it is a straight up html gauge, so it seems pretty clear intent developers are expected to work with it. Part of the issue for me, is that I am not able to "hack" the model folder with anything that hasn't been compiled by FSPackagetool.exe, first; I am able to join exterior and interior model versions, using a .json formatter to allow MSFS to recognize my hybrid package, but if I say, remove gauge polygons from an Asobo model, those edits must be compiled to .glTF and if compile MCX and then the .json formatter, the interior model is invisible in sim.

I am pretty sure the image reversal is a consequence of recompiling the gauge, It's a little hard to understand how html, coded to a texture designation on specific poly geometry that does not change, itself changes upon a build operation, because if I just replace my entire cockpit with an Asobo cockpit, the gauges work fine. This might be a measure to protect the security of html gauges as mentioned above, if one can't compile gauges without editing the gauge itself, it tends to remove incentive.

 

[GaryGB]

Hello:

Umberto Colapicchioni of FSDreamTeam / Cloud-9 is quoted regarding some aspects of what, IIUC, is the topic under discussion here:

https://www.fsdeveloper.com/forum/threads/non-looping-simobject-animation.452650/post-884241

GaryGB

 

[B21-soaring]

I don't know how to write to a file (to save aircraft preferences) with html/css/js.

If I've understood your requirement correctly, Asobo provide a pair of JS functions to store information from gauges (e.g. preferences is the main thing I use it for):

Include.addScript("/JS/dataStorage.js");

And then in your gauge class you can persist string values with:

SetStoredData("my_unique_var_name", "string value to save");

And get the data back with:

var my_stored_value = GetStoredData("my_unique_var_name");

There is a noteworthy 'gotcha' - if the user quits MSFS via 'Alt-F4' or by hitting the [X] in the top-right corner of the window, then MSFS instantly quits WITHOUT persisting the data from the SetStoredData calls. I assume this is because the Sets/Gets are using a memory cache while MSFS is running which is written to disk when the user quits MSFS, but only if they quit via the 'return to Main Menu' sequence. Also please note this is a key-value store, not generalised access to the file system. Nevertheless all my gauges are a one-click flip from imperial to metric and that gets stored via this method which seems to work well, also volume settings and gauge preferences (like North Up vs Track Up) are remembered between sessions.

I also don't know how you would access simconnect with html/css/js.

There's no SimConnect API in html/js gauge support AFAIK. Subscribing to events and reading/writing simvars is ok via the gauge API, so that's what I've needed in my gauges that could have been either API, but I'm assuming there's something you might want to do in a gauge with SimConnect you'd struggle with in the gauge API.

 

[=rk=]

Getting working html gauges from default aircraft was simply a matter of reorienting the gauge polygons using MCX move and rotate functions. After the inversion was reversed, the left-right direction remained reversed and this was solved by reversing all polygons and then rotating the gauge polygons 180°.

 

[Cactus2456]

It can't be any plainer than the SDK. If someone refuses to confirm that something is "recommended," how could that person possibly be mistaken.

Can be satisfied by taking the GaugeAircraft sample and replacing the demo image, with a desired image, ok? This seems pretty simple.

Now I look at your "procedure" and I for one, am absolutely dead in the water, sorry to be so dumb and still developing. What I can make of it, looks very, very similar to the breakdown of WASM in the SDK, but since you won't read that document, or explore those tutorials, we're not able to relate on that level.

FYI, entering the conversation with conclusions about "us guys" and what we must know or not know, gives an impression one's mind is firmly made up.


Ok, let's be clear that this is something you "think." You are comparing comments in a forum, that is quickly adding scores, if not hundreds of lines, to it's position, as a single entity, against "lines of code," as some sort of multitude, in rebuttal. Please stop the nonsense. You actually have quite a few arguments in favor of WASM and you'd know them if you looked into the SDK. I am not "advocating" WASM, I answered a forum post and I provided personal anecdotes to support the idea.

I'm sure the OP is glad to learn your ideas, as well and I hope you can feel free to articulate them, without forcing everyone to abandon the SDK.

I have been having issues with my installation and the samples folder is not showing up, I wanted to ask this before I delve any further in trying to make a guage.