Hi,
On Samstag 19 Februar 2005 20:01, Jon Stockill wrote:
I've just had a thought presumably now the ground cache code has
been added it would be possible to have a carrier with a ski jump for
the harrier model? That opens up another interesting area of deck
operations.
Yes, I think it
Good morning,
(... at least in europe :)
On Samstag 19 Februar 2005 14:59, Jon Stockill wrote:
It turned out there was an ancient version of GLU hiding in /usr/local -
which hadn't caused any problems until now - eliminating that solved the
problem.
Good.
Thanks for the feedback anyway!
Vivian Meazza wrote:
Mathias would need to reply definitively, but I think so. Just by chance I
have been fiddling with a model of HMS Hermes with a ski-jump, but I was
going to remove it, and restore it to her strike carrier days. I served
aboard her in her last commission as a strike carrier.
I
Vivian Meazza wrote:
I'm not sure that the Nimitz version in cvs has cats. If it has, then don't
forget that the Seahawk has differential brakes, and no nosewheel steering.
I have a more detailed version available here:
ftp://ftp.abbeytheatre.dynu.com/fgfs/Nimitz/
Warning: it's still under
Jon Stockill
Vivian Meazza wrote:
I'm not sure that the Nimitz version in cvs has cats. If it has, then
don't
forget that the Seahawk has differential brakes, and no nosewheel
steering.
I have a more detailed version available here:
ftp://ftp.abbeytheatre.dynu.com/fgfs/Nimitz/
Vivian Meazza wrote:
Yes, make sure that this is in your ...Data/AI/nimitz-demo.xml file:
solidElevator-3-Deck/solid
solidDeck/solid
In place of whatever solid.../solid appears there now.
Ah, so I fell through the elevator then :-) That would explain the view
of the hangar deck.
--
Jon Stockill wrote:
Vivian Meazza wrote:
Yes, make sure that this is in your ...Data/AI/nimitz-demo.xml file:
solidElevator-3-Deck/solid
solidDeck/solid
In place of whatever solid.../solid appears there now.
Ah, so I fell through the elevator then :-) That would
From: Vivian Meazza
Jon Stockill wrote:
Vivian Meazza wrote:
Yes, make sure that this is in your ...Data/AI/nimitz-demo.xml
file:
solidElevator-3-Deck/solid
solidDeck/solid
In place of whatever solid.../solid appears there now.
Ah, so I fell through the
Jim Wilson wrote:
From: Vivian Meazza
Jon Stockill wrote:
Vivian Meazza wrote:
Yes, make sure that this is in your ...Data/AI/nimitz-demo.xml
file:
solidElevator-3-Deck/solid
solidDeck/solid
In place of whatever solid.../solid appears there
Mathias Fröhlich wrote:
Hi,
On Freitag 18 Februar 2005 17:30, Frederic Bouvier wrote:
Are you sure your runtime librairies ( that seems to be compiled with
gcc-2.95.3 ) match your compiler ?
That is my impression too.
It turned out there was an ancient version of GLU hiding in /usr/local -
which
Jon Stockill
Mathias Fröhlich wrote:
Hi,
On Freitag 18 Februar 2005 17:30, Frederic Bouvier wrote:
Are you sure your runtime librairies ( that seems to be compiled with
gcc-2.95.3 ) match your compiler ?
That is my impression too.
It turned out there was an ancient version of
Vivian Meazza wrote:
Let us know how you get on. Melchior claims the first successful Seafire
landing.
Took off from KSFO, and nailed the seahawk to the deck on the first try,
then couldn't work out how to get the thing onto the cat to launch. That
secondary ASI comes in rather handy :-)
--
Jon
Jon Stockill wrote:
Vivian Meazza wrote:
Let us know how you get on. Melchior claims the first successful Seafire
landing.
Took off from KSFO, and nailed the seahawk to the deck on the first try,
Well done.
then couldn't work out how to get the thing onto the cat to launch.
I'm
Vivian Meazza wrote:
Well done.
It was easier than I expected.
ftp://ftp.abbeytheatre.dynu.com/fgfs/Nimitz/
Warning: it's still under development, and some of the textures are HUGE.
I'll grab that and have a go tomorrow.
That secondary ASI comes in rather handy :-)
It was called the Deck Landing
Jon Stockill
Vivian Meazza wrote:
Well done.
It was easier than I expected.
ftp://ftp.abbeytheatre.dynu.com/fgfs/Nimitz/
Warning: it's still under development, and some of the textures are
HUGE.
I'll grab that and have a go tomorrow.
That secondary ASI comes in rather handy
Jon Stockill wrote
Vivian Meazza wrote:
Well done.
It was easier than I expected.
ftp://ftp.abbeytheatre.dynu.com/fgfs/Nimitz/
Warning: it's still under development, and some of the textures are
HUGE.
I'll grab that and have a go tomorrow.
If you take it all, you might
Jon,
I cannot reproduce this.
It just works for me with a plain cvs checkout
using that scenry tile from Scenery-0.9.8.
On Freitag 18 Februar 2005 01:24, Jon Stockill wrote:
(gdb) bt
#0 0x0ce8b760 in ?? ()
#1 0x40142974 in __dynamic_cast (from=0xce8b760,
to=0x8548f9c typeinfo for
Quoting Frederic Bouvier:
Quoting Mathias Fröhlich :
Jon,
I cannot reproduce this.
It just works for me with a plain cvs checkout
using that scenry tile from Scenery-0.9.8.
On Freitag 18 Februar 2005 01:24, Jon Stockill wrote:
(gdb) bt
#0 0x0ce8b760 in ?? ()
#1
Quoting Mathias Fröhlich :
Jon,
I cannot reproduce this.
It just works for me with a plain cvs checkout
using that scenry tile from Scenery-0.9.8.
On Freitag 18 Februar 2005 01:24, Jon Stockill wrote:
(gdb) bt
#0 0x0ce8b760 in ?? ()
#1 0x40142974 in __dynamic_cast (from=0xce8b760,
Hi,
On Freitag 18 Februar 2005 16:08, Frederic Bouvier wrote:
I don't know if it is true for gcc, but with MSVC, rtti needs to be
activated with a specific compile-time option otherwise the result is
unpredictable.
I see, this is the first usage of rtti in flightgear.
But all those
Mathias Fröhlich wrote:
Hi,
On Freitag 18 Februar 2005 16:08, Frederic Bouvier wrote:
I don't know if it is true for gcc, but with MSVC, rtti needs to be
activated with a specific compile-time option otherwise the result is
unpredictable.
I see, this is the first usage of rtti in flightgear.
But
Mathias Fröhlich wrote:
From that backtrace:
There is exactly one dynamic_cast in this function.
In theory it should never happen that the argument to that dynamic_cast is
zero.
Since I cannot reproduce it myself, can you help me?
Could you please apply the attached patch and tell me of some of
Quoting Jon Stockill :
Mathias Fröhlich wrote:
From that backtrace:
There is exactly one dynamic_cast in this function.
In theory it should never happen that the argument to that dynamic_cast is
zero.
Since I cannot reproduce it myself, can you help me?
Could you please apply the
Hi,
On Freitag 18 Februar 2005 17:30, Frederic Bouvier wrote:
Are you sure your runtime librairies ( that seems to be compiled with
gcc-2.95.3 ) match your compiler ?
That is my impression too.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Ron Lange wrote:
Hi Gerhard,
certainly I examine the variables, as mentioned the last created
thread try to access the properties, but the static property pointers
don't point to valid memory regions. The 'vel' property node is just
the first invalid, where the invalid access occured. The other
Hi Gerhard,
certainly I examine the variables, as mentioned the last created thread
try to access the properties, but the static property pointers don't
point to valid memory regions. The 'vel' property node is just the first
invalid, where the invalid access occured. The other two property
On Fri, Feb 11, 2005 at 04:14:15PM +0100, Ron Lange wrote:
double v = vel-getDoubleValue(); = segfault
Can you check vel in the debugger? Just set a breakpoint one line above
and enter ``print vel'' (in gdb).
Cheers
-Gerhard
--
Gerhard Wesp o o Tel.: +41 (0) 43
sorry, not the *commandline* below causes fg to break but similar
.fgfsrc file...
fgfs --airport=EDHI --aircraft=bo105 --enable-game-mode
#
Again, only a present .fgfsrc with similar content causes a segfault,
the commandline let
On Fri, 11 Feb 2005 16:14:15 +0100
Ron Lange wrote:
sorry, not the *commandline* below causes fg to break but similar
.fgfsrc file...
fgfs --airport=EDHI --aircraft=bo105 --enable-game-mode
#
Again, only a present
Jorge Van Hemelryck wrote:
Could you make sure that there is only one option per line in the
.fgfsrc file ? It looks like the parser is trying to set the airport
from the string EDHI --aircraft=bo105 --enable-game-mode...
Aaah, your comment reminds me that the parser is unable to parse
Hm...hmmm...since putting one flag per line in .fgfsrc wasn't satisfying
(not starting from EDHI nor with the bo-105...) I put all flags in one
row. Then everything goes as desired but the game mode...after adding
enabel-game-mode the segfault appeared.
Regards
Ron
Martin Spott schrieb:
Jorge
Just downloaded a fresh CVS FlightGear and found that the AI code is
causing segfaults now. I'll recompile and run it through gdb. In the mean
time beware that some aircraft that set up AI scenarios by default, like
the T-38 or the hunter-2tanks, are crashing the sim.
I've run it through
Just took another look and realized the trace was fine. The bug really is in
the animation code. I'll post the patch in a bit.
Best,
Jim
Jim Wilson said:
There appears to be something still broken in the AIManager::update(). I'm
rebuilding without threads to see if I can get a better
Try the airport code in all caps ... this used to be more robust to
non-matching codes, not sure what changed but we should probably look
into it.
Regards,
Curt.
Sydney Weidman writes:
Not sure if I should ask about this problem here or in the user list but
here goes:
I tried to start fg
Frederic Bouvier wrote:
Please ignore my previous patch. It only produce white splash. Instead,
please apply the one below. The memory is deleted in the destructor.
Well, that way the texture data is kept in memory at three different places:
1. Main memory (because of your patch)
2. Main memory
Erik Hofman wrote :
Frederic Bouvier wrote:
Please ignore my previous patch. It only produce white splash. Instead,
please apply the one below. The memory is deleted in the destructor.
Well, that way the texture data is kept in memory at three different places:
1. Main memory
Frederic BOUVIER wrote:
Erik Hofman wrote :
Frederic Bouvier wrote:
Please ignore my previous patch. It only produce white splash. Instead,
please apply the one below. The memory is deleted in the destructor.
Well, that way the texture data is kept in memory at three different
I wrote :
Erik Hofman wrote:
Curtis L. Olson wrote:
I'm getting a seg fault on exit these days somewhere in ~SGTexture. I
haven't investigated further than that ... anyone have any ideas?
I am not seeing this.
Could it be the result of a stale object file?
I am seeing the same
Dave Perry writes:
PS The dc3 is still broken. When I try to start the 2nd engine, the
mag switch moves, but nothing else happens.
You need to advance the magneto as well, probably.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
David Megginson writes:
Dave Perry writes:
PS The dc3 is still broken. When I try to start the 2nd engine, the
mag switch moves, but nothing else happens.
You need to advance the magneto as well, probably.
David, give it a try ... actually my guess is that due to the gear
problem,
Curtis L. Olson writes:
David, give it a try ... actually my guess is that due to the gear
problem, it probably crashes instantly so nothing will work at all
with it. And of course, in air starts don't work for YAsim models,
so... :-) Andy, I'd be happy if we were forced to specify
The ovState crash seems like it might have been a transient bug in
plib for a while and was fixed I'm running with plib-1.6.0 here,
but if you are running cvs version, you might consider doing a cvs
update and reinstalling (and make sure you don't have a packaged
version installed someplace
William Earnest wrote:
Dave Perry wrote:
Again, an old copy of the the base with bin/fgfs (compiled early in
December) runs fine.
Regards,
Dave
I've sent a patch to Curtis which fixes a possible core dump when
/sim/systems/electrical/path has not been defined in the
aircraft-set.xml file.
Dave Perry writes;
Bill Earnest wrote:
Norman Vine wrote:
/ Dave Perry
//
//Here is the last few lines before the segmentation fault.
//
//Loading tile /usr/local/FlightGear/Scenery/w010n00/w001n00/2938503 //
// Did you update the fgBase files from CVS too ?
I renamed the base package
Dave Perry wrote:
Erik wrote:
I've sent a patch to Curtis which fixes a possible core dump when
/sim/systems/electrical/path has not been defined in the
aircraft-set.xml file.
Which aircraft are you trying to load when this happens?
Erik,
I have tried a number of different aircraft
Dave Perry writes
Here is the gdb text after the model is complete to the segfault:
leave NewTgtAirportInit()start of fgInitProps()
end of fgInitProps()
[New Thread 8192 (LWP 1557)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 1557)]
Dave Perry writes:
Norman Vine wrote:
please enter 'backtrace full' in the gdb window immediately after
gdb reports the Segmentation fault and post the results
Dave Perry writes:
Here is the bactrace.
Tile not found (Ok if initializing)
scheduling needed tiles for -122.358
Dave Perry wrote:
Bill Earnest wrote:
Norman Vine wrote:
/ Dave Perry
// // //Here is the last few lines before the segmentation fault.
//
//
//Panel visible = 0
//Playing audio after 0 sec: rumble
//Playing audio after 0 sec: squeal
//Tile not found (Ok if initializing)
//scheduling needed
Dave Perry wrote:
Here is the last few lines before the segmentation fault.
Panel visible = 0
Playing audio after 0 sec: rumble
Playing audio after 0 sec: squeal
Tile not found (Ok if initializing)
scheduling needed tiles for -122.358 37.6117
load() base = /usr/local/FlightGear/Scenery
Loading
Dave Perry
Here is the last few lines before the segmentation fault.
Panel visible = 0
Playing audio after 0 sec: rumble
Playing audio after 0 sec: squeal
Tile not found (Ok if initializing)
scheduling needed tiles for -122.358 37.6117
load() base = /usr/local/FlightGear/Scenery
Norman Vine wrote:
Dave Perry
Here is the last few lines before the segmentation fault.
Panel visible = 0
Playing audio after 0 sec: rumble
Playing audio after 0 sec: squeal
Tile not found (Ok if initializing)
scheduling needed tiles for -122.358 37.6117
load() base =
William Earnest writes:
Norman Vine wrote:
Dave Perry
Here is the last few lines before the segmentation fault.
load() base = /usr/local/FlightGear/Scenery
Loading tile /usr/local/FlightGear/Scenery/w010n00/w001n00/2938503
Segmentation fault
FWIW, the directory
Michael Selig writes:
I am trying to compile and run the latest version of fgfs, but I have
hit a problem. When I run it I promptly get the error message
Segmentation Fault
There are no other messages.
(gdb) run
Starting program:
From: Michael Selig [EMAIL PROTECTED]
At 10/23/02, Curtis Olson wrote:
I'm not coming up with any good ideas ... I *thought* that if you
didn't specify --enable-clouds3d, then none of that code was executed,
but perhaps that's not the case ... (?)
From gdb, it's dying in the 3d cloud
Michael Selig writes:
At 10/23/02, Curtis Olson wrote:
I'm not coming up with any good ideas ... I *thought* that if you
didn't specify --enable-clouds3d, then none of that code was executed,
but perhaps that's not the case ... (?)
From gdb, it's dying in the 3d cloud setup/init but beyond
On Wed, 2002-10-23 at 17:39, Michael Selig wrote:
I am trying to compile and run the latest version of fgfs, but I have
hit a problem. When I run it I promptly get the error message
Segmentation Fault
There are no other messages.
What I have:
- Redhat 7.1
- automake 1.6.3
- autoconf
At 10/23/02, Tony Peden wrote:
On Wed, 2002-10-23 at 17:39, Michael Selig wrote:
I am trying to compile and run the latest version of fgfs, but I have
hit a problem. When I run it I promptly get the error message
Segmentation Fault
There are no other messages.
What I have:
- Redhat 7.1
On Wed, 2002-10-23 at 19:14, Michael Selig wrote:
At 10/23/02, Tony Peden wrote:
On Wed, 2002-10-23 at 17:39, Michael Selig wrote:
I am trying to compile and run the latest version of fgfs, but I have
hit a problem. When I run it I promptly get the error message
Segmentation Fault
At 10/23/02, Tony Peden wrote:
On Wed, 2002-10-23 at 19:14, Michael Selig wrote:
At 10/23/02, Tony Peden wrote:
On Wed, 2002-10-23 at 17:39, Michael Selig wrote:
I am trying to compile and run the latest version of fgfs, but I have
hit a problem. When I run it I promptly get the error
Michael Selig writes:
I am still getting the same segfault w/ this option.
It even promptly crashes w/
./fgfs --help
i.e. I don't get the option list.
Are you missing the base package some how, or pointing to the wrong
directory?
Curt.
--
Curtis Olson IVLab / HumanFIRST Program
I just ran through firing up all the non 172 planes
and there are several JSBsim planes that segfault
x24b
X15
Shuttle
On Wednesday 23 October 2002 10:30 pm, Tony Peden wrote:
On Wed, 2002-10-23 at 19:14, Michael Selig wrote:
At 10/23/02, Tony Peden wrote:
On Wed, 2002-10-23 at 17:39,
At 10/23/02, Curtis Olson wrote:
Michael Selig writes:
I am still getting the same segfault w/ this option.
It even promptly crashes w/
./fgfs --help
i.e. I don't get the option list.
Are you missing the base package some how, or pointing to the wrong
directory?
If I run my working old
At 10/23/02, John Check wrote:
I just ran through firing up all the non 172 planes
and there are several JSBsim planes that segfault
x24b
X15
Shuttle
I have been down this road before. These planes are crashing for some
reason, and the segfault is not the first thing that happens.
This
.
Is anyone else seeing this?
Jon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:flightgear-devel-admin;flightgear.org]On Behalf Of John Check
Sent: Wednesday, October 23, 2002 10:36 PM
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] segfault
I just ran through firing up all
PROTECTED]
Subject: Re: [Flightgear-devel] segfault
At 10/23/02, John Check wrote:
I just ran through firing up all the non 172 planes
and there are several JSBsim planes that segfault
x24b
X15
Shuttle
I have been down this road before. These planes are crashing for some
reason
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] segfault
At 10/23/02, John Check wrote:
I just ran through firing up all the non 172 planes
and there are several JSBsim planes that segfault
x24b
X15
Shuttle
I have been down this road before. These planes are crashing for some
I seem to recall having problems with crashes when starting up with the telnet
interface. Well, the problem really was with subsequent attempts at starting.
I'd see segfaults if the first run didn't exit normal, either through a crash
or other means. At the time I had the line for the telnet
And it only happens with *some* *JSBSim* aircraft?
Jon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:flightgear-devel-admin;flightgear.org]On Behalf Of Curtis L.
Olson
Sent: Wednesday, October 23, 2002 11:13 PM
To: [EMAIL PROTECTED]
Subject: RE: [Flightgear-devel] segfault
On Thursday 24 October 2002 12:18 am, Jon Berndt wrote:
And it only happens with *some* *JSBSim* aircraft?
Jon
Heres console output from X15
Starting and initialitoken = OBJECT name = KHAF.btg
zing JSBsim
T,p,rho: 518.67, 2116Start common FDM init
...initializing position...
: [Flightgear-devel] segfault
At 10/23/02, John Check wrote:
I just ran through firing up all the non 172 planes
and there are several JSBsim planes that segfault
x24b
X15
Shuttle
I have been down this road before. These planes are crashing for some
reason, and the segfault
Alex,
Make sure you have the latest base package ... I think some default
properties changed. I don't think this should lead to a segfault, but
apparently it does ...
Curt.
Alex Perry writes:
...
Cannot open file: /usr/local/lib/FlightGear/Scenery/Objects.txt
Initializing splash screen
Yep, that apparently fixed it.
Curt said:
Make sure you have the latest base package ... I think some default
properties changed. I don't think this should lead to a segfault, but
apparently it does ...
Alex Perry writes:
...
Cannot open file:
Curt,
The new default properties set up the various views. So the problem is if
running the new code, and none is defined there would be no view to access.
I'm going to submit some patches that consolidate some of the matrix math for
models and views, which included some patches to the view
Jim Wilson writes:
Here's a backtrace on this.
I've just checked in some minor fixes to props.cxx in SimGear, and
swapping panels (with 's') in FlightGear is working again. Thanks.
By the way, we need to get rid of the panel_2 property; instead, we
should have panel[0], panel[1], panel[2],
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Here's a backtrace on this.
I've just checked in some minor fixes to props.cxx in SimGear, and
swapping panels (with 's') in FlightGear is working again. Thanks.
By the way, we need to get rid of the panel_2 property;
When I try to switch to a mini-panel, I always get a segfault (I've
tested in c172 and c310). Is anyone else seeing this? I'm using a
clean CVS build from yesterday (ie. prior to David's property code
changes) with no command-line options. Thanks
It was working for me a couple of days
Here's a backtrace on this.
Best,
Jim
#0 0x82ddfba in SGPropertyNode::clear_value (this=0x9747f90) at props.cxx:464
464 delete _value.string_val;
#1 0x82de8e0 in SGPropertyNode::~SGPropertyNode (this=0x9747f90, __in_chrg=3)
at props.cxx:672
#2 0x806c0e0 in
Cameron Moore writes:
When I try to switch to a mini-panel, I always get a segfault (I've
tested in c172 and c310). Is anyone else seeing this? I'm using a
clean CVS build from yesterday (ie. prior to David's property code
changes) with no command-line options.
Yep :-(
I started getting
78 matches
Mail list logo
