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

[Dris]

Hi!

I want to know how to set up that the engines are already started up when opening the game. I'm ussing the SenecaII.

Thanks!

[Thorsten]

This is only possible if the plane supports this (then it should be possible to select as a state overlay in the launcher).

[Dris]

Hi Thorsten!

I have looked in the laucher and didn´t fount anything. If I want to programm that, how can I do it?

Thanks!

[TheEagle]

Doesn't the SenecaII have an autostart function ? You can just hit that when you load up FG, right ?

[Thorsten]

If I want to programm that, how can I do it?

You have to understand how the particular engine simulation in a plane works, aka what properties need to be set how to have the engine running. Then you need to write a function that sets this state. It may be necessary to alter the engine simulation to override things like spin-up times for components etc. to allow to make it quicker than a normal start-up sequence. That function needs to be called via the state overlay function.

Basically if you know enough to actually do it, you don't need instructions, if you need instructions then the problem is too tough to tackle.

Setting a reasonably complex plane to a well-defined state is a really tough problem, you have to understand how the plane works, what things like integrator windup are and how to overcome then, what different code-paths need to exist for 'init running' vs ' starting normally' and how your particular hardware might complicate things by e.g. the throttle on the physical stick being set to a certain value that would not permit the engine to start.

There's a reason there is no such thing as a general save/resume or start in a particular state in FG.

[Dris]

Okey Thorsten, thanks!

Another question: How can I set up (which command lines should I introduce and where?) that always i start the plane the property controls/engines/engine[0]/magnetos has the value 3?

Thanks!

[Hooray]

There's a reason there is no such thing as a general save/resume or start in a particular state in FG.

I don't disagree with anything you said, since you have clearly experience working around these restrictions, you obviously understand what is involved to implement such a feature given the current situation.

However, with that being said, this feature is actually widely supported in the majority of flight simulators, i.e. not just in games, but indeed professional ones.

And as a matter of fact, this feature also used to work in FlightGear originally. The truth is, it got hugely crippled by the introduction of the so called "presets" system at the time (early 2000s), and never got fixed up/repaired afterwards: https://wiki.flightgear.org/Fixing_presets


Also, shortly thereafter, another major feature got introduced that moved more stuff out of the realm of C++ space into fgdata space: Nasal scripting.

Without FlightGear's huge reliance on user-space "code" (XML, property rules, presets and scripting), it would be relatively straightforward to provide aircraft developers with the infrastructure to provide support for saving/loading and resuming flights using well-defined hooks.

So, please let's not mistake FlightGear's current architectural shortcomings as fundamental showstoppers - a plethora of commercial and professional flight simulation software do support these features, without requiring the degree of "custom coding" that our aircraft developers currently have to use.

Fixing this, is a long-standing challenge, and one that's been repeatedly mentioned by some of the most seasoned contributors with a background in professional flight simulation - for instance, you only need to look up Richard's comments in this context, to learn more about the professional side of things, from someone who also happens to be familiar with FG core internals, including the shuttle specifically.

https://wiki.flightgear.org/Reset_%26_re-init

Realistically, FlightGear's way of being developed, has crippled a number of important features over the years, the ability to reset/re-init and save/load to resume/continue a flight, being one of the longest-standing and most serious restrictions of FlightGear as a whole, which also affects a number of other features, that may seem unrelated at first glance, but which are made nearly impossible because of FlightGear fragile notion of reset/re-init and state handling in general.

Again, Jon S. Berndt, David Megginson, Andy Ross, Melchior Franz and more recently, Richard Harrison have rightly pointed out that this is an essential feature for any flight simulator to be taken serious.

For instance, see Jon's comments here (JSBSim): The [Re-]Initialization Process in FlightGear: A Specification Proposal

Without supporting Nasal and XML systems, it would (was) relatively straightforward to support these use-cases (even though tedious and time-consuming to implement!)
The Canvas system also added more complexity on top of all this obviously.

Thus, clearly, the folks with a professional background in flight simulation and FDMs, do understand that it's indeed FlightGear's fault that we are not supporting these use-cases

As a matter of fact, back when FG 1.0 was released, a number of core devs were opposed to the idea of releasing a 1.0 release without returning this feature first

It seems, Gijs deleted the original article, but this has been getting quite a bit of attention over the last 15 years actually: https://wiki.flightgear.org/w/index.php ... r_Sessions

[Thorsten]

Without FlightGear's huge reliance on user-space "code" (XML, property rules, presets and scripting), it would be relatively straightforward to provide aircraft developers with the infrastructure to provide support for saving/loading and resuming flights using well-defined hooks.

That seems to be the issue - FG simulates not by ticking options in a pre-defined simbox (that's more or less how YaSim operates) but by actually adding code to the default setup.

That allows us on the one hand to define arbitrarily complex chains of failures that may prevent an engine from running (that would be insane to put into a pre-defined simbox, no flight simulator coder would usually consider the possibility of a particular attitude adjustment thruster being always on because the logic to command it off is failed) - but it also means that especially the top-end craft are highly customized beasts which bring significantly more than the defaults to the table.

And as a matter of fact, this feature also used to work in FlightGear originally.

That could only have been because aircraft were really simplistic back then and nobody gave a damn about complex failure modes. Once you really are interested in things like realistic system and failure simulation, there's no way 'pre-defined hooks' could be sufficient.

Without supporting Nasal and XML systems, it would (was) relatively straightforward to support these use-cases

It is relatively easy to do it for YaSim.

Thus, clearly, the folks with a professional background in flight simulation and FDMs, do understand that it's indeed FlightGear's fault that we are not supporting these use-cases

I disagree - the benefits in terms of the realism we can add to systems and in terms of how we can tackle really exotic situations not forseen by FDM core developers by far outweighs the drawbacks.

To say it bluntly - I'd rather have a Shuttle, a Viggen or an F-16 with complex weapons systems than an out-of-the box save/resume - and it's very clear that we could not have possibly both the freedom and a generic solution.

[Hooray]

That could only have been because aircraft were really simplistic back then and nobody gave a damn about complex failure modes. Once you really are interested in things like realistic system and failure simulation, there's no way 'pre-defined hooks' could be sufficient.
[...]
I disagree - the benefits in terms of the realism we can add to systems and in terms of how we can tackle really exotic situations not forseen by FDM core developers by far outweighs the drawbacks.

To say it bluntly - I'd rather have a Shuttle, a Viggen or an F-16 with complex weapons systems than an out-of-the box save/resume - and it's very clear that we could not have possibly both the freedom and a generic solution.

I do understand your point of view - however, please don't shoot the messenger: People doing simulators for a living, do understand that we can have our cake and eat it, and they've been pointing that out for decades.

Like you rightly said, the complexity of providing re-init, save/load and resume functionality is proportional to the degree of systems/failure modeling, and to sum it up in one word REALISM - however, please let's keep in mind that not a single FlightGear aircraft is certified to be used professionally, whereas a number of professional simulators do indeed have certified aircraft that can be used for flight training/proficiency purposes, exactly due to the underlying fidelity/realism of systems modeling done.

Thus, it'd be overly simplistic to indicate, that we are in a different position because of our degree of "realism", whereas any professional flight training software, inevitably needs to provide more realism than we can possibly hope to. And again, I am not referring to FSX or X-Plane here (even though some X-Plane stuff is indeed certified meanwhile IIRC).

Both, Richard H. and Jon S. Berndt have extensively covered why fixing up FlightGear would be important, and possible.

PS: The term "hooks" is used as an API term, and as such it is indeed sufficient - the original SGSubsystem API also provided "hooks" for init/reset and save/load, it's just that nobody except for David Megginson himself bothered to fill out those stubs

[Thorsten]

however, please let's keep in mind that not a single FlightGear aircraft is certified to be used professionally, whereas a number of professional simulators do indeed have certified aircraft that can be used for flight training/proficiency purposes, exactly due to the underlying fidelity/realism of systems modeling done.

That has nothing to do with FG capabilities though. The Shuttle has been very well received by former NASA simulation people and rather enthusiastically praised for the level of realism - however I would have no idea how to get it certified in any way, nor would I possibly want to spend the time.

Similarly with other aircraft - the capability is there.

I seriously doubt that many other simulator platforms would allow to code a spacecraft with that degree of realism at all.

So in essence you're comparing aircraft simulation platforms with a much more general flight simulation platform.

whereas any professional flight training software, inevitably needs to provide more realism than we can possibly hope to.

I don't think so. If you are able to support every procedure in the operations manual, people can train the manual. If it's not in the manual, it's likely not relevant enough to be trained.

The term "hooks" is used as an API term, and as such it is indeed sufficient

Well, no - the problem exists on a logical level - if you can't know in advance what's important in what way, you can't generally save it. Clearly an aircraft simulator has a much easier time here because the number of complications is rather limited compared to a flight simulation.

(And note that the platform FG has been used for FAA certified simulations... just no aircraft in the repository is certified).

[MariuszXC]

A quick question.
I understand, that given arbitrary complexity of an aircraft model it may be impossible/very hard to implement a generic save/restore on logical systems level, but there is another way, which is used every time one suspends/resumes their laptop with an arbitrary complex mix of running applications. It is called a binary image save/restore.
Has it been considered as a possible alternative for FG save/resume?
Are there any drawbacks other than possible large size of a binary state image file?

[Thorsten]

Has it been considered as a possible alternative for FG save/resume?

No, not to my knowledge.

[Hooray]

Binary snapshots basically require a fixed amount of memory to be pre-allocated. That's what's commonly done for save/suspend and resume (hibernate) operations, or virtual machine setups.
In the case of FlightGear, there used to be a set of predefined hooks for things like pause/unpause and time warp, including support for saving/loading (serializing) state to disk and resuming operations.
However, the majority of subsystems never adopted this design internally (basically, the corresponding stubs remained empty). Later on, this feature got even more crippled when the presets functionality was added (ironically, at the time, the idea was to indeed allow an aircraft to start up in a pre-defined state/location, which obviously collided/interfered with the capability to save/resume flights).

Even if all C++ subsystems had working save/load/resume functionality, that would never work "as is" for anything implemented outside C++ space - like Thorsten said, the degree of systems modeling that is these days supported outside C++ space (specifically in XML and Nasal) is extensive, and basically without limits.
That is why Andy Ross and Melchior Franz originally discussed not to continue with our "ad hoc" adoption of XML/Nasal "code" that sits on top of listeners, but rather uses the underlying SGSubsystem machinery, so that even logic residing outside C++ space, can access key simulator events like save/load and resume, and allow aircraft developers to internally encode their logic such that it either serializes/unserializes internal state or disregards state - like Jon originally pointed out (and as Thorsten has alluded to), some "systems" will literally need to discard internal state, while running some loops to "catch up" with new state to compute internal state, or everything will be invalid.

Again, this is a long-standing challenge, but like Richard pointed out repeatedly, it certainly isn't one that doesn't have a solution, it does require a different kind of coding (and discipline), and like Thorsten said, it won't work "automagically" for existing aircraft - i.e. we really cannot hope to end up with working save/load/resume functionality without also fixing up the exact places that contain so much code and heuristics/logic outside C++ space.

Either way, stopping to use fgdata-level logic like Nasal "as is" would certainly be a worthwhile thing to explore, because once Nasal code is subject to the same SGSubsystem infrastructur, it becomes much more straightforward to clean up the existing mess. Likewise, XML-based systems (FDMs/AP/Property Rules) would also need a way to encode heuristics, i.e. how to deal with a save/load or resume event internally.

These days, we actually do have a number of heavily overlapping features that have related functionality, including specifically the fgtape system (which is all about saving/replaying flights/state), but also the multiplayer system (which is about replicating local state to other fgfs multiplayer instances), but also support for multi-instance setups (which is all about replicating a single local aircraft/flight across multiple fgfs instances). Furthermore, there's Richard's Emesary system.

In other words, there is now a handful of promising options on the horizon to eventually fix up the current design "some day".

[Thorsten]

For any given aircraft that you happen to work on as maintainer, save/load or states aren't terribly difficult problems, they're just tedious to do if the state is large enough.

So it's not that some features core-side would be needed, a simple Nasal script does the job once you have systems that support being commanded into a certain state.

[Hooray]

right, but again: it's a feature that used to work in FlightGear and one that is commonly supported in many other simulators -including professional ones- so it is obvious that people kinda expect it. The beauty of turing-completeness is that you don't need feature XYZ once you are in scripting space - but the point is that stuff like startup situations, reset/re-init primarily no longer works because of moving more and more sophisticated functionality out of core space into scripting space.
This is not to say that a certain "core feature" is needed, but what would be useful is a standardized interface to bridge this gap between the core and fgdata space, and that is exactly what people like Jon, Melchior and Andy discussed long ago.

Obviously, someone with your professional background, and with your track record of contributing to FlightGear could probably also pull all this off in assembly space, but that's not the point of the exercise. Reset/re-init stopped working when people began using more and more XML/Nasal stuff, without really bothering much what the core side is doing, or needs done to make things work properly (there actually is /sim/signals, once introduced by Melchior himself). Obviously, people intimately familiar with FG/Nasal and their own aircraft systems, can work around these restrictions by implementing reset/re-init, checklists/situations or saving/loading functionality without ever looking at the core side of things, 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.

As has been said previously, saving/loading and resuming a flight is basically a matter of "state management", and that is something that is poorly-formalized in FlightGear (as James has been pointing out for many years now) - but it's also heavily overlapping with other features that actually work already: multiplayer, multi-instance setups or fgtape/replay functionality.

For the time being, the project has been re-inventing the wheel over and over again, without recognizing, let alone addressing, that all of these features are about "state management", so that people wanting multiplayer support, replay support or multi-crew/shared control support, end up working on different types of "formalizing state".

Richard hinted on this on the devel list, when he pointed out how the MP system could indeed use Emesary, and so could the fgtape/replay system.
As long as we continue looking at these features in isolation, we will keep to ignore that these are basically about the same type of state management.

This is not to say that we cannot work around these limitations in XML/Nasal space, but like you said, even just formalizing all these data/data flow dependencies is rather tedious as is, now imagine what is entailed in adopting our existing checklist system, startup situations, multiplayer/multi-pilot, multi-instance or fgtape/replay support.

Under the hood, we could do away with much of this at the cost of using optional state attributes to encode update and serialization semantics.

By exposing the SGSubsystem API to scripting space, it would all of a sudden become possible for "the core" to tell what's going on, i.e. which scripts live in what scope and how they relate to certain simulator events (signals), like reset/re-init, save/load and resume flights