MSFS GetGameVarValue

[eric_marciano]

As I was digging into the JavaScript code, I found call to the GetGameVarValue function, something like:

let cruiseMach = SimVar.GetGameVarValue("AIRCRAFT CRUISE MACH", "mach");

It looks similar to the well known GetSimVarValue, but I don't know the difference. And "AIRCRAFT CRUISE MACH" is not part of the sim vars, so what is it? Is it a specific variable created for this instrument? In that case, why not using an L: var that can be get/set with GetSimVarValue/SetSimVarValue?
Needless to say, not a single word about this in the SDK...

Any information is welcome

Thanks,
Eric

 

[eric_marciano]

For information, I also found SetGameVarValue but I still don't know what it is about...

 

[Anthony31]

Well cruise_mach is set in flight_model.cfg under [REFERENCE SPEEDS] so I am guessing it lets you access .cfg variables. You'd have to test this to confirm as like you say, it's undocumented.

There's also

SimVar.GetGlobalVarValue("ZULU TIME", "seconds");

which looks like it is used for E: vars . Environment data which is mostly just time and date variables.

Another use of simvarvalue is using E: or L: to get variables that are not A: vars. I include this only for reference in case someone doesn't know it yet.

SimVar.GetSimVarValue("E:ABSOLUTE TIME", "seconds");

Notice how A: vars do not need have the A: prefix when using GetSimVarValue

SimVar.GetSimVarValue("ELECTRICAL MAIN BUS VOLTAGE", "volts");

I imagine you could use GetGlobalVarValue to get absolute time as it is an E: var but the M803 clock js uses both examples so, yeah, consistency eh?

 

[Prepar3DGuy]

Any information is welcome

Maybe content of simvars.js and TestSimVar.js files that lives inside C:\PROGRAM FILES\WINDOWSAPPS\MICROSOFT.FLIGHTSIMULATOR_1.15.8.0_X64__8WEKYB3D8BBWE\Packages\fs-base-ui\html_ui\JS will help you.
As I can understand, that simvar, globalvar, gamevar are parts of window and have some methods to get values of different types (look at GetSimVarValue implementation) and all except globalvar can be set values using Coherent.call("setValue_Number", ...). The function setValue_Number is like a callback that implemented in C++ and binded with CoherentGT using BindCall so C++ code can work with JavaScript like in that sample.
Never mind, I may be wrong, cause know nothing.

 

[eric_marciano]

Well cruise_mach is set in flight_model.cfg under [REFERENCE SPEEDS] so I am guessing it lets you access .cfg variables. You'd have to test this to confirm as like you say, it's undocumented.

There's also

SimVar.GetGlobalVarValue("ZULU TIME", "seconds");

which looks like it is used for E: vars . Environment data which is mostly just time and date variables.

Another use of simvarvalue is using E: or L: to get variables that are not A: vars. I include this only for reference in case someone doesn't know it yet.

SimVar.GetSimVarValue("E:ABSOLUTE TIME", "seconds");

Notice how A: vars do not need have the A: prefix when using GetSimVarValue

SimVar.GetSimVarValue("ELECTRICAL MAIN BUS VOLTAGE", "volts");

I imagine you could use GetGlobalVarValue to get absolute time as it is an E: var but the M803 clock js uses both examples so, yeah, consistency eh?

Yes, you're probably right, I also saw GetGameVarValue used to read the crossover speed, which is also defined in a cfg. Now I wonder what SetGameVarValue does, maybe it writes information in a file, that would be interesting too.
Thanks for letting me know about GetGlobalVarValue, I didn't know this so I was using SimVar.GetSimVarValue("E:ABSOLUTE TIME", "seconds"); to read time. If it is the same, I am sure we should use GetGlobalVarValue instead, which is the "modern" way of reading variables.

Thanks for your answer.

 

[eric_marciano]

Maybe content of simvars.js and TestSimVar.js files that lives inside C:\PROGRAM FILES\WINDOWSAPPS\MICROSOFT.FLIGHTSIMULATOR_1.15.8.0_X64__8WEKYB3D8BBWE\Packages\fs-base-ui\html_ui\JS will help you.
As I can understand, that simvar, globalvar, gamevar are parts of window and have some methods to get values of different types (look at GetSimVarValue implementation) and all except globalvar can be set values using Coherent.call("setValue_Number", ...). The function setValue_Number is like a callback that implemented in C++ and binded with CoherentGT using BindCall so C++ code can work with JavaScript like in that sample.
Never mind, I may be wrong, cause know nothing.

Thanks for this info, I will look closely into the implementation of these function. I also thank you for your explanations about Coherent.call because I was also wondering what it was.
I saw it used like this:

Coherent.call("AP_SPD_VAR_SET", 1, knots);

I will have to find out what the 2nd parameter is, but I'm happy to know it is designed to call C++ code. I had a quick look at your sample that explains communication between JavaScript and C++, but in the specific case of MSFS, I guess it is used only to communicate with existing C++ code developed by Asobo. Or can we also use this to communicate between JS and WASM?

Thanks,
Eric

 

[B21-soaring]

Prepare3DGuy nailed it.

One advantage of GetGameVarValue() is that it returns values of any JS data type, where 'FSX' simvars weren't originally designed for this. Asobo has used this to provide values that can be read from the aircraft config files, and some new vars that weren't available in FSX.

Further to Prepare3DGuy's comments, fs-base-ui/html/JS/SimPlane.js (which provide the 'Simplane' interface used in many Asobo gauges) makes extensive use of GetGameVarValue to return sim values.
e.g.

    function getStallSpeed() {
        return SimVar.GetGameVarValue("AIRCRAFT STALL SPEED", "knots");
    }
    Simplane.getStallSpeed = getStallSpeed;

If I was to guess, I think Asobo have the Simplane.XXX methods as a more 'strategic' way of getting sim data into html/js gauges, as they're using them to access existing 'traditional' FSX simvars, e.g. using Simplane.getWindDirection() rather than SimVar.GetSimVarValue("AMBIENT WIND DIRECTION"...) in their gauges. in some cases the Simplane function isn't a simple 1:1 mapping to a simvar.

    function getWindDirection() {
        var angle = SimVar.GetSimVarValue("AMBIENT WIND DIRECTION", "Degrees");
        return angle;
    }
    Simplane.getWindDirection = getWindDirection;

Here's a straight 'grep' of the references to GetGameVarValue() in SimPlane.js:

        speeds.VS0 = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VS0", "knots");
        speeds.VS1 = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VS1", "knots");
        speeds.VFe = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VFE", "knots");
        speeds.VNe = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VNE", "knots");
        speeds.VNo = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VNO", "knots");
        speeds.VMin = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VMIN", "knots");
        speeds.VMax = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VMAX", "knots");
        speeds.Vr = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VR", "knots");
        speeds.Vx = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VX", "knots");
        speeds.Vy = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VY", "knots");
        speeds.Vapp = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VAPP", "knots");
        speeds.BestGlide = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED BEST GLIDE", "knots");
        return SimVar.GetGameVarValue("AIRCRAFT GREEN DOT SPEED", "Knots");
            return SimVar.GetGameVarValue("AIRCRAFT CROSSOVER SPEED FACTOR", "Number", _cas, _mach);
        let maxSpeed = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VNO", "knots");
            let limit = SimVar.GetGameVarValue("AIRCRAFT FLAPS SPEED LIMIT", "Knots", _flapIndex);
        let maxSpeed = SimVar.GetGameVarValue("AIRCRAFT DESIGN SPEED VNO", "knots");
            let gearSpeed = SimVar.GetGameVarValue("AIRCRAFT MAX GEAR EXTENDED", "knots");
        return SimVar.GetGameVarValue("AIRCRAFT LOWEST SELECTABLE SPEED", "knots");
        return SimVar.GetGameVarValue("AIRCRAFT STALL PROTECTION SPEED MIN", "knots");
        return SimVar.GetGameVarValue("AIRCRAFT STALL PROTECTION SPEED MAX", "knots");
        return SimVar.GetGameVarValue("AIRCRAFT STALL SPEED", "knots");
        return SimVar.GetGameVarValue("AIRCRAFT STALL SPEED PREDICTED", "knots", _flapIndex);
        return SimVar.GetGameVarValue("AIRCRAFT AUTOPILOT AVAILABLE", "Bool");
        var usePropRpm = SimVar.GetGameVarValue("AIRCRAFT USE PROPELLER RPM", "bool");
            var maxHP = SimVar.GetGameVarValue("AIRCRAFT MAX RATED HP", "ft lb per second") / 550;
        return SimVar.GetGameVarValue("AIRCRAFT MIN CRUISE RPM", "rpm");
        return SimVar.GetGameVarValue("AIRCRAFT MAX CRUISE RPM", "rpm");
        return SimVar.GetGameVarValue("AIRCRAFT MAX INDICATED RPM", "rpm");
        return SimVar.GetGameVarValue("AIRCRAFT MAX RATED RPM", "rpm");
        var type = SimVar.GetGameVarValue("AIRCRAFT PROPELLER TYPE", "Enum");
        var type = SimVar.GetGameVarValue("AIRCRAFT NB PROPELLERS", "Enum");
        return SimVar.GetGameVarValue("AIRCRAFT AOA ANGLE", _unit);
        return SimVar.GetGameVarValue("AIRCRAFT ORIENTATION AXIS", "XYZ");
        return SimVar.GetGameVarValue("AIRCRAFT CROSSOVER ALTITUDE", "feet", _cas, _mach);
        return SimVar.GetGameVarValue("AIRCRAFT FLAPS HANDLE ANGLE", "Degree", _flapIndex);
        if (SimVar.GetGameVarValue("AIRCRAFT ELEVATOR TRIM LIMIT", "number") > 0)
        return SimVar.GetGameVarValue("AIRCRAFT ELEVATOR TRIM NEUTRAL", "percent over 100");
        return SimVar.GetGameVarValue("AIRCRAFT HAS GLASSCOCKPIT", "boolean");
        return SimVar.GetGameVarValue("GAME UNIT IS METRIC", "boolean");

 

[eric_marciano]

Thanks for your good explanations.
What I read here is that SimPlane not only returns constant values defined in the cfg files, it also returns variables that vary according to the aircraft configuration. For example, the stall speed and green dot speed are in that case. It means we can get fixed values like max_mach, which never changes, and variable values that change according to the flight.
Do you confirm my understanding?

Thanks,
Eric

 

[B21-soaring]

Thanks for your good explanations.
What I read here is that SimPlane not only returns constant values defined in the cfg files, it also returns variables that vary according to the aircraft configuration. For example, the stall speed and green dot speed are in that case. It means we can get fixed values like max_mach, which never changes, and variable values that change according to the flight.
Do you confirm my understanding?

Thanks,
Eric

yes, that is essentially correct, :

So we have

SimVar.GetSimVarValue("FSX var name"...) - returns 'traditional' single-value results, e.g. airspeed.

SimVar.GetGameVarValue("var name"...) - can return new data values which may be read from config files, OR new values generated live in the sim, and may be more 'composite' JS values.

Simplane.<function call> - calls either of the above, returning JS values of any type, plus may have additional code in the implementation to improve the functionality without 'breaking' the underlying simvars.

An example is Simplane.getOrientationAxis() which returns { "pitch": .., "bank": .., "yaw": ..} (from memory - "yaw" name might be wrong)

Another example Simplane.getIsGrounded() which has a lot more code in it than simply looking at the "SIM ON GROUND" 'FSX' simvar (in fact it doesn't use that at all).

The Asobo gauges extensively use Simplane calls and I'm guessing that means they can extend the 'Simplane' interface while leaving the FSX simvars 'frozen'. I think people locked into C++ WASM gauge development have limited experience of what is going on with the Asobo html/js gauge developments but html/js seems more likely to be the strategic direction.

 

[Geoff_D]

function getStallSpeed() {

return SimVar.GetGameVarValue("AIRCRAFT STALL SPEED", "knots"); }

Simplane.getStallSpeed = getStallSpeed;

So I can get AIRCRAFT STALL SPEED from the .cfg file

Is there a way now to tell the sim, (for this Plane) , a NEW value for AIRCRAFT STALL SPEED ?

WHY:
If one wanted a MOD that altered this Value, without actually having to go into the .cfg itself to modify it (which you may not be able to do in any case, if the it was in a .fsarchive)



ie somthing like

Simplane.getStallSpeed = 60;
SimVar.PutGameVarValue("AIRCRAFT STALL SPEED", "knots", Simplane.getStallSpeed);

 

[Geoff_D]

I should have looked first !!

SimVar.SetVar.SetGameVarValue("AIRCRAFT STALL SPEED","string",_value);


so maybe


StallSpeed = SimVar.GetGameVarValue("AIRCRAFT STALL SPEED", "knots");
SimVar.SetVar.SetGameVarValue("AIRCRAFT STALL SPEED","string",_StallSpeed + 10);

 

[eric_marciano]

Indeed, SetGameVarValue is supposed to let you set a value, just like Get/SetSImVarValue. Now you need to check if it works, because these variables may be read-only. Only a quick test will let you know, and I would be happy to know the result of that test

 

[Geoff_D]

Eric, as a recognized gauge developer, I would be interested in your take on this.

Basically - I want to Programmatically change the Value of a parameter read from system.cfg .

The Variable I am interested insetting in a MOD (until Asobo fixes the issue below), is “altitude Indicator” under [AUTOPILOT] in system.cfg,

The value of “altitude Indicator” under [AUTOPILOT] in system.cfg, not the same as the Baro Index that is controlling the Autopilots Altitude Hold.

==============================

The standard BARO indexes in MSFS seem to be (Not documented, but looking at Asobo planes, is this “By example” )


1 = Main baro (Altimeter)
2 = AP baro
3 = Transponder baro (Should not FIXED at 29.92 unless you want to introduce a maintenance issue, where it looses calibration)


So Logically, to select the Baro in the AP to control the AP code in the Kernel you set “altitude Indicator” to 2 – as is done in every ASBO Plane, and most 3rd party planes.


But setting it to 2, actually cause the Kernel to use Baro:3 !!!


If you just hit “B” to set all Baros, its not an issue, but if the AP has a baro Adjustment, it may well alter the value for baro:2 – but it has NO EFFECT on the AP’s Hold Altitude, because the SIM;s kernel is looking at baro:3 in error …


WTF did that one get missed !!!

 

[WarpD]

Why would they be hard coded at all? That makes no sense whatsoever. Many aircraft have multiple barometric systems onboard. Pilot side, copilot side, standby altimeter... just as example. This is not something that should be hard-coded. It was a well defined process in FSX... they should have used that system as a base. Just because you can re-invent the wheel... doesn't mean you should.

 

[eric_marciano]

Geoff, I am not sure I understand what you want to do here. As WarpD says, in MSFS you can have several altimeters with different barometric settings, so they will show different values for the same actual altitude. Is it what you want? If so, no need to change the altitude indicator value.
Now if there is another reason that I misunderstood, please explain me again. But I am sure that if Asobo set a value in a config file, they will not ignore it for a hard-coded value.

 

[B21-soaring]

SimVar.SetVar.SetGameVarValue("AIRCRAFT STALL SPEED","string",_value);

Geoff note you have a .SetVar. typo in that code, i.e. in general it would be SimVar.SetGameVarValue("AIRCRAFT STALL SPEED","string",_value);

However I'm a bit dubious that SetGameVarValue for a 'config' variable will work as you're hoping - only testing will tell.

 

[Geoff_D]

My Typo .. thanks ..

It is not used very much at all, but both Aobo and at least one other 3rd party plane (that I have) are using that function.

 

[Geoff_D]

Why would they be hard coded at all? That makes no sense whatsoever. Many aircraft have multiple barometric systems onboard. Pilot side, copilot side, standby altimeter... just as example. This is not something that should be hard-coded. It was a well defined process in FSX... they should have used that system as a base. Just because you can re-invent the wheel... doesn't mean you should.

Thank you for your valuable input on the matter, it is always appreciated -- Forgot you might still be around !!

 

[Geoff_D]

Geoff, I am not sure I understand what you want to do here. As WarpD says, in MSFS you can have several altimeters with different barometric settings, so they will show different values for the same actual altitude. Is it what you want? If so, no need to change the altitude indicator value.
Now if there is another reason that I misunderstood, please explain me again. But I am sure that if Asobo set a value in a config file, they will not ignore it for a hard-coded value.

I cannot make it much clearer :-
Ref: C172 Steam's Baro Indexes

1 = Main baro (Altimeter)
2 = AP baro
3 = Transponder baro (Should be FIXED at 29.92 unless you want to introduce a maintenance issue, where it looses calibration)


So Logically, to select the Baro in the AP to control the AP code in the Kernel you set “altitude Indicator” to 2 – as is done in most ASBO GA Plane, and most 3rd party GA planes.


But setting“altitude Indicator” = 2, the Kernel actually uses Baro:3for the AP's altitude Hold processing.

If you want the AP to use the baro that is in the AP, and adjustable within the AP, by the AP's baro knob, you have to set “altitude Indicator” to 1
If you want the AP to use the baro that services the Analogue Altitude gauge , and adjustable by the Analoge ALTIMETER knob, you have to set “altitude Indicator” to 0

With “altitude Indicator' =2 (as set in the system.cfg file, the AP references it altitude off the Transponder's Baro)

Now this does not appear to be too much of an issue, if you are Lazy, and use the FAKE "B" key to set ALL the baros, as then it does not matter which one the AP is using, the B button has set them all....

But it should not have set the Transponder, which is meant to ALWAYS display FL.
That can be fudged around by having the TRANSPONDER display "Pressure Altitude" ie FL -- so it does not matter if its baro has been changed and is not STD Pressure.

 

[WarpD]

I really don't understand a separate baro for the AP, let alone the transponder. The transponder typically gets input from either an encoding altimeter (the value provided is the pressure altitude) or from a "static altimeter" that is always at 29.92. There is no need for the transponder to have a baro setting of any type whatsoever. That would not be realistic.
As for the AP, it should only have it's own baro setting IF the modeled AP had one. As example, a Pro Line 21 autopilot would not have it's own, it would use the baro setting on the side in control (pilot or copilot).
I think that Asobo would be better off returning the baro setting behavior to that of FSX. This system seems horribly messed up and inaccurate.

On a side note... the altitude indicator setting appears to be zero based.