Andy Ross wrote

> Vivian Meazza wrote:
> > I would deduce that the property:
> > Controls/engines/engine/boost-control
> > Does not exist when the solver runs.
> It should still see a zero for undefined properties, 

What does it do for defined properties that contain null/nil? 

> although you can
> make arbitrary property settings in the approach/cruise definitions up
> at the top.  Some of the aircraft

> Note again, though, that you appear to have a case bug.  The property
> tree name is "controls", not "Controls".

There is no case error, sorry to have mislead you here.
> I would back out your changes to the last version that works and
> re-add them one at a time.  The change to the property input for the
> throttle control will not cause a change in solution results.
> Something else must have been modified.

No - nothing else has been modified. I've gone back to the cvs-head version
of source and data. This is the _only_ change in the code anywhere:

<!--    <control-input axis="/controls/engines/engine[0]/throttle"
axis="/controls/engines/engine[0]/boost-control" control="THROTTLE"/>

this is the solver output in fgfs:

YASim solution results:
       Iterations: 1
 Drag Coefficient: 1000
       Lift Ratio: 1
       Cruise AoA: 0
   Tail Incidence: -0
Approach Elevator: 0
            CG: -3.412, 0.000, -0.201

Same thing using yasim.exe. You can check for yourself very quickly and

My hypothesis remains that the value of 


is null/nil at solve time. Since this property hasn't been initialized with
this as the only change this ought to be the case??? If I do initialize the
property using nasal, then the outcome is the same, therefore I deduce that
the property remains null/nil despite apparent initialization until after
solve-time. I have had to add this to some nasal to work around this

if (mp == nil){mp = 0};

But not in this test - the only change to cvs-head is as above.


Flightgear-devel mailing list

Reply via email to