Status / Update (07/2014)
|Note This article should be considered outdated, while the underlying problem still persists it is being worked on and the ideas presented here are deprecated meanwhile, thus it is purely kept for reference here, it does NOT represent the latest state of things.|
The last time, "reset/reinit" (as well as saving/loading flights) was reported to work properly, was prior to the "presets" work:
Yes, reset and save/restore are a bit broken in FlightGear right now. I'll try to fix them when I have a chance, but it will require a bit of refactoring (removing Curt's initial-state stuff, for example).
— David Megginson
In the last couple of years, FlightGear has basically never really been able to reliably switch between different aircraft at runtime, so that -so far- users need to exit and restart FlightGear in order to change the active aircraft, this limitation is rather frequently brought up not only by new users     but also by long-term contributors   and core developers, but also the project lead himself has repeatedly indicated an interest in "fixing" this (). So this isn't just something that causes confusion among new users, but also something that causes frustration among some seasoned users, contributors and developers, especially when demonstrating FlightGear to new users  where reasonable turnover times matter and restarting the whole simulator simply isn't feasible.
In fact this limitation isn't just restricted to switching to a different aircraft at runtime, but also affects other features such as saving/loading flight data at runtime  . Overall, this is also perceived as being a rather serious restriction in various FlightGear reviews during the last 10 years, a more recent example being a review from a year ago (11/2007) where the reviewer specifically stated:
- "At first, I was totally puzzled on how to change aircraft types. A search on the web revealed, you have to do this via the command line and if you want a permanent change, edit a script! Now to me, for such a competent, polished application, this was a huge let-down and one I believe the developers should address as soon as possible. Surely with this level of program sophistication, it's not beyond the realms of possibility to have a drop down list to select the aircraft type. This one issue for a lot of people will be a real turn off." 
A more mildly put example found in another review reads:
- "With FlightGear you have to choose the airplane on the command line (or with a launcher), and can't change it mid-session. With X-Plane you can change planes any time. This is a plus for X-Plane."
- "FlightGear doesn’t let you change aircraft without a restart. That’s just silly" 
This problem is mainly due to architectural shortcomings in the original init/loading code that -at least in part- even dates back to a time when FlightGear was still very new, not surprisingly said code is now facing tremendous challenges when it comes to providing support to the many new features that have been added to FlightGear since then, and which more often than not complicate the housekeeping process required to properly retain and manage session information in order to be able to return to an arbitrary state.
While having to quit/restart FlightGear in order to switch aircraft is mainly a matter of inconvenience , this issue and the fact that it has been around for so many years meanwhile, also illustrates technical low-level limitations in the underlying core code (most of which can be found in legacy procedural initialization code) that apparently could not be solved in the last couple of years, even though this issue has been brought up regularly and most core developers agree that "fixing" this would definitively improve FlightGear's architecture   .
In fact, this seemingly ever-predominant situation of not being simply able to just start FlightGear and customize the startup settings at runtime in order to pick and load arbitrary aircraft (and switch arbitrarily), has lead to several related side-efforts and projects with the mere goal of providing a convenient GUI frontend for FlightGear in order to make FlightGear more accessible to the user community, and help making FlightGear provide similar functionality to that being provided by its proprietary competitors.
One of the very first, but also most prominent and most-successful instances of a launcher being "fgrun", which was specifically written in order to simplify use of FlightGear for users with a non-technical background who may not be as familiar with just working in a shell/console environment, a capability that would otherwise in fact be required in order to start up FlightGear, which however cannot necessarily -and realistically- be expected from users on MS Windows platforms, which are in use by the majority of FlightGear users.
While fgrun is undoubtedly one of the most important side projects of FlightGear, because it facilitates and simplifies intuitive use and startup of FlightGear for users who may otherwise not be easily able to use and leverage FlightGear, it is also a very compelling example for the fact that the actual problem of FlightGear still not being runtime-configurable -when it comes to selecting aircraft- has been ignored for years - if not even given up on already by many core developers.
Some of whom who must have obviously determined that running a side project to provide these frontend facilities -not just temporarily but for many years- would be easier than getting fellow developers to agree on addressing the underlying architectural issues.
About the Relevance of User Accessibility
While the FlightGear community of core developers has long been able to pretty much ignore this problem and its underlying architectural issues, for example also by explicitly pointing out that FlightGear were intended to be a "simulator" (i.e. to be used scientifically by professionals) and not a "game" targeted at just gamers - so that FlightGear's lack of accessibility for non-technical users shouldn't be an issue, this line of reasoning is inherently flawed and broken, in particular in the context of an open source project such as FlightGear that encourages and strives on community involvement:
FlightGear as an open source project and community has always depended on, and benefited from, a diverse variety of users and contributors, with strongly varying backgrounds - all of whom who were able to contribute to different areas of the overall project.
This particular fact, is backed up by plenty of recent developments in FlightGear areas that are not at all related to core-development, but which are evident in base package-related contributions such as greatly improved aircraft and scenery, most of which being usually contributed by users who'll often haven't contributed any line of code to the fgfs core or who don't even have any coding background in general, but who'll nevertheless do make highly meaningful contributions to FlightGear as a whole.
In fact, for the time being (03/2009) the development ongoing in non-core areas seems to take place at much higher pace than the core development itself, which can for example be witnessed by following numerous discussions on the FlightGear user forums where new users regularly provide new contributions to be downloaded and tried out by fellow community members, be it in the form of new/modified aircraft or improved scenery tiles. Similarly, this is evident by following the CVS commits to the base package.
The Status Quo
Basically, FlightGear -in it's current form- doesn't really have any sort of concept about "sessions", rather the closest thing to "session support" consists currently of simply dumping initial state (property tree) to a temporary variable, so that it may later on be used to regain said state in order to -hopefully- reset the FlightGear core to a usable state, where new data may be dropped into the tree.
However, due to the aforementioned wealth of new features in FlightGear (often, interacting with eachother in many not-easily predictable ways), this attempt to approaching FlightGear sessions, is not only overly simplistic but also pretty error-prone, as it may yield hard-to-reproduce issues (i.e. because of all sorts of data/code leftovers from previous sessions possibly affecting the new session). Also, the current approach ignores the fact that most subsystems internally maintain runtime state that isn't necessarily also published in the property tree, so that even a properly reset property tree doesn't necessarily indicate proper internal state for all other subsystems.
So, the current approach of "resetting" or re-initializing FlightGear, is also highly non-deterministic and its success depends on factors such as complexity of the modeled aircraft and varies with use of more complex features such as scripting or use of certain subsystems whose re-initialization support isn't yet mature enough, or more generally: simply non-existent so far.
The Concept Of Data "Scopes" and Property Node "markers"
Providing proper session support in FlightGear means inevitably to do property tree housekeeping based on the scope of the data that is being written to the tree, some data for example may have inter-session scope (i.e. being relevant as long as the process is running, regardless of which aircraft is being used), while other data in the property tree may only be relevant to the current aircraft's session, meaning it might have to be reset to some pre-defined state or possibly even completely deleted from the property tree.
One simple and straightforward way to do this would be to maintain this meta information in the form of extra attributes for all nodes (i.e. a scope="aircraft" attribute), such attributes would be easily supported by both, XML files and the property tree. So that these attributes could be used as "markers" to mark property nodes in order to communicate their lifetime/scope to the fgfs core, which could thus easily recycle/garbage collect the property tree according to these attributes.
The Pros & Cons Of The Property Tree
While the FlightGear property tree -being it's central nervous system- is clearly one of FlightGear's greatest assets, it also introduces some subtle new technical (and management) challenges, as the open nature of the property tree encourages and enables anyone (users, contributors and developers) to easily access internal simulator state by reading from and writing to a very intuitive tree-like hierarchy of key/value pairs, which at the same time means that it's getting increasingly harder to properly categorize type and scope of state information being written to the tree in order to manage session information based on the relevance and lifetime of the information.
While it is indeed possible to do some basic categorization by following proper naming conventions, as well as putting restrictions on where to put certain data (within the property tree), these approaches to maintaining session information have their own challenges concerning their applicability and scalability when it comes to dealing with complex data sets featuring mutual dependencies.
Furthermore, starting to re-arrange the Property Tree (categories and names) in FlightGear to properly reflect a more appropriate session-oriented data hierarchy would not only complicate things unnecessarily, but would probably also break many of the existing config files, which would then have to be patched. Thus, this approach is not favored in this discussion of the issue, instead the idea is to individually store session-information for properties, possibly using an inheritance-based technique to allow for recursively marking all children of a node.
FlightGear's support for Property Listeners/callbacks, as well as its support for scripting using the Nasal scripting language introduces additional possible challenges concerning the feasibility of implementing session support in FlightGear, mostly because of the current habit of allowing aircraft authors/contributors to provide arbitrary listeners and scripts in a non-formalized fashion (even without requiring them to explicitly provide "cleanup" code as well), that are automatically loaded into global state, which may however not only have dependencies to aircraft-specific properties, but which may also "stick around" to possibly interact negatively with following aircraft sessions.
Thus, one essential step towards preparing FlightGear for a future with reliably resettable subsystems, would include requiring users to explicitly provide cleanup code , so that registered listeners can be automatically disabled/unregistered, as well as formally putting all aircraft-specific Nasal scripts into an aircraft-specific Nasal context (or possibly just a module/namespace (hash)), so that the fgfs core can reliably call cleanup code  to fully disable and clean up all registered listeners, as well as purge the Nasal interpreter from any aircraft-specific scripts. In the same sense, all other non-aircraft specific Nasal scripts should live in their own contexts/modules to ensure that they can be easily addressed by the core without affecting unrelated scripts.
- David Megginson (Mon, 24 Nov 2003 07:22:13 -0800). Re: Helicopters: wow!.