Custom Saving/Loading Service Triggered By MSFS Default Save/Load Functionality

[ajs117]

Aircraft Version

Stable

Description

Currently saving/loading doesn't work as it doesn't save or load the complete state of the aircraft and is using MSFS default save/load functionality. This has been successfully implemented on a certain competing payware aircraft from a company beginning with a P by dumping the state of everything including all panel state settings, flight plans, and high-level winds into custom files for each stored in AppData triggered by MSFS default save function. Upon calling the default MSFS load function, these files are read and everything is loaded.

This feature will be more significant for the A380 where long haul is much more common and also users to complete long haul flights around their busy daily lives.

References (optional)

No response

Additional info (optional)

No response

Discord Username (optional)

No response

[2hwk]

Related to #818 however as some of the information in that issue is outdated (we can now pipe data between WASM and JS reliably), the issue of state persistence in 2024 is more feasible to tackle (although still a difficult task, definitely not a good first issue for new contributors).

Note that as over 2/3rd of our codebase related to instruments is in js/ts (msfs-avionics framework) and every panel in our aircraft projects (down to the battery display) is using the new MSFS HTML based API and not the legacy WASM gauge API.

Thus a lot of what would apply to other addons which are primarily using the WASM API would not apply to FBW projects that are written in both js/ts as well as with some elements in rust and cpp where it makes sense to exist.

Furthermore, as the default MSFS save/load system does not include an auto-save function, nor does it currently dump panel state from HTML JS based instruments beyond what is captured by L:Vars, we will probably be biased in these cases towards our own custom implementation (and methods) and not one based on default MSFS save/load functionality.

This will probably have some trade-offs when it comes to working with external software but in the end we prefer the reliability of our own code over having dependencies.

Specifically for systems with a rs and cpp based implementation, using the work folder in AppData along with MSFS save files is a more viable idea and one that is already being used for fuel states (per ATC ID) as a proof of concept. This is currently already active and is a feasible starting point.

Complete state loading is definitely in the pipeline, but primarily for now the efforts will be focused on where it reduces drag for developers (i.e. having the ability to load in on a flight plan at a certain segment would be useful for testing) and will be probably be iterative and in small tranches of work (prototypes, proof of concepts, etc.) and not an entire save/load system service overnight.