yes, more or less - my answer was in response to the other question the OP asked a few days ago, i.e. using an external FDM and starting fg with a running aircraft to shoot approaches - which is why I mentioned the "presets" feature.
Otherwise, the more common, FG specific method, is providing an "autostart" feature for different scenarios/situations - usually, in the form of scripts and/or property rules.
More recently, this is commonly implemented on top of the "Aircraft Checklists" feature, i.e. by making checklists executable:
http://wiki.flightgear.org/Aircraft_Che ... _executionIIRC, the extra500 has an even more sophisticated checklist/tutorial system using some kind of hybrid approach:
http://wiki.flightgear.org/Extra_EA-500 ... ist_dialogFor the time being, none of this -unfortunately, too useful for the original presets use-case, i.e. shooting approaches by telling FG to position the aircraft on a 10 mile final with the engines running and the corresponding landing configuration applied.
Equally, this is not commonly supported at runtime via the "location (in air)" menu/dialog, because there's so much aircraft specific logic that needs to be hooked up the initial state desired:
http://wiki.flightgear.org/Startup_SituationsFor some background, here's Jon's original proposal to formalize/standardize this much better (pre-dating reset/re-init by several years):
The [Re-]Initialization Process in FlightGear: A Specification ProposalJon S. Berndt wrote:In order for the FDMs to consistently and completely handle a reset request
from FlightGear, there ought to be a specification that describes what is
supposed to happen. Here's a first cut at what a specification for the reset
function might say:
1) There MUST be separate functions to
a) initialize cockpit controls, and
b) initialize the FDM.
Controls_init includes things like yoke position, trim, engine controls, et
cetera. This is crucial when one or more inputs are coming from the keyboard
as opposed to from a joystick.
The first time around, the caller MUST call both, but subsequently the
caller MAY call FDM_init alone. FDM_init MUST behave the same on init and
re-init.
The rest of this spec is devoted to the FDM_init.
2) FDM_init MUST be "clean" and 100% reproducible. That means that the FDM
MUST NOT remember anything from before the init. This includes
systematically initializing (including re-initializing) anything in the
property tree that it cares about, as well as any internal variables
(including any cache values, history, rates, momenta, et cetera).
3a) The following properties "belong" to the FDM. The caller MAY specify
any/all of these, and the FDM MUST respect them:
-- latitude, longitude, and altitude;
-- heading, pitch attitude, and bank angle;
-- groundspeed.
3b) The following properties also "belong" to the FDM. The caller MAY
specify them, but the FDM MAY choose to ignore what the caller says:
-- yaw rate, pitch rate, and roll rate;
-- slip angle and rate of climb.
4) If the caller specifies any other properties, the FDM MAY ignore them or
MAY respect them.
5) The caller does NOT NEED to specify any of the properties mentioned in
item 3.
Assuming settings are passed via the property tree, the FDM MUST interpret
each of the following as "unspecified":
-- A property that is entirely absent from the property tree.
-- A property that is set to nil.
-- A property that is set to "".
Remark: The key point here is that the spec MUST provide clear
conventions for indicating which properties are in the unspecified
state.
In the case of floating-point variables _tied_ into the property
tree, none of those conventions would work, which seems like a
sufficient reason why these variables SHOULD NOT be tied.
6) The altitude, if unspecified, defaults to "ground level" at the specified
lat/lon.
The rest of the properties mentioned in item 3 should default to zero.
(This is not a particularly useful default for the position, so for
practical purposes the caller SHOULD always specify an initial
lat/lon.)
7) Other than the properties mentioned in item 3, the FDM MUST NOT mess with
any other properties. This includes cockpit controls and trim.
Specifically, any auto_trim, auto_throttle, or gs_capture functions MUST NOT
be bundled into the standard FDM_init. If the caller wants to invoke such
functions separately, that's beyond the scope of this document.
8) The interface MUST use the following units: degrees for angular
variables, knots(true) for groundspeed, and feet(true) for altitude.
Remark: The key point here is that the spec MUST specify a clear
choice of units. The units in item 8, as proposed above, are not so
much a recommendation as a reflection of the existing interface,
although that's undocumented and there could well be inconsistencies
in the existing usage.