Hello! I’m getting the error in the subject line when MSFS builds my
standalone WASM module project. The full error message:
1. WASM: ERR_VALIDATION_ERROR (-4095 / fffff001)
2. env_WASM_set_named_variable_typed_value not found in C library imports
3. WASM: Error -4095 / fffff001
The same WASM module uses a number of other GaugeAPI functions, such as
set_named_variable_value(), get_named_variable_typed_value(),
aircraft_varget(), and so on, all of which builds fine if I comment out the
set_named_variable_typed_value() call. MSFS version 1.25.9.0 To be clear, the
C++ code itself compiles fine (to the .wasm), the error occurs when trying to
build the resulting package from within the MSFS project manager (.wasm to
native code). I don’t think there’s anything significant in the actual
function call I’m using… in fact it’s right next to
set_named_variable_value() which works fine…
1. ID varId{-1};
2. ENUM unitId{-1};
3. double value{0.0};
4. // ... populate IDs and value ...
5. if (unitId > -1)
6. set_named_variable_typed_value(varId, value, unitId);
7. else
8. set_named_variable_value(varId, value);
9.
I’ve tried with the WASM module built in both Debug and Release modes. I
looked all over but can’t find where these “env_WASM_” would be
exported/imported from so I seem to be stuck. Any clues would be appreciated,
or LMK if there’s any other pertinent details I can provide. Thanks! -Max
Hello @max.paperno First, don’t expect the
GaugeAPI to work properly in the context of a standalone module. GaugeAPI
needs a SimObject with a gauge context available. Then,
set_named_variable_typed_value is disabled on WASM side, although still
exposed in the SDK header. It’s been like this since game launch but I’m not
able to explain why yet. We will investigate this to see what’s the reason for
this and change header and documentation accordingly. Regards, Sylvain
@FlyingRaccoon, your comment about the GaugeAPI not working in a stand-alone
module is worrisome. Maybe parts of it might not make much sense without a
Gauge but, the only reason why people has been using Stand-Alone WASM modules
until today, is to keep reinventing the wheel of using the GaugeAPI to pull L:
variables on the outside, using Simconnect as a communication layer. It seems
the OP is doing that as well, and while I never used the
set_named_variable_typed_value, I assure the most of the calls related to L:
variables, including the ubiquitous execute_calculator_code, not only works
just fine, but they are part of many products that has been already released
and rely on those calls. There are many of identical stand-alone WASM modules
that all do exactly the same thing, basically, which is almost the only thing
for which a Stand-alone WASM module is useful. They are used to help various
add-ons, handle hardware interfaces, and the only reason why everybody has
wrote the same module, over and over, is just one: We can’t access L:
Variables or execute XML expressions using Simconnect We have been asking
for this feature for a long while, and it’s currently the 3rd most voted idea:
https://devsupport.flightsimulator.com/t/3082 Because of this, since
products needs to be done, and developers do whatever they need to do to
achieve their goals, we are already with dozen of modules doing exactly the
same thing, all spamming Simconnect with by-directional communication to use
WASM in a client-server way to read/write those variables, all affecting the
Main thread, and let’s assume none of them has bugs. Please, consider adding
native support to read/write ALL kind of variables with Simconnect, both in
and out of process. That would make disappear 90% of the stand-alone WASM
modules out there, and performances, reliability and sim startup time will
benefit all.
Thanks Sylvain. Yes I figured something like that was the reason. I’d love to
hear the outcome of your further investigations. I’m not sure how to interpret
your first comment though… What’s the point of running a standalone wasm
module if all it can do is use SimConnect? There probably is one but I can’t
think of it right now… 
Also, most gaugeAPI method calls I’ve tried seems
to work OK…? (Thought I’m still learning what’s what and how things behave,
so there certainly could be “improper” behavior going on which I’ve yet to
find or understand). Best, -Max
@max.paperno
@virtuali Apologies, I didn’t want to worry you
with that first comment. My intent was to remind that some of the functions
are expecting to be executed in the context of a SimObject. But manipulating L
vars will not be an issue AFAIK.
Just to follow up on what works or not, I’m using the following Gauge API
functions in my new
WASimCommander module with no
issues so far, with several testers reporting in.
- execute_calculator_code() (with all result types)
- format_calculator_string()
- gauge_calculator_code_precompile()
- get_named_variable_value()
- get_named_variable_typed_value()
- aircraft_varget()
- initialize_var_by_name()
- lookup_var()
- set_named_variable_value()
- register_named_variable()
- check_named_variable()
- get_aircraft_var_enum()
- get_name_of_named_variable()
- get_units_enum()
- send_key_event()
So everything I expected to work does, except
set_named_variable_typed_value(). Though I’m not sure how many local vars
even handle unit type conversion (none so far that I’ve found when using calc
code to specify units). (Also used register_key_event_handler() at one
point, with a handler function, but didn’t keep that. Though I’m very curious
how that woks w/out any concurrency support in WASM.) Also would just like to
say I’ve had no issues running the WASM module in either release or debug
builds (besides some self-inflicted ones :). I’ve removed all 3rd party add-
ons that may run any code, and MSFS (currently v1.26.5.0) has been the most
stable ever. b^.^d (thumbs up) Cheers, -Max
Hi Sylvain, So the function compiles now in SU10… but now it seems any
mention of L vars being able to have a Unit specifier has been removed from
the docs (at least the vars type list on the RPN page). LOL Are the Gauge API
functions get_named_variable_typed_value() and
set_named_variable_typed_value() meant to be deprecated then? Or do they
have some other purpose? Thanks, -Max
Hello @max.paperno I’m not aware of any changes
of the documentation in that regard. Can you tell me where you saw the
difference between the SU10 and flighting documentation? Regards, Sylvain
In the variable types list on
https://docs.flightsimulator.com/html/Additional_Information/Reverse_Polish_Notation.htm
Pretty sure it used to say “Yes” in the “Units” column. I could be wrong…
but that combined with those API functions was what prompted me to use them in
the first place. The actual docs on specifying L vars in aircraft files
doesn’t mention units, but I don’t know if that has changed recently or not
(I’m not an aircraft designer).
@FlyingRaccoon Sorry, seems I was wrong about the docs changing, my mistake.
Still wondering about those functions being present. Thanks, -Max