* Curtis L. Olson -- Saturday 19 January 2002 23:35:
Melchior FRANZ writes:
Perhaps it could be tied, but not directly, the far clip plan has to
at least include the sky dome, sun, moon, stars, planets, clouds,
etc. even when the visibility is rather low.
OK, yes. I meant that the far clip
Norman Vine wrote:
just a teaser image for now
http://www.vso.cape.com/~nhv
FWIW - good data is hard to get
Cool stuff. I've been thinking to use this data (except for submarine
simulation) for coastlines in FlightGear (different textures for
waterhights of less than (lets say) 60 feet.
Curtis L. Olson wrote:
Christian Mayer writes:
Hi,
is there a reason why SimGear/misc/zfstram.hxx was changed from
#ifdef HAVE_ZLIB
# include zlib.h
#else
# include simgear/zlib/zlib.h
#endif
to
#include zlib.h
It was a slight phylisophical shift. Although zlib
Christian Mayer wrote:
Anyway, could all
#include zlib.h
lines be changed back to
#ifdef HAVE_ZLIB
# include zlib.h
#else
# include simgear/zlib/zlib.h
#endif
w/o causing any trouble? This would help me. I wouldn't need any other
change as the directories are still
Erik Hofman wrote:
Christian Mayer wrote:
Anyway, could all
#include zlib.h
lines be changed back to
#ifdef HAVE_ZLIB
# include zlib.h
#else
# include simgear/zlib/zlib.h
#endif
w/o causing any trouble? This would help me. I wouldn't need any other
Hi,
The latest FlightGear from CVS gives me a core after startup.
I traced it back to SimGear/simgear/misc/props.hxx line 730:
Process 14190 (fgfs) stopped on signal SIGSEGV: Segmentation violation
(default) at [SGPropertyNode::getAttribute(SGPropertyNode::Attribute)
const:730
Still happening just the same. Is it my fault?
- Julian
John Check wrote:
On Wednesday 16 January 2002 04:28 pm, you wrote:
Does this indicate a problem on the base package CVS server?
...
cvs server: Diffing Aircraft/X15/Panels
cvs server: Diffing Aircraft/X15/Panels/Textures
This has been discussed before and I don't recall any reason why these auto-generated
files should be in CVS. If this is the case please could someone remove them.
SimGear:
aclocal.m4
simgear/simgear_config.h.in
FlightGear:
aclocal.m4
src/Include/config.h.in
- Julian
Until this is fixed properly, you can fix this by adding the line:
AC_PREREQ(2.13)
at the beginning of configure.in, just after the dnl ... lines which are comments.
At least, this works for me.
- Julian
Michael Basler wrote:
Hi,
when I tried to build CVS Simgear today, I got with
On Sunday 20 January 2002 10:40 am, you wrote:
Still happening just the same. Is it my fault?
- Julian
Maybe I just did an anonymous checkout and it seems to be working.
What are you doing exactly, a checkout or an update? Hmm...
just did cvs up -dP and no problems. Try deleting your
Julian Foad writes:
Until this is fixed properly, you can fix this by adding the line:
AC_PREREQ(2.13)
at the beginning of configure.in, just after the dnl ...
lines which are comments. At least, this works for me.
Just running make again seems to work also
Don't ask me why
Norman
Julian Foad wrote:
Erik Hofman wrote:
The latest FlightGear from CVS gives me a core after startup.
I traced it back to SimGear/simgear/misc/props.hxx line 730:
Process 14190 (fgfs) stopped on signal SIGSEGV: Segmentation violation
(default) at
-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im Auftrag von Julian Foad
Until this is fixed properly, you can fix this by adding the line:
AC_PREREQ(2.13)
at the beginning of configure.in, just after the dnl ... lines
which are comments. At least,
Thanks, John - that fixes it. I suppose CVS didn't delete it because I had made
modifications in it. I'd expect it to say so, though!
- Julian
John Check wrote:
just did cvs up -dP and no problems. Try deleting your c172/Instruments
directory, it's no longer relevant.
TTYL
J
On
I asked for --tile-radius, because I don't get enough tiles if I
fly at good visibility (--fog-disable or hitting 'Z' a few times).
only schedules tiles for loading when you cross a tile boundary
Is this out of line ... using --fdm=magic ... rise to say 15,000 feet,
clear fog and clouds, no
Now I've got another problem with it. I don't seem to need the AC_PREREQ(2.13) any
more (it doesn't make any difference to the following output), but I get CXX = and
CC = followed by failure further down. Although it says checking whether make sets
${MAKE}... (cached) yes, there is no
I committed a fix to the FGInitialCondition problem this morning.
If the MSVC folks could give it a shot without your fixes (either
from JSBSim CVS or wait for FG CVS to be updated) I'd really appreciate
it.
The problem did exist on linux, as well, but somehow never surfaced.
It was only after
On Sat, 2002-01-19 at 07:20, Tony Peden wrote:
I've been trying to reproduce the reported problem in FGInitialCondition
and would like to have floating point exceptions enabled to do that.
The trouble is that I can't seem to get it to work like I expect.
On linux, if I either the method in
By false you mean they are null, I assume. Well, latitude and longitude are
created a few lines further up by:
// Any time after globals is created we are ready to use the
// property system
static const SGPropertyNode *longitude
= fgGetNode(/position/longitude-deg, true);
Michael Basler writes:
Julian Foad write:
Until this is fixed properly, you can fix this by adding the line:
AC_PREREQ(2.13)
at the beginning of configure.in, just after the dnl ... lines
which are comments. At least, this works for me.
One million thanks, Julian, this fixed the case for
Tony Peden writes:
Well, I've spent quite a few hours on this and AFAICT, the FPU
is being set up correctly, it's just not generating the exception
for a floating point divide by zero (or any other floating point error
I could induce). Integer divide by zero works just fine.
Tony
Try adding
On Sun, 2002-01-20 at 10:47, Norman Vine wrote:
Tony Peden writes:
Well, I've spent quite a few hours on this and AFAICT, the FPU
is being set up correctly, it's just not generating the exception
for a floating point divide by zero (or any other floating point error
I could induce).
Norman Vine wrote:
Michael Basler writes:
Julian Foad write:
Until this is fixed properly, you can fix this by adding the line:
AC_PREREQ(2.13)
at the beginning of configure.in, just after the dnl ... lines
which are comments. At least, this works for me.
One million thanks,
OK: a CygWin update followed by mv acsite.m4 aclocal.m4 fixed it for me. Details
below.
Norman Vine wrote:
Julian Foad writes:
Now I've got another problem with it. I don't seem to need
the AC_PREREQ(2.13) any more (it doesn't make any difference
to the following output), but I get
Blimey! What a wierd combination of effects. On Windows ME its nearly the same: just
start .\notepad is different.
C:\ver
Windows Millennium [Version 4.90.3000]
C:\start /m notepad
-- notepad started minimized
C:\start .\notepad
Cannot find file '.\notepad' (or one of its components).
Maybe someone would like me to submit a patch for this?
--
Ross
On Tue, 2002-01-01 at 19:12, Ross Golder wrote:
Sorry for dragging this old problem up again, but it hasn't really been
solved. I know from experience that I should run 'aclocal -I .' when I
get this problem, but this isn't
26 matches
Mail list logo
