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
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
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 bu
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 thi
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, SeaLevelRadi
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
> 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 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 proble
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
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
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 memo
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 initia
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 N
13 matches
Mail list logo
