it can’t just be me… The WASM SDK seems to include two almost identical but
different methods of reading the same MSFS simvar. Can anyone explain why I
would choose one over the other?
I might not have been clear enough in my question. I do understand completely
“lookup_var” and “aircraft_varget” are not the same (i.e. identical). The docs
often repeat that and it’s clear the names are different and the simple code
structure you use in a WASM gauge to receive e.g. the latitude of the user
aircraft on each update cycle is slightly different. But if a WASM gauge
developer wants to receive PLANE LATITUDE on each update cycle, what’s the
difference in choosing between using the two methods? Given a free choice is
one better e.g. for performance or is maybe the recommended method by Asobo so
adopting it now positions the developer better for future enhancements? If one
method is simply better for PLANE LATITUDE and the other is better for
SIMULATION TIME that would be an odd technical strategy. Currently the
latitude of the plane is obviously a common underlying value that can be
retrieved a variety of ways. It might be the token variables are the new
preferred approach for WASM gauges, but if so that would be useful to know,
rather than simply the methods are similar but different.
I have exactly the same question and nobody answered so I will add to this topic what I believe is the case.
I think the simple answer is that there are two APIs due to organic history. The gauges API and token variables predate Simulation Variables.
My assumption is that aircraft_varget is the correct API to use for all cases except when a specific token variable exists and a simulation variable doesn’t. I’ve never seen that case though, which means Token Variables are basically for backwards compatibility with legacy content.