the thing is that there is already a way of doing this... each craft requires meta tags and the proper options to be added... there has been talk on the developers' mailing list about how to do in-air starts... the main thing is to allow the craft to cycle through its routines several times so that it does have time to spool up and get everything set and balanced for flight at that point in time... then the sim would allow the operator to take over and fly the craft... all of this preparation stuff would take place behind the cloak of the splash screen... i think, but am not sure, that the c172p has had some of this capability added to it... i don't recall if all the work in the sim and in the c172p were completed to be able to demonstrate this... it was certainly discussed and some work or thoughts posted...

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

frankly, it is a freaking mess to code this up for any non-trivial aircraft (i.e. anything more complex than the ogeL, ufo or c172p) - supporting this properly needs a fair bit of infrastructure which is currently misssing, or you're literally coding up all the missing infrastructure in a highly use-case specific fashion, which is likely to conflict with other parts of the simulation.There is quite a bit of overlapping requirements and functionality when it comes to the MP system, dual-pilot, and especially the instant replay system - but also the checklist system, unfortunately these are all using hugely different approaches that are not exactly compatible either.

Technically, this would involve quite a bit of coding, and it would only be feasible to approach this by designing all systems (FDM, property rules, Nasal etc) accordingly - and that also includes a capability to implement state transition, including tinkering with the dt value of the simulated time, so that the simulation can literally "fast forward" (time acceleration) to get to the desired state behind the scenes.

Again, it's definitely possible - but not in a general fashion, it would have to be done right from the beginning, and it far easier to do with much less complex aircraft/systems, and ideally the simulator itself would provide the building blocks and infrastructure for the corresponding "situations" (aircraft configurations) and means to transition between these states - which is to say doing event handling, because under the hood, aircraft developers would still have to implement everything obviously.

frankly, it is a freaking mess to code this up for any non-trivial aircraft (i.e. anything more complex than the ogeL, ufo or c172p) - supporting this properly needs a fair bit of infrastructure which is currently misssing, or you're literally coding up all the missing infrastructure in a highly use-case specific fashion

Mathematically, any aircraft is a set of coupled integral/differential equations.

What you perceive as 'aircraft on the ground' or 'aircraft in flight' is a near-equilibrium steady state solution of these equations (there's nothing trivial about the aircraft standing on the ground - this happens only if the equations of the gear spring potential and tire friction let it settle into this state).

What you perceive as 'control' of this aircraft is a perturbation of the steady-state which makes it settle into a new equilibrium.

There's a host of other solutions which are wildly oscillating, diverging to infinity and doing other nasty things - and we don't want to run into these.

Whenever you try to init an aircraft, it has to be done in such a way that it converges into equilibrium reasonably fast. What that means depends on the current environment settings - you may have to go as far as provide a fake history invented for the current environment to make it work.

Even leaving any infrastructure questions aside, even on the most abstract algorithmical level there is nothing simple about this.

Yes - which is why I criticized the idea brought forward, explaining my reasoning for doing so, whereas you blame me personally for something (I don't really know what - supposedly blaming someone which, well, doesn't really emerge from the quotes - after all, no one has volunteered, that's the simple observation of a fact, not criticism or blame)

Thorsten - I think you're being overly pessimistic here, and far too negative. After all, you've coded up ways to set up the space shuttle at various stages, including IIRC the ability to save off the current command state.

wlbragg - I had forgotten about the various states that could be set. From memory I think James was thinking that these could be used for in-air starts and having well-defined names for common scenarios. Might be worth talking to him about his thoughts on this, as it seems slightly wrong to have to indicate the required state being set from a command-line option.

swampthing - That's not that great an option if you want to practise multiple instrument approaches, particularly when you're learning.

I guess it got set aside for the time being.Yes, to have to include a command line argument to activate it doesn't seem like it would be the way to go.I think the idea was to eventually have some predefined state identities that would be selectable from the GUI (Approach, Parked, Taxi, Circuit, etc). Maybe even be able to have the GUI pick up developer supplied custom states. That is how I would do it.

Thorsten - I think you're being overly pessimistic here, and far too negative. After all, you've coded up ways to set up the space shuttle at various stages, including IIRC the ability to save off the current command state.

First of all, mission stages and save/load for the Shuttle is a ton of extra code - including init flags which activate special alternative channels inside the JSBSim systems and special Nasal logic that switches on current guidance targets. There's nothing trivial about this, and worse, nothing that would readily generalize to other aircraft.

Second, much of the init actually involves initializing the FDM in space - which is a fairly easy task, since you have zero perturbations, you you know what the PID controllers must do up-front. Initializing in the upper atmosphere is considerably harder even in the absence of winds, initializing in the lower atmosphere is a mess which requires extra init support in the PID controllers of the FCS (again alternative channels).

I've spent a total of more than 30 hours creating these functions for the Shuttle - even if you assume that other aircraft take 1/10 of the effort, it still doesn't scale will to all aircraft on FGAddon.

In fact, the reason I am negative is because I have done it and know the work that's involved pretty well.