Hi,
In Ubuntu 8.04 LTS, just did a git pull (SG/FG/DATA), and make,
etc, and on running the default a/c, as someone else also reported,
get the console output :-
creating 3D noise texture... DONE
Trim Results:
Altitude AGL:4.4 wdot: 1.54e-03 Tolerance: 1e-03 Failed
Am 25.01.2011 12:59, schrieb Geoff McLane:
[... JSBSim trim failure report]
Is this a problem? Certainly do not like seeing 'Failed',
but it seems fg runs ok, and the aircraft seems to fly ;=))
so maybe not a problem...
It is probably not a problem, except for adding complexity when hunting
On Sun, Jan 23, 2011 at 9:13 PM, Andreas Gaeb wrote:
ok, I found the cause for this one. FGPropagate's members
LocalTerrainRadius, SeaLevelRadius and VehicleRadius are not initialized
in the constructor but only later in InitModel(). FGInitialCondition
Andreas, thanks a lot for debugging this!
On 23 Jan 2011, at 20:13, Andreas Gaeb wrote:
With both patches applied, I can't seem to produce any more NaNs by
resetting, though one never knows for sure...
Looks good here, both are merged to next, and to the 2.2.0 release branch.
Obviously everyone should keep an eye out for similar
Am 23.01.2011 01:33, schrieb ThorstenB:
[...]
Uh, ugly! Why (and where?) are these members only initialized when the first
instance is created? Or are they never initialized and it's just because
memory often happens to be 0 when the first instance is created?
IIRC, gcc has a default
On Sun, Jan 23, 2011 at 12:51 PM, Andreas Gaeb wrote:
IIRC, gcc has a default initialization routine that sets new variables
to zero unless they are explicitly initialized like
int a=1;
Yes, but that's only the case for global and static variables. The start-up
code initializes the memory
Am 23.01.2011 13:18, schrieb ThorstenB:
[...] So, member
variables should be initialized manually in the constructor.
ok, so we need to find out where this does not happen and fix it.
[...] Most compilers provide warnings for uninitialized
local variables (on the stack), but unfortunately I
On Sun, 2011-01-23 at 13:18 +0100, ThorstenB wrote:
On Sun, Jan 23, 2011 at 12:51 PM, Andreas Gaeb wrote:
IIRC, gcc has a default initialization routine that sets new
variables
to zero unless they are explicitly initialized like
int a=1;
Yes, but
On Sun, Jan 23, 2011 at 3:44 PM, Geoff McLane wrote:
And I am not so sure MSVC even zeros static variables,
unless specifically set to NULL/0, unlike as suggested
for gcc, thus say :-
static char * cp;
void func() {
if (cp == NULL)
cp = malloc(val);
can also be a problem...
No, the JSBSim object is created on the heap memory - not on
the stack. Only local variables (including local static
objects) are on the stack. Heap isn't initialized, neither
stack. So member variables have random values - unless
explicitly set. Most compilers provide warnings for
On Sun, Jan 23, 2011 at 4:57 PM, Jon S. Berndt wrote:
I'd like to find a way to reinitialize an instance of JSBSim in FlightGear
without having to destruct it and reinstantiate it. A couple of years ago I
changed the construction process and separated out a reset/reinitialization
feature to
Am 22.01.2011 22:36, schrieb Andreas Gaeb:
[...]
The second place where an FPE shows is kt_70.cxx:211 which seems to be
the first place where the value of /position/altitude-ft is read after a
reset.
ok, I found the cause for this one. FGPropagate's members
LocalTerrainRadius, SeaLevelRadius
Hello everybody,
I've been looking a bit into the NaN issues. A way to produce them on my
system is to reset JSBSim aircraft, although it happens only about every
fifth time on average, and there are at least two different places in
the code where the NaN finally surfaces, both of which are not
On Sat, Jan 22, 2011 at 10:36 PM, Andreas Gaeb wrote:
I've been looking a bit into the NaN issues. A way to produce them on my
system is to reset JSBSim aircraft, although it happens only about every
fifth time on average, and there are at least two different places in
the code where the NaN
14 matches
Mail list logo
