MSFS20 2D gauges conversion by Legacy Importer

[thealx]

Greetings. I am Legacy Importer tool developer and apparently reached the point where I need some help. Working on gauges conversion now, get some result but its really far away from the finish line.

As you know, 2D gauges does not work in legacy cockpits (because of bug probably and maybe will be fixed some day, but who knows). I see some mentions that XML gauge format still supported by engine, but I have decided to avoid it (we know that devs does not care about legacy stuff so it can be broken with any future update) and move to native gauges format - HTML.

I've started 2D gauges experiments about 2 weeks ago. For some reason, VCockpit method did not work for me. Maybe it's another legacy bug, or I did something wrong, tell me if you made it work. But VPainting did work - it is not supposed to be used for needles control, but it does use JS and have access to all sim variables, so good enough for my goal.

Spoiler: Looks useless but I was happy to see it for the first time

So I moved on and made HTML/CSS generator. That was easy part actually. Most problematic is JS code generator - complicated animation, FSX and MSFS sim variables differences, and especially expressions parsing - these things makes me dizzy.

Spoiler: XML > HTML Conversion result example

Animation itself quite tricky, on top of that FSX and FS9 has has different XML formats. Currently only rotate/shift elements processed, but that enough for initial testing.

Linking variables not so simple task as it should be. If I use transformation solution like this one:
(A:Wiskey compass indication degrees,degrees) -> SimVar.GetSimVarValue("Wiskey compass indication degrees", "degrees")
at least 50% of variables will be not read properly.

So I had to build a table of known variables which works fine but will take a lot of time until it will be completed:

Spoiler: FSX2MSFS sim vars conversion table

                case string hn when hn.Equals("(A:Delta Heading Rate,rpm)", StringComparison.InvariantCultureIgnoreCase):
                    return "parseFloat(-SimVar.GetSimVarValue(\"TURN INDICATOR RATE\", \"degree per second\")) * 60 / 360";
                case string hn when hn.Equals("(A:Variometer rate,knots)", StringComparison.InvariantCultureIgnoreCase):
                    return "parseFloat(SimVar.GetSimVarValue(\"AIRCRAFT WIND Y\", \"knots\"))"; // TODO: fix rate
                case string hn when hn.Equals("(A:Wiskey compass indication degrees,degrees)", StringComparison.InvariantCultureIgnoreCase):
                    return "parseFloat(SimVar.GetSimVarValue(\"PLANE HEADING DEGREES MAGNETIC\", \"degrees\"))";

Any thoughts how to make it more flexible, or maybe full list of available variables exists?

Last one is postfix expression parsing. Simple arithmetics like +-/* is not a problem. Expression with single argument (sin abs if-else) a bit complicated, 2-3 - haven't even tried to make it work so converter returns 0 in this case and gauge does not work.This Expression Operators table really helps.

So, this method looks promising even if doesn't work in 80% of cases =) I will continue on it and hope to reach at least 50% success level. You can test it in latest Legacy Importer version, any imported plane can be loaded - it's not required to use any other program functions like CFG split or AIR import. If some/all of gauges does not appear you may check JS files first - if at least single error happen, whole panel will be black out.

Spoiler: Some gauges conversion examples

 

[OzWookiee]

Really love the effort you've put into this and it's certainly going to help a lot of order aircraft conversions that only have 2D gauges.

 

[WebSimConnect]

Nice work. I did couple of years ago similar XML gauges conversion into HTML to be used within my framework for P3D/X-plane. Now as the HTML renderer is out of box built-in MSFS it makes sense for me to come back to this project.

I managed to migrate all XML elements and their properties (shift, rotation, etc) however I failed to convert RPN code especially with those IFs, CASE statements etc. This is a nightmare to build proper parser as RPN is one thing and FSX specific parser implementation is another (e.g. stack operations, loop etc), so I skipped that and produced kind of warnings logs to modify manually particular RPN statements. I was happy enough to parse +- 80% of RPN statements without errors for complex PFD gauges.

What was a challenge is that XML gauges philosophy is different from JS programming, XML gauges are responsive to variable changes, so I need to apply same philosophy in kind of watch variable framework. I have not yet analysed HTML-JS framework for MSFS integration, but it might be this can be achieved in another way...

Anyway, good luck in your project.

 

[thealx]

Hi!

Expressions parsing is a headache indeed. I've reach some success by simulating stack manipulator - most commands supported (except case mentioned by you, bitwise, string operators, and some uncommon for JS lang commands), but I am going to finish at least most of them. Planning to make full report for everyone who interested with detailed description and code examples.
Unfortunately, I'm getting challenges from each direction so my current goal is make ~50% of gauges work. Amount of time required for single improvement will increase dramatically with each step, so at some point it will not worth it.

 

[ESAbolichin]

Really love the effort you've put into this and it's certainly going to help a lot of order aircraft conversions that only have 2D gauges.

Totally agree with OzWookiee, thx to thealx for sharing this info with the comunnity... have a nice day guys!

 

[thealx]

Hey, fellow FS developers. I wish to share some information on FSX expressions parsing (which in Reverse Polish notation form, or just Postfix) that implemented in latest Legacy Importer (on post publish moment - in future 0.0.4.10 update).

If some of you would like to test conversion process and debug it - two instruments available:
1. Test expression converter button will open form where you can past expression and get conversion result
2. When you converting aircraft panel, log file created next to XML file (in example picture below - fragment of ".panel.log.txt" file of DG808S). Log contain detailed information about stack state (records divided by | ), condition logic state, and conversion results. You can see that variables replaced with random numbers for simplification process - once parsing finished, they moved back into final script.

Spoiler: Parser testing instruments

You can check table in attachments with all available operators, their conversion replacements (in final JS script) and examples. Original data was copied from here.

Color labels:
white - not implemented yet
green - native JS operator user
blue - custom functions used as workaround
yellow - works but probably wrong

Feel free to report about any issues you will find. I am still working on scripts so maybe this table will updated soon.

 

[Lagaffe]

Hi,

While manipulating on a great number of planes, we noticed that the transcription maded by LegacyImporter went better when certain precautions had been taken in the writing of the panel.cfg:
- no blank between commas and numbers: example "gauge, 3, 3, 3" becoming "gauge,3,3,3,3"
- no white in the gauge's names, it is better to replace them with underscores

 

[thealx]

Thanks for the tip, will check it out.

I've made significant improvement lately by adding support of nested Elements, so now a lot of digital instruments details pop up (even if animation does not work properly most of the time). but it cause some problems with cockpits that did work fine before, trying to solve it and push new update soon.

 

[thealx]

MSFS Legacy Importer 0.0.5.0

List of changes:

* Discord link fixed
* missing aircraft.cfg values fix for all liveries
* fix for invalid ui_typerole value (to make aircraft visible in main menu list)
* real time status for textures conversion, CAB extraction, panels import
* JSON generation result message
* panel import log improved
* gauge string data import (static styles only, no formatting or if/else parsing)
* expression if/else issues fixed
* most expressions operators added (except case and labels)
* nested gauge elements support (infinity depth)
* gauge string with single dimension (width) supported
* gauges IDs sanitizing
* numeric gauge ID fix
* some sizing issues fixed
* macro data reading
* gauge image load without extension

 

[thealx]

Aircraft panel data manipulation tutorials:

 

[Michael2]

My thanks to the OP who made this tool. I have used it to get started with html gauges as I need several of these in the aircraft I am developing. The old xml ones work as intended except they go black without an emissive property which isn't going to work for me as the gauges in question are not screens but rather tapes that scroll behind a window and should not be illuminated when the panel lights are off. So I have no option but to use html gauges.

The converter produced something that wasn't functional, but with a few edits I was able to get it working correctly. The only problem is it refreshes very slowly (maybe once every one or two seconds) whereas I need it to move smoothly at a high frame rate. The converter produced a vlivery gauge rather than a vcockpit gauge. Is there some way to control the rate at which a vlivery gauge runs? These are intended to work for static registration numbers so I cannot find any examples in the default aircraft that are of assistance with this.

I have tried to convert the gauge to a vcockpit gauge that I believe would run fast by default but without success so far -- I can't get the image file to load. The gauge is very simple -- all it has to do is move an image file up and down using a single line of code that I have managed to write correctly in the JS file (as demonstrated in the vlivery version).

It seems quite incredible how many files and how much text it takes to run a single line of code to move one image. I have never written JS before, so that certainly doesn't help.

 

[thealx]

Hello. Project no longer maintained, so the used rendering method (registration number workaround for legacy planes) no longer works properly. But you can fix your gauge manually to make it work fast with native plane (I guess you have a native project), use attached template as example for JS files header/footer update, also you need to change panel.cfg gauge line to make it look that way (not precisely, just example - it very same as any other native panel):

[VCockpit05]
size_mm = 1024,1024
pixel_size = 1024,1024
texture = $TEXT
background_color=0,0,0,0
htmlgauge01 = mycompany_simple_aircraft_jet_panel/gauges.html,0,0,1023,1023

Maybe some HTML edits also required, do not remember. You can check this aircraft https://flightsim.to/file/13218/air-creation-582sl it was converted from legacy into native plane with this tool, you can clearly see the differences in gauge HTML/JS files.

 

[Michael2]

Thanks,

That's very helpful -- I'll give it a try.