From David Megginson:

From David Megginson:

The files in the attached tarball make the following changes to
FlightGear:

- rename the existing FGInterface::init() method to
FGInterface::_setup to get it out of the way

- move *all* FDM initialization code out of src/Main/fg_init.cxx and
into FGInterface::init(), and clean up fg_init.cxx a little
(especially by removing the zillions of attempts to place the plane on
the ground at various locations in the code)

- modify FGInterface::bind() so that no values are picked up
automatically at bind time (they are set previously by init() instead)

- modify the init() methods of the classes derived from FGInterface
(i.e. larcsim, jsbsim, balloon, magic, and ada) to invoke
FGInterface::init() explicitly before doing their own setup

I don't claim that the code in FGInterface::init() is optimal (or even
correct), but it seems to work for on-ground starts with both LaRCSim
and JSBSim on runways pointing various directions from near sea level
to about 700' ASL (the range I happened to test).  I expect that Jon
and Tony will want to look at the code and refactor and correct it now
that they can see what's going on in one place.

Here's a quick outline of what is invoked:

  cur_fdm_state = new <whatever>(dt);
  cur_fdm_state->init();
  cur_fdm_state->bind();

The constructor allocates memory and sets default values only (with
the help of the FGInterface::_setup() method).  The init() method pull
any required properties out of the property tree and sets up the
initial state of the FDM.  The bind() method takes ownership of
FDM-related properties so that the FDM can publish them to the rest of
the sim.

Note that bind() and init() are virtual, so any implementation in a
subclass will hide the implementation in FGInterface; that's why
subclass implementations of init() and bind() have to invoke
FGInterface::init() and FGInterface::bind() explicitly, probably at
the start, so that they get the basic initialization.