In 2020 not only are there no functions to set a string type Sim Var, but RPN calculator code doesn’t work either. The only way outside of JS API is to use SimConnect.
Still the same in 2024?
Thanks,
-Max
1 Like
+1 but I can see why MS/Asobo/WT will struggle to improve it. A suggestion for a simple, pervasive, usable solution would be to have S: simvars that can contain strings, with support to read and write those in:
- XML RPN:
"hello world" (>S:GREETING) - JS:
const greeting = SimVar.GetStringSimVarValue("S:GREETING") - WASM:
FsVarError ve = fsVarsStringSimVarGet(varId, &greeting)
It’s a pretty obvious implementation but in MSFS there’s an unplanned drag to the right from RPN → WASM → JS → typescript which is tending to compromise any systems-wide improvement.
There is a new ‘Vars’ API for WASM in MSFS2024 but as far as I can tell that assumes every var type is a ‘double’ - maybe I’m wrong.
1 Like
BTW I looked at the 2024 systems.cfg SDK docs and in the [LocalVars_EX1] section it refers to setting L: vars with a type of “string” !! But I scrolled up to the [LocalVars] section and that said the same (hmmm) and then went back to the 2020 SDK docs and that suggests string values for L: vars are possible also, which AFAIK is definitely not the case. So probably just a SDK docs bug copied over into 2024.
https://docs.flightsimulator.com/msfs2024/html/1_Introduction/#LocalVars
Thanks, and yea, same thoughts and experience here. I struggled to even figure out how a unit type is set on an L var. And saw the string thing and knew that was wrong, which kinda makes the docs look unreliable.
I’m “struggling” to understand the purpose of the new Vars API, which is basically parts of Guage API plus a function to set Sim Vars directly (Guage API had to go through RPN to do that but had function to read them, which always seemed rather odd). I mean, why not just point the Guage API functions at a new back-end, if that’s what they have? Seems like that’s the point of an API, to abstract what happens behind the scenes. I’m not seeing a benefit right now to switching over since that will mean different code for 2020 vs. 2024 (maybe just some #ifdefs, but still, what’s the point).
Heck if we’re talking new/modern C++ API there are even things like std::variant, templates, or old-school void * pointers (how SimConnect does it), function overloads, unions, … and probably other ways to be able to provide various argument types to a function (eg. to send floats/ints/strings/structs/whatever using the same API).
Cheers,
-Max
It would be undesirable for the public API to require C++ (std::variant). C is the de-facto standard for language interop. That would make it tricky for things like msfs-rs.
While I’ve said the same thing about ease of creating bindings to C-style libs (regarding SimConnect), and I’m not disagreeing now either, it’s certainly possible to bind to C++ as well. Eg. GitHub - rust-skia/rust-skia: Rust Bindings for the Skia Graphics Library (Skia Graphics is a massive C++ based lib).
Anyway even with C-style SimConnect it’s possible to use variant type data to set variables with, including structures and strings. There’s no reason a new “vars API” couldn’t also handle that. I’m confused what the point is of just giving the same limited functionality (as Gauge API) under new function names.
I’m very confused as well.
With SU12, we finally got the ability to access L: vars through Simconnect, almost removing the need to have WASM modules acting just as data providers for other apps.
Almost, because we are still missing the all useful execute_calculator_code calls, which was the most important call of the Gauges API, since it allows data-driven and user-created expressions to be evaluated dynamically without requiring changes in the software (like in custom expressions to control external hardware), so we still have the need for (multiple) WASM modules that could have all been retired, had the execute_calculator_code being added to Simconnect as well.
So now we have a new API, which seems to be a wrapper of the gauges api with some scoping features added, but without a replacement for execute_calculator_code, which has been left in the deprecated api.
So we are still forced to have multiple stand-alone WASM modules all running at the same time, all generating Simconnect traffic ( to push data out to various apps ), all doing the same thing ( calling execute_calculator_code ), which we could all be retired if we could just call execute_calculator_code and gauge_calculator_code_precompile directly from Simconnect.
And yes, adding user-made String variables that could be accessed from all places (Simconnect, JS, WASM), would be another huge improvement in usability.
Indeed. Never understood why SimConnect is missing this powerful capability, especially considering how much of the sim’s scripting relie(s|d) on it. And to reiterate (beat dying horse) my other recent question in this category… someone must have looked at all the “deprecated” calculator_code functions and thought… “naaah, who needs those?”
Don’t forget format_calculator_string! Never see anyone mention the neglected thing… 
Granted there are easier ways to format strings these days, but it can still be pretty handy vs. getting a bunch of individual values for formatting some output.
Another thing the new Vars API seems to leave out is the whole (newish) InputEvents stuff (B vars) which was added to SimConnect (somewhat awkwardly). So, conversely, yet another reason (besides setting strings) one might need SimConnect in an otherwise standalone WASM module/gauge. I’m not sure there’s a JS API for those B vars either yet… so for example, as I understand it, a JS panel/gauge would need to use Comm Bus to talk to a WASM module which then makes SimConnect calls and then the whole chain in reverse for any response. And each step async… 
needwant…
One API To Rule Them All tm
SimVar.[Get/Set]SimVarValue works for B vars and I believe has since they were introduced, if I am recalling correctly.
-Matt
Ah, thanks, good to know! As usual I couldn’t find any mention of this in the official docs, new or old. Makes their omission from the new Vars API more glaring.
EDIT: Ah well now I see the API docs do link to the RPN reference of all variable types (in “Var Types” section). So does that mean all those types can be used in JS API? And B vars “set” like others? Because that doesn’t work in, for example, a standalone WASM module with execute_calculator_code() since the module has no access to any aircraft instruments. So maybe same in JS API and B vars would only work when used in an instrument?
BTW on that JS API docs page I linked, and the RPN var types reference, it explicitly states that L vars can only have numeric values. At least for purposes of SetSimVarValue anyway.
-Max