Is there a way to access Environment Variables (Environment Variables) through the new API?
I’ve tried to use fsVarsAircraftVarGet, both with and without “E:” prefix, but that doesn’t seem to work.
In the old API we could access these variables through Token Vars or XML calculator code, but both methods have been deprecated. I guess there’s still an option to use SimConnect instead, though that’s a bit more complex.
Following as I use these variables in all my MSFS 2020 WASM Modules, so when I convert to full 2024 standards I will need access to these variables.
@Arzop any idea how this goal can be achieved?
Best,
Raul
Hi,
The goal of this API is to give access to the most variables possible so Wasm modules don’t rely on RPN anymore (which is terribly slow) and have a secure way to do it.
Environment variables have been exposed through this API on our side and will be public soon (not for MSFS2024 release date) but I cannot give any ETA.
If you have others requests about this API, feel free to make them (or create a dedicated topic so others users can participate).
Best Regards
Maxime / Asobo
Well Token var lookup is very fast. Some say lookup_var() is even faster than aircraft_varget() though I haven’t verified this for myself. I’d guess because there are no unit types involved, if nothing else.
A way to set Sim Vars w/out RPN is nice.
What is insecure about the current Gauge API? Do you have any references to point me to? Or were you referring to something else?
I guess you weren’t addressing me, but feel free to check the other open questions about the new vars API here in this very forum topic/category. 
Thanks,
-Max
Game vars, like the FLIGHT_NAVDATA_DATE_RANGE, would also be quite useful for WASM FMS developers I think. In FS2020 only JS gauges could access the validity dates of the navigation data.
There’s a fundamental aspect of simulator development that you need a set of simvars and time that actually relate to each other. I.e. if you load latitude and longitude, you don’t want those two values to come from different updates in the core sim, and more importantly (counter-intuitively) when you load a set of values and the sim time, those values and the time should be exactly related.
The MS/Asobo/WT team are slowly losing track of this basic sim principle in MSFS and that’s one important context to understand the E: simvars issue.
Already we have the JS support for simvars can silently span multiple updates in the core sim, and the Avionics Framework is using the delta time value from JS which is generated from a free-running Javascript clock rather than being anything to do with the simulation time since the last update.
It’s possible we could argue MSFS has gone far enough down this route already that E:ABSOLUTE TIME and E:SIMULATION TIME are no longer connected to the sim updates anyway and programs might as well take a guess (like the JS support) calculating their own delta times which will be in the right ballpark. Thinking the sim time value isn’t needed in an API (i.e. WASM) is kinda odd for a sim.
But MS/Asobo/WT should think a little bit about how this core sim functionality has been missed. I don’t think it’s a major drama and it’ll be tempting to explain it away, but weakening the core sim will ultimately cause issues.
That’s what I always thought (assumed) structured data types were for in SimConnect. Or at least one big reason. Otherwise it may be more efficient in most cases to listen for individual value changes (and eg. using fEpsilon to filter).
Same for updating structs of values that are meant to be set at the same time. Trying to move/control an object in real-time with each axis updated on a different process loop (with “random” timing!) would not be much fun at all.
This might have made sense 20 years ago when applications are single threaded, but I feel you are misunderstanding how modern software works. I don’t see any issue; many aircraft have custom WASM flight models working great. If something “fundamental” was broken, that would not be possible.
WASM modules are single threaded. Also there’s SimConnect available there, with its structured data.
Control theory hasn’t changed just because multi-threading in large CPUs is more common now. It has to account for all variables of whatever situation it is being applied to.
I didn’t say WASM modules are multi-threaded. My comment was only expressing my confusion understanding B21’s post.
haha perhaps. I’ll be in trouble though as I teach Computer Science at the University of Cambridge where the Systems Research Group I lead focuses on real-time intelligent interpretation of large-scale urban sensor data. 
A great deal of e.g. gauge code only depends on independent variables, e.g. you can have a ‘speed tape’ animated with “AIRSPEED INDICATED” and never have an issue. TBH a lot of what is thought of as ‘complicated’ gauge programming in MSFS is actually a lot of graphics driven by a lot of independent variables.
If (and it’s a big if) you’re programming calculations not already built into the sim you quickly notice that a ‘skew’ between multiple simvar values actually makes some of those calculations impossible. It’s something I workaround in MSFS in my glider gauges. You’re absolutely right that multi-threading requires more careful consideration than all code being in a single thread locked to a single sim update loop but reading coherent blocks of data (as currently to simconnect and the model RPN AFAIK) is still doable.
I tried to use the new API to access the E: vars in 1.2.7.0 version, as mentioned in the changelog, but either I’m missing the magic recipe, or it still doesn’t work. When using the API just like for regular simvars (fsVarsAircraftVarGet), I’m getting random values, that tend to change from time to time, but are never correct.
Hi,
I do not repro this issue, is it possible to have the piece of code you’ve used ?
I’ve tested with this :
FsUnitId unitSecond = fsVarsGetUnitId("second");
FsEnvVarId zuluVar = fsVarsGetEnvironmentVarId("ZULU TIME");
FsEnvVarId simrateTimeVar = fsVarsGetEnvironmentVarId("SIMULATION RATE");
double zuluVal;
double simrateVal;
fsVarsEnvironmentVarGet(zuluVar, unitSecond, &zuluVal, nullptr);
fsVarsEnvironmentVarGet(simrateTimeVar, unitSecond, &simrateVal, nullptr);
printf("WASM - ZULU TIME %f", zuluVal);
printf("WASM - simrate %f", simrateVal);
Regards,
Etienne
Ahh, there’s a new function for that, that explains my issues, thanks!
It’s not in the documentation yet (Vars API) so I assumed one of the existing functions should work.