Startup Profiles: Difference between revisions

Jump to navigation Jump to search
Line 5: Line 5:


== Status ==
== Status ==
James would like to get starting-state support working the C172P and ideally a few other aircraft in FGaddon, he needs aircraft developers, especially the C172 team, to give feedback on the current code so he can make any improvements. Especially, he wants cold-and-dark vs ready-for-takeoff (autostart complete) vs in-air starts to work with the —state argument, then he can car drive this from the launcher. He will ask on the forum as well, the more examples we have of supporting this feature the better.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35478478/
  |title  =  <nowiki> [Flightgear-devel] State support in the C172P </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Nov 8th, 2016
  |added  =  Nov 8th, 2016
  |script_version = 0.40
  }}</ref>
James wants to get the C++ code at least approximately correct before the upcoming release, so that in the next dev cycle we can expand aircraft support widely.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35478726/
  |title  =  <nowiki> Re: [Flightgear-devel] State support in the C172P </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Nov 8th, 2016
  |added  =  Nov 8th, 2016
  |script_version = 0.40
  }}</ref>
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
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/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35166174/  

Navigation menu