Re: [Flightgear-devel] In-air vs on-ground starts

[James T. <zak...@ma...>]

> On 17 Jun 2016, at 18:36, James Turner <zak...@ma...> wrote:
> 
> 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)

Just realised a potential problem here: 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.

Kind regards,
James