How to set up that the engine is already started when log in

[S&J]

There are a lot of planes, GA and gliders that don't have massively complex systems.

Just aerodynamics that produce a stable glide and a piston engine that's needs a throttle setting

[Thorsten]

but continuing "as is" is definitely not in the best interest of the project, and also isn't good for the sanity of the folks working on stuff like reset/re-init.

I still disagree.

The issue is not a design flaw but a logical consequence of how FG allows complex craft, and the benefit by far outweighs the drawbacks as far as I am concerned. You're stuck in a simpler world where aircraft used to be just 'data' being processed by the core. Luckily we've left that behind.

So there is no thing you can 'fix' core side or design side.

Continuing 'as is' works indeed best for the project, and people just need to give up on general save/resume as it would destroy more than it gains.

Instead, we need to teach maintainers how to design aircraft side to make it happen with reasonably simple Nasal. For most craft this will be no more than a few hours work.

Just aerodynamics that produce a stable glide and a piston engine that's needs a throttle setting

So you just write aerodynamical state to file and resume it - costs you five minutes to copy/paste the relevant Nasal script.

[TheEagle]

Instead, we need to teach maintainers how to design aircraft side to make it happen with reasonably simple Nasal. For most craft this will be no more than a few hours work.

I agree - there's nothing wrong with each craft having it's own save / resume functionality, as the Shuttle for example. But it'd be nice if that would actually be implemented for more aircraft, and if you could select a saved state from the Launcher (which could of course be done with the existing state system.

[Hooray]

well, people will usually want to:

- start up an aircraft in a custom configuration, e.g. for shooting approaches (think student pilots, CFIs or people wanting to maintain proficiency)
- be able to reset/re-init (e.g. to change airports/location or even just the weather/environment)
- be able to save/share pre-recorded flights with other users
- use the multiplayer feature to do flights with other folks
- set up fgfs on multiple computers to create a home cockpit using a handful of computers
- save/load and resume flights

obviously, we could teach people to do do all of this manually (e.g. in scripting space ), or provide a core-level structure for logics residing in fgdata space to play nicely with the fgfs core - if in doubt, feel free to look up what any core developer has said about the problems arising from more and more stuff like this being implemented in fgdata space, to see for yourself if all of them are somehow mistaken, or maybe ... just maybe, that we're having an actual problem here complicating state management enormously

[Thorsten]

obviously, we could teach people to do do all of this manually (e.g. in scripting space ), or provide a core-level structure for logics residing in fgdata space to play nicely with the fgfs core

You're missing the point (again) - it's a logical problem, there is no structure core-side missing or could be implemented to be helpful.

The logical issue is that the definition of a 'state' needs to be assembled and applied, and that this description contains information about sequential setting of switches, functions running with some values etc. This is not just 'data', this is data with meta-information how to use it that you can't easily predict.

The core does what it should, the aircraft does what it should, just the core can't know what the aircraft needs - so it has to be defined aircraft-side.

I mean, in all these discussions you've never even said how those mysterious 'hooks' or 'helpers' ought to look like.... Because, let's face it, you only have a foggy idea of what e.g. the 'state' of the Space Shuttle (or the weather system for that matter) is in actual reality.

well, people will usually want to:

Well, people will usually want to

* fly complex aircraft
* experience a realistic weather environment
* avoid complicated bugs

and I'd argue that they want that more than being able to share pre-recorded flights.

And this is one of the cases where you can't have everything. Comparing this with a single purpose simulator (the commercial pilot trainers have specific cockpits for one aircraft only, you can't simply decide to fly a Fokker Triplane in them) is generically unfair, because for a single purpose sim you obviously know what a 'state' comprises and the distinction between 'simulator-side' and 'aircraft-side' is increasingly meaningless.

[cgdae]

It should be possible to save / resume Nasal state. Would that help?

Some nasal state that depends on things that are not restored, eg. outside the property tree, might be fragile on resume, and certainly network connections will appear to instantly fail. But if we could resume listeners and timers and variables and threads, it might take care of a lot of the basics.

- Jules

[Thorsten]

As I said, I don't think it's terribly complicated to write a state to file when you understand the aircraft. For many aircraft it'd be really simple. People just need to be told what properties need to be saved.

To give an example. JSBSim has a host of velocity components in different frames and coordinate systems, and FG produces yet some more. Most of these are derived and will be overwritten when you try to set a property - some are not.

But once you have the info which components need to be stored to write the kinematic state of the aircraft, it's a trivial matter to do it.

So in my view it's lack of information how to do it rather than lack of supporting features that prevents a more wide adoption of save/resume. Technically it's more or less worked out, if it works for the Shuttle, it sure works for a hangglider.

[Hooray]

It should be possible to save / resume Nasal state. Would that help?

Some nasal state that depends on things that are not restored, eg. outside the property tree, might be fragile on resume, and certainly network connections will appear to instantly fail. But if we could resume listeners and timers and variables and threads, it might take care of a lot of the basics.

While it would be interesting to learn what you're having in mind here, I really doubt that this would somehow magically "solve" things.
Like Thorsten said already, the issue isn't writing state to a file, but dealing with state dependencies, i.e. chains of dependencies and how they relate to one another if/when the simulator pauses/suspends operation, serializes certain state to disk, and then wants to resume operations afterwards.
It really is an interesting problem - but it isn't easily solved by having support for timers or listeners to suspend/resume.

Indeed, modeling complex subsystems on top of timers and listeners is rather fragile and also hasn't really helped Nasal's reputation, many GC issues were really only understood when people figured out that "events" in the subsystem manager is short-hand for "Nasal timers": https://wiki.flightgear.org/Nasal_Events

As Thorsten indicated already, the underlying systems need to be designed with this use case in mind - Thorsten has extensively written about the underlying issue on the devel list.
James, Richard and other core devs mentioned how the Nasal engine is complicating "state management" from a core perspective - and that isn't easily solved.

This is a problem that all modern browsers ran into when they began using JavaScript for internal purposes - i.e. multi-window browsers with multiple tabs open, where you simply don't want scripts from one tab to interfere with other tabs and vice versa, let alone with "core" scripts.

As a matter of fact, we'd want to use different "contexts" for different types of scripts: think 1) aircraft, 2) scenery, 3) UI or 4) misc - right now, we're loading/dumping all scripts into a single global Nasal context, which is also why it is complicated to track garbage collection "per script" (Richard has done extensive research on this).

Again, it really is an interesting problem - but it isn't easily solved - even though I'd be intrigued to learn how you envision to serialize/deserialize something like a timer or a listener callback, because there's frankly more to it than the underlying callback (function id) - there's a bunch of surrounding state, and the way we're using these callbacks in FG, really doesn't lend itself to simply dumping a function id and its closure/stack frame to disk to suspend and resume operations later on.

Either way, if you are serious about looking into this, this seems like something that would be better discussed on the devel list, i.e. with fellow core devs who've previously written about the issues revolving around reset/re-init and save/load/resume (for the time being, given who's around, that'd seem to be mainly James and Richard).

PS: If dumping a stack frame to disk and cont'ing that later on really is what you had in mind, you'll want to look up the implementation of naContinue() in $SG_SRC/nasal as well as the naRuntimeError(), both of which have access to this sort of internal info - but it certainly isn't for the faint-hearted (it's touching the GC stuff that Richard worked on a while ago). But again, I think Thorsten's perspective is spot on when it comes to systems having to be designed for this - there is no underlying Nasal/core issue here, other than the lack of a proper interface to play nicely with the fgfs core outside C++ space, because stuff doesn't use SGSubsystem* and friends, but rather timers and listeners, or property rules / FDM systems - which are basically opaque to the fgfs core (again, both, James and Richard have extensively commented on this over the years, and most recently, Edward was dealing with reset/re-init too - for unit testing purposes)