20,741
edits
Startup Profiles: Difference between revisions
Jump to navigation
Jump to search
→Motivation
| Line 3: | Line 3: | ||
--> | --> | ||
{{Startup}} | {{Startup}} | ||
== Status == | |||
See the c172 for two example overlays, you /could/ add the data inside the main -set.xml but I’d strongly encourage using separate XML files to keep things manageable. Startup option is —state=<NAME> All other settings are applied on top of the overlay; the /only/ configuration it takes priority over is the -set.xml. No GUI support yet, nor auto-selection based on position. I’m happy to consider any plausible auto-selection rules, for example looking for a ‘catapult’ state for carrier-based aircraft when startup pos is a carrier, picking ‘cold-and-dark’ vs ‘takeoff’ based on runway vs parking-position on the ground. My initial name guesses and selection rules are below. I will add a <description> string to each overlay to allow nicer GUI menu selection. For the auto-selection, I’m considering adding some criteria to the state overlays, basically min / max altitude values to make more intelligent cruise vs climb/approach selection. That and min/max IAS values are about the only ones I can see really working, but even they would cover a good few cases. (Concorde in subsonic climb vs supersonic cruise) states and proposed selection criteria: parked (aka ‘cold-and-dark’?) : selected when at a parking stand or non-runway startup location takeoff (aka ‘engines-running’?) : selected when starting on a runway, or manually via UI cruise: select for in-air start, but maybe only above min-altitude criteria approach: selected when startup pos is relative to a runway / ILS, or cruise is excluded by altitude constraint. climb : manually selected, similar to approach but with higher fuel load presumably (I can’t think of any good way to distinguish approach and climb based on altitude, but figure more people starting in-air want to practice approaches than climb-outs) more specialist ones: moored : parked on water ??? - on a water runway with engines running (‘water-takeoff’?) [these two are to allow automatic selection for amphibious aircraft, compared to current nasty situation that occurs] catapult: takeoff but on a carrier catapult<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35166174/ | |||
|title = <nowiki> Re: [Flightgear-devel] In-air vs on-ground starts </nowiki> | |||
|author = <nowiki> James Turner </nowiki> | |||
|date = Jun 17th, 2016 | |||
|added = Jun 17th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
auto-selection depends on position init, which we currently do /much/ later in startup than where we load the -set.xml. I need to think if applying the state overlay latee is going cause any issues - it certainly needs to be applied before subsystem postinit (when Nasal runs), but I wonder if it should really be done before subsystem create/init, in which case this means moving some parts of position init earlier. Off the top of my head I don’t know any reason position init can’t happen sooner, for common cases - or at least some checks of the kind of position (we won’t know carrier location or active runway, but we’ll know a carrier was requested or that the active runway was). The concern is that the position init code is fairly fragile already, so I’d sooner work around it than start messing with when it runs. We shall see.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35166498/ | |||
|title = <nowiki> Re: [Flightgear-devel] In-air vs on-ground starts </nowiki> | |||
|author = <nowiki> James Turner </nowiki> | |||
|date = Jun 17th, 2016 | |||
|added = Jun 17th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
auto-selection depends on position init, which we currently do /much/ later in startup than where we load the -set.xml. I need to think if applying the state overlay latee is going cause any issues - it certainly needs to be applied before subsystem postinit (when Nasal runs), but I wonder if it should really be done before subsystem create/init, in which case this means moving some parts of position init earlier. Off the top of my head I don’t know any reason position init can’t happen sooner, for common cases - or at least some checks of the kind of position (we won’t know carrier location or active runway, but we’ll know a carrier was requested or that the active runway was). The concern is that the position init code is fairly fragile already, so I’d sooner work around it than start messing with when it runs. We shall see.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35166498/ | |||
|title = <nowiki> Re: [Flightgear-devel] In-air vs on-ground starts </nowiki> | |||
|author = <nowiki> James Turner </nowiki> | |||
|date = Jun 17th, 2016 | |||
|added = Jun 17th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
== Motivation == | == Motivation == | ||