WASM modules can currently see two file trees: their own package folder (read
only) and an empty work folder reserved for them (read/write). Please add
read-only access to all packages. This would let WASM modules read data from
other packages and behave accordingly. For example, a single WASM module could
read custom airport lights data from airport packages, and then write
variables to drive their model behaviours to switch lights in response to
airport traffic. Currently the work-around is to use an external application
and launch it through exe.xml and loop over installed packages to collect
data, but this is obviously undesirable and is not available on Xbox.
I would second that request of getting read only information about other
packages. I am mainly interested in all the package meta data from their
manifest.json. If would be nice if that was available to read e.g. via
SimConnect. Like stated, currently we can read that from an .exe, but would
like to do it in a wasm later down the line and necessarily for Xbox.
I second that too. This would be a very handy feature for numerous
applications.
We need this! I third and fourth/fifth this 
Happy Holidays.
Hello. First, you should post this as an idea and have it upvoted. That’s how
we review and prioritize third party developers feature request. @Paavo Part
of the need you describe would be covered by an API to request airport and nav
data I think (https://devsupport.flightsimulator.com/t/3076 ) As for
retrieving local vars from other packages to be able to write to it, I’d say
it’s up to the package creator to document which local vars he wants to
expose. @BenBaron85 I’m not sure to understand what you want to do with data
from other packages manifest.json, could you elaborate on that? I’d be
interested to know more concrete examples of usage to be able to judge if
those request can be addressed a different way or if some of them really
require a WASM access to other packages. Regards, Sylvain
@FlyingRaccoon The platform defaults to a question when clicking on “Create”
and there seems to be no way to change the type afterwards. I noticed that
shortly after posting too. Sorry about that. Anyway, let’s say we have an
airport package for EETN, including four stopbars created as SimObjects. These
are just rows of red lights for holding positions, each tied to a separate
L-variable: EETN_stopbar1, EETN_stopbar2, etc. Whenever the associated
variable is non-zero, lights turn on. Their sim.cfg has standard parameters
and a few custom parameters:
[fltsim.0]
title=EETN_stopbar1
stopbar_var=EETN_stopbar1
stopbar_poly=59.414817 24.851018, 59.414887 24.852229, 59.414852 24.864172, 59.414731 24.866077, 59.415051 24.866070, 59.415190 24.851016
With read access, a single universal module could loop over multiple airports,
collect information about their stop bars, and set EETN_stopbar1 variable to
turn on stopbar lights when traffic is inside this poly. We can currently do
this by having the module and SimObjects within a single package, but long-
term maintenance becomes a problem when tens or hundreds of airports use the
same module, and need to be separately updated when something changes in MSFS
and breaks existing functionality. It would make much more sense to follow the
modular design of MSFS and publish the module as a standalone package. And
whenever something changes, we could just update the standalone package
without having to touch airports. It would also mean better performance with a
single module polling for data instead of many. Currently we can achieve
standalone design and global read capability by creating a custom EXE that
starts with MSFS (using exe.xml config) to collect data and write it into a
file that the module can see, but asking users to run arbitrary non-sandboxed
executables on their system is better avoided. Furthermore, packages with
executables cannot run on Xbox nor be published to the in-game MSFS store,
which leads to fragmentation and people missing out on advanced functionality
that MSFS is capable of providing. There are many ways to approach this
problem, but providing global read-only access is the simplest and the most
flexible way of doing things.
Hi Sylvain, regarding a use case of querying other packages meta data
contained in their manifest.json files: We at Aerosoft are developing a vdgs
module that is active at certain addon-airports only. For that to work
correctly, we need to know within the module, not only if those airport
packages we work with are actually installed in the current sim, but also that
their “package_version” is a fit. Currently, we can achieve that easily, as
the module is running externally anyways due to missing functionality in the
wasm layer, but mid to long-term and as soon as this becomes a viable option,
we would like to refactor into wasm to also bring the full airport
functionality onto x-box. What I am suggesting is something like extending the
SimConnect_RequestSystemState() method to have “PackagesLoaded” as third
param. Which could return an array of structs with all currently loaded
packages meta data. But anything along those lines would do the trick for us.
Thanks for consideration and if you have further questions, just ask. Greets,
Ben
I think you are both trying to do something which would be way easier and more
reliably done, should this famous airport data access API would eventually be
available so, considering it’s by far the most voted SDK request, let’s try to
push for that. Because, none of the things you suggest would likely solve the
biggest issue, that is accessing airport data for Marketplace/Premium
airports, which are encrypted. That’s another reason why an official API is
what we should strive for.