20,741
edits
Startup Profiles: Difference between revisions
Jump to navigation
Jump to search
→Motivation
| Line 3: | Line 3: | ||
{{Startup}} | {{Startup}} | ||
== Status == | |||
{{Note|as of 04/2016, a new proposal is currently being discussed on the FlightGear devel list}} | |||
* add a /sim/startup/state string property | |||
* permit -set.xml files to supply states at /sim/aircraft/states[0..n] | |||
* state has a unique string id such as ‘cruise’ or ‘orbit', for internal use, also a name & description for display in the GUI / launcher / menus; number of states is up to the aircraft developer - we define some standard state labels, so GUI / launcher can pre-select a state when user picks in-air / on final / parking stand / runway to start. (if there’s no matching state for the selected startup location, we carry on as before) | |||
* new command line option —state allows direct selection of state - /sim/aircraft/states[n]/overlay/* can contain arbitrary properties which over-write the -set.xml values eg /sim/aircraft/states[2]/overlay/foo/bar/ot=42 would set /foo/bar/zot=42 when the state is selected. | |||
* /sim/aircraft/states[n]/overlay-file-path can contain a string referencing a props XML file which is overlayed if present eg shuttle-orbit-state.xml contains /foo/bar/zog=3.141, which ends up in the main tree So this gives to ways to supply property customisations, either in-line in the -set.xml file, or in separate files which might be cleaner if there’s many properties and/or states | |||
For security, we might need to restrict which properties can be customised in such an overlay, since otherwise any property in the whole tree could be changed. Although, this is also true for a -set.xml file already I guess. I am assuming these are applied *after* the -set.xml, but prior to config options being overlaid, so if you do still set —vc or similar, they might work, or they might not. For aircraft which need more complex by-state config, this can be done in Nasal by inspecting /sim/startup/state, or of course any other property defined by the property overlay mechanism. I.e I don’t think a manual Nasal hook point is needed. I’m still busy with TerraSync features / bugs so won’t get to this for a week at least, maybe two, but any discussion about how useful / easy / horrible the above would be for real use cases, especially the C172, would be appreciated. Note I’m happy to add property-based configuration to subsystems if it means we can avoid Nasal in the common case - most things already configure via properties but I can imagine a few missing pieces that might need some Nasal right now, but could be fixed not to. | |||
<ref> {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34981795/ | |||
| title = <nowiki>Re: [Flightgear-devel] In-air vs on-ground starts</nowiki> | |||
| author = <nowiki>James Turner</nowiki> | |||
| date = Mar 31st, 2016 | |||
| added = Mar 31st, 2016 | |||
| script_version = 0.25 | |||
}} | |||
</ref> | |||
<references/> | |||
== Motivation == | == Motivation == | ||