Re: [Flightgear-devel] Crash carnage

2005-10-02 Thread Eric Sorton
On 9/24/05, Curtis L. Olson [EMAIL PROTECTED] wrote: One thing we'd like to do that wouldn't be too technically difficult would be to get a 2nd receiver on the same channel as the aircraft but keep it on the ground. Pipe the servo outputs from the ground based receiver into a little PIC board

Re: [Flightgear-devel] Crash carnage

2005-10-02 Thread Curtis L. Olson
Eric Sorton wrote: Hi Curt, FMA Direct FS8 Receiver has serial output which can be used with their Windows software to view the current position of the control outputs. If they provide the protocol (or if it can be reverse engineered), you could simply read the output of the receiver

Re: [Flightgear-devel] Crash carnage

2005-09-25 Thread Curtis L. Olson
Arnt Karlsen wrote: ..ahem, the big guys use opening shock damper rings to keep chute loads safe throughout the speed range, these rings use the chute opening loads to slow the chute opening. ;o) Except that I heard a story recently about a guy that got himself into a bad high speed

Re: [Flightgear-devel] Crash carnage

2005-09-25 Thread jj
, 2005 12:12 PM Subject: Re: [Flightgear-devel] Crash carnage Arnt Karlsen wrote: ..ahem, the big guys use opening shock damper rings to keep chute loads safe throughout the speed range, these rings use the chute opening loads to slow the chute opening. ;o) Except that I heard a story

Re: [Flightgear-devel] Crash carnage

2005-09-25 Thread Arnt Karlsen
On Sun, 25 Sep 2005 14:12:13 -0500, Curtis wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..ahem, the big guys use opening shock damper rings to keep chute loads safe throughout the speed range, these rings use the chute opening loads to slow the chute opening. ;o)

[Flightgear-devel] Crash carnage

2005-09-24 Thread Curtis L. Olson
This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out with. We have a backup plane and our expensive

Re: [Flightgear-devel] Crash carnage

2005-09-24 Thread Lee Elliott
On Saturday 24 Sep 2005 16:28, Curtis L. Olson wrote: This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out

Re: [Flightgear-devel] Crash carnage

2005-09-24 Thread Dave Martin
On Saturday 24 September 2005 16:28, Curtis L. Olson wrote: This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping

Re: [Flightgear-devel] Crash carnage

2005-09-24 Thread Dave Martin
On Saturday 24 September 2005 20:07, Curtis L. Olson wrote: It's definitely an interesting thought. Anyone know what size parachute a person would need to gentle let down about 15 lbs (7kg)? Many R/C receivers have a failsafe mode so you can trigger the servos to go to preset locations in

Re: [Flightgear-devel] Crash carnage

2005-09-24 Thread Dave Martin
On Saturday 24 September 2005 16:28, Curtis L. Olson wrote: This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping

Re: [Flightgear-devel] Crash carnage

2005-09-24 Thread Curtis L. Olson
Dave Martin wrote: Just done some more reading of your page and incident analysis; I was just thinking that a useful tool would be a couple of camcorders. (and a friend to operate one of them). If you set one up on a tripod looking at the transmitter, you could at least see what control

[Fwd: Re: [Flightgear-devel] crash handling options for JSBSim in FlightGear

2005-06-11 Thread Gerard Robin
Le samedi 11 juin 2005 22:07 +, Martin Spott a crit : Gerard Robin wrote: Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, http://baron.flightgear.org/pipermail/flightgear-cvslogs/ Look at the recent changes made by Erik,

Re: [Flightgear-devel] crash handling options for JSBSim in FlightGear

2005-06-10 Thread Erik Hofman
Dave Culp wrote: Just checked in a JSBSim.hxx and JSBSim.cxx to JSBSim CVS that makes crash handling user-configurable. The default behavior is the current subterranean flying behavior. If the user sets the property /sim/pause-on-crash to true, then the sim will pause on crash, which is the

Re: [Flightgear-devel] crash handling options for JSBSim in FlightGear

2005-06-10 Thread Gerard ROBIN
Le jeudi 09 juin 2005 20:52 -0500, Dave Culp a crit : As for the /fdm/jsbsim property cloning problem, this has been around for some time now. Any reset of FlightGear while using a JSBSim aircraft will cause another /fdm/jsbsim node to be created. I've tried stopping that but have had

Re: [Flightgear-devel] crash handling options for JSBSim in FlightGear

2005-06-10 Thread Gerard ROBIN
Le vendredi 10 juin 2005 12:33 +0200, Gerard ROBIN a crit : Le jeudi 09 juin 2005 20:52 -0500, Dave Culp a crit : As for the /fdm/jsbsim property cloning problem, this has been around for some time now. Any reset of FlightGear while using a JSBSim aircraft will cause another

Re: [Flightgear-devel] crash handling options for JSBSim in FlightGear

2005-06-10 Thread Andy Ross
Erik Hofman wrote: Dave Culp wrote: If the user sets the property /sim/pause-on-crash to true, then the sim will pause on crash, which is the same behavior Yasim has, so this should be the default for FlightGear. If the user sets the property /sim/reset-on-crash to true, then the sim

[Flightgear-devel] crash handling options for JSBSim in FlightGear]

2005-06-10 Thread Gerard Robin
Message transfr De: Gerard Robin [EMAIL PROTECTED] : [EMAIL PROTECTED] Objet: Re: [Jsbsim-devel] crash handling options for JSBSim in FlightGear Date: Fri, 10 Jun 2005 23:13:21 +0200 Le vendredi 10 juin 2005 14:59 -0500, Dave Culp a crit : It seems like I misunderstood

Re: [Flightgear-devel] crash handling options for JSBSim in FlightGear]

2005-06-10 Thread Gerard Robin
Nobody wants subterranean flying. This will make the crash handling much cleaner. We can make pause the default behavior and reset the optional behavior, based on a property reset-on-crash. Everyone agreed on this? Dave In that case the float are contact

[Flightgear-devel] crash handling options for JSBSim in FlightGear

2005-06-09 Thread Dave Culp
Just checked in a JSBSim.hxx and JSBSim.cxx to JSBSim CVS that makes crash handling user-configurable. The default behavior is the current subterranean flying behavior. If the user sets the property /sim/pause-on-crash to true, then the sim will pause on crash, which is the same behavior

[Flightgear-devel] Crash detection (was FDM freeze)

2005-05-26 Thread Dave Culp
We should probably come up with some kind of standard way for the FDM to signal to the rest of the simulator that it has detected a collision and stopped. I agree it's time for crash detection and handling. I just added a basic version to my OV-10 sim (can't have public users wallowing

Re: [Flightgear-devel] Crash detection (was FDM freeze)

2005-05-26 Thread Andy Ross
Dave Culp wrote: One decision to make is what the handler should do once a crash is detected. I have it calling the reinit code in order to reset the sim to the starting position (below), while others may prefer to have the sim close after a crash, or perhaps display a crash-splash screen

Re: [Flightgear-devel] Crash detection (was FDM freeze)

2005-05-26 Thread Dave Culp
If you want to do push-mode handling with an FGCommand and make it settable by the user, you can have the command call (or be) a Nasal script that can be assigned by the user (e.g. globals.crashHandler = myFunction). Or have it indirect through another FGCommand binding found in the property

[Flightgear-devel] crash with (mistakenly) both --vor and --ndb given

2004-07-09 Thread Vassilii Khachaturov
I mistakenly specified both --vor and --ndb (I meant to say --adf instead of --ndb), and got a segfault on the startup, even before the splash screen. fgfs --prop:/environment/params/real-world-weather-fetch=true \ --prop:/environment/params/control-fdm-atmosphere=true \

Re: [Flightgear-devel] crash in FGAIPlane::Update(double)

2004-03-04 Thread David Luff
This should now be fixed. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] crash in FGAIPlane::Update(double)

2004-03-03 Thread Alex Romosan
i haven't been able to use flightgear for the past couple of days as it crashes in FGAIPlane::Update(double) (actually it doesn't quite crash, the sim just freezes and i have to kill it from the command prompt). this is the gdb backtrace: 0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98,

Re: [Flightgear-devel] crash on very first start of 0.9.2

2003-06-15 Thread Martin Spott
Martin Koller [EMAIL PROTECTED] wrote: I just downloaded version 0.9.2 and compiled and installed everything on my Linux Suse 8.0. On the first start I get a Segmentation fault, and looking in gdb I see: I attached a 'Build' script that I use for my daily build from CVS. Although it is

Re: [Flightgear-devel] crash on very first start of 0.9.2

2003-06-15 Thread Martin Spott
As usual, I forgot the attachment #!/bin/sh # # Please set ${FG_ROOT} appropriately. You will need a 'FlightGear/' directory # set to ${FG_ROOT} and a 'src/' directory one level up. # FG_ROOT_SRC=${FG_ROOT}/../src # DO_LNDIR=true # NUMPROCS=`grep ^processor /proc/cpuinfo | wc -l` if [ -z

[Flightgear-devel] crash on very first start of 0.9.2

2003-06-11 Thread Martin Koller
Hi all, I just downloaded version 0.9.2 and compiled and installed everything on my Linux Suse 8.0. On the first start I get a Segmentation fault, and looking in gdb I see: Is it normal that the total variable is ZERO ? Initializing scenery subsystem Program received signal SIGSEGV,

[Flightgear-devel] crash

2002-07-18 Thread Alex Romosan
i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a 1600x1200 picture so it might be pretty large). so either the crash code is wrong, or the

re: [Flightgear-devel] crash

2002-07-18 Thread David Megginson
Alex Romosan writes: i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a 1600x1200 picture so it might be pretty large). so either the

Re: [Flightgear-devel] crash

2002-07-18 Thread John Check
On Thursday 18 July 2002 7:43 pm, David Megginson wrote: Alex Romosan writes: i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a

RE: [Flightgear-devel] crash

2002-07-18 Thread Norman Vine
Curtis L. Olson writes: David Megginson writes: Alex Romosan writes: i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a

RE: [Flightgear-devel] Crash on Reset function.

2002-06-06 Thread David Megginson
Norman Vine writes: Hopefully once we get 'reset' working again developers will test 'reset' before submitting their changes in the future so we don't repeat this quagmire It's a little more complicated than that. The original reset was a simple kludge that worked fine for a simple

RE: [Flightgear-devel] Crash on Reset function.

2002-06-06 Thread Norman Vine
David Megginson writes: Norman Vine writes: Hopefully once we get 'reset' working again developers will test 'reset' before submitting their changes in the future so we don't repeat this quagmire It's a little more complicated than that. The original reset was a simple kludge that

RE: [Flightgear-devel] Crash on Reset function.

2002-06-06 Thread Jim Wilson
David Megginson [EMAIL PROTECTED] said: Curt has mentioned that there are ordering dependencies, especially around rendering, that we have to be careful not to break. We should be able to get those automatically, as long as we add the subsystems to the vector in the right order. The

Re: [Flightgear-devel] Crash on Reset function.

2002-06-05 Thread David Megginson
Curtis L. Olson writes: David, I'm looking for help on this one since it's seems to be very much wrapped up in the property system and environment manager and cloud layers. This problem seems to be very complicated. Agreed. I've managed to patch things up in my local copy so that it

RE: [Flightgear-devel] Crash on Reset function.

2002-06-05 Thread Norman Vine
David Megginson writes: Curtis L. Olson writes: David, I'm looking for help on this one since it's seems to be very much wrapped up in the property system and environment manager and cloud layers. This problem seems to be very complicated. Agreed. Remember that reset has always

RE: [Flightgear-devel] Crash on Reset function.

2002-06-05 Thread Jim Wilson
Norman Vine [EMAIL PROTECTED] said: Hopefully once we get 'reset' working again developers will test 'reset' before submitting their changes in the future so we don't repeat this quagmire Maybe that should be part of a minimum test before something is commited to cvs? Actually my most

Re: [Flightgear-devel] Crash on Reset function.

2002-06-04 Thread Curtis L. Olson
Jim Wilson writes: Curtis L. Olson [EMAIL PROTECTED] said: Has anyone tried to debug the Reset menu crash? Yes, right after the cloud layer changes went in it started. David knows about it. Comment out the cloud layer config in preferences.xml and the problem goes away (but you have

Re: [Flightgear-devel] Crash on Reset function.

2002-06-04 Thread Curtis L. Olson
Curtis L. Olson writes: Jim Wilson writes: Curtis L. Olson [EMAIL PROTECTED] said: Has anyone tried to debug the Reset menu crash? Yes, right after the cloud layer changes went in it started. David knows about it. Comment out the cloud layer config in preferences.xml and the

Re: [Flightgear-devel] Crash on Reset function.

2002-06-04 Thread Curtis L. Olson
Jim Wilson writes: Yes, right after the cloud layer changes went in it started. David knows about it. Comment out the cloud layer config in preferences.xml and the problem goes away (but you have no clouds). It appears there's something that isn't getting cleaned up in the simgear code.

Re: [Flightgear-devel] Crash on Reset function.

2002-06-04 Thread Jim Wilson
Curtis L. Olson [EMAIL PROTECTED] said: At the start of the program we save a copy of the property tree. As part of restoring the initial state we copy back this saved property tree to the current/master property tree. Because of callbacks (functions tied to property reads and writes)

Re: [Flightgear-devel] Crash on Reset function.

2002-06-03 Thread Jim Wilson
Curtis L. Olson [EMAIL PROTECTED] said: Has anyone tried to debug the Reset menu crash? Yes, right after the cloud layer changes went in it started. David knows about it. Comment out the cloud layer config in preferences.xml and the problem goes away (but you have no clouds). It appears

RE: [Flightgear-devel] Crash on Reset function.

2002-06-03 Thread Norman Vine
Curtis L. Olson writes: Has anyone tried to debug the Reset menu crash? Yep, but no joy. This is a bug we shouldn't let sit around very long. The longer it sits, the harder it will be to track down. FWIW: It is curious that 'goto airport' seems to still work Norman

Re: [Flightgear-devel] Crash on Reset function.

2002-06-03 Thread Andy Ross
Curtis L. Olson wrote: Has anyone tried to debug the Reset menu crash? I've been looking at it for an hour and am just going in circles. Half the time I get a segfault with no backtrace ... I don't remember what a malloc segfault exactly means, but I seem to recall that it probably means

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread Curtis L. Olson
Tony Peden writes: OK, I've figured out what the problem is. At intialization both the altitude and runway altitude are set: Start common FDM init ...initializing position... FGJSBsim::set_Longitude: -2.0444 FGJSBsim::set_Latitude: 0.572695 cur alt (ft) = 0 FGJSBsim::set_Altitude:

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread jsb
Question: Who's responsibility is it (or should it be) to set the runway elevation inside of FGInterface? JSBSIm does fine on its own by using a runway elevation (or scenery elevation, or whatever) of zero - assuming sea level operations only, for now. JSBSim defaults to sea level in

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread Curtis L. Olson
[EMAIL PROTECTED] writes: Question: Who's responsibility is it (or should it be) to set the runway elevation inside of FGInterface? JSBSIm does fine on its own by using a runway elevation (or scenery elevation, or whatever) of zero - assuming sea level operations only, for now. JSBSim

RE: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread BERNDT, JON S. (JON) (JSC-EX) (LM)
I didn't mean to evoke a defensive response. [That's just how I write, sometimes. I wasn't being defensive - though it came across that way - just argumentative. :-)] The question is, who should be updating the values inside of FGInterface (which are really inside the JSBSim class since

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread Tony Peden
We should also investigate why FlightGear is reporting one elevation initially and then amending it to something else later ... there's something not quite right there either. That investigation isn't going to happen though before 0.7.9. This, it seems to me, is the root cause of the

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread David Megginson
Curtis L. Olson writes: The question is, who should be updating the values inside of FGInterface (which are really inside the JSBSim class since JSBSim inherits from FGInterface.) This is what JSBSim is using for runway elevation and is what is not getting updated when starting at KMYF.

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread Andy Ross
Curtis L. Olson wrote: JSBSim properly handles updating the runway/ground elevation most of the time, but here is at least one situation where it doesn't. YASim doesn't handle this at all (but Andy's the new kid so we can cut him some slack.) :-) Uh, stupid question: where do I stick

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread Curtis L. Olson
Andy Ross writes: Curtis L. Olson wrote: JSBSim properly handles updating the runway/ground elevation most of the time, but here is at least one situation where it doesn't. YASim doesn't handle this at all (but Andy's the new kid so we can cut him some slack.) :-) Uh, stupid

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread Andy Ross
Curtis L. Olson wrote: Andy Ross wrote: Uh, stupid question: where do I stick the number? I can't imagine this is difficult to fix. Should be a breeze. Essentially you are assuming that the runway elevation field in the FGInterface structure is getting updated externally by

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread Curtis L. Olson
I think that does the trick, thank! Curt. Andy Ross writes: Curtis L. Olson wrote: Andy Ross wrote: Uh, stupid question: where do I stick the number? I can't imagine this is difficult to fix. Should be a breeze. Essentially you are assuming that the runway elevation

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-15 Thread Tony Peden
On Thu, 2002-02-14 at 09:09, Alex Perry wrote: The current CVS hangs for me when ground started at KMYF, yet is fine at KSFO. Immediate crash. It's a long way to commute, could we fix that sometime? I've sent a fix off to Curt for this. ___

[Flightgear-devel] Crash when KMYF not KSFO

2002-02-14 Thread Alex Perry
The current CVS hangs for me when ground started at KMYF, yet is fine at KSFO. Immediate crash. It's a long way to commute, could we fix that sometime? ___ Flightgear-devel mailing list [EMAIL PROTECTED]

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-14 Thread Curtis L. Olson
Alex Perry writes: The current CVS hangs for me when ground started at KMYF, yet is fine at KSFO. Immediate crash. It's a long way to commute, could we fix that sometime? Hmmm, I can verify this same problem here too. With fgfs --airport-id=KMYF : - Flightgear starts up. - The JSBSim

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-14 Thread Martin Spott
So it appears that at least for KMYF, JSBSim and FlightGear are having a very strong disagreement over the elevation of the ground, and neither is willing to budge. Sounds like two typical flightgear developers. :-) Yep :-) This is _very_ similar to what I've been experiencing with 0.7.8

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-14 Thread Alex Perry
Ok, there is something really strange here, probably because things were changed without a proper understanding of how everything worked together. My mind is fryed at the moment looking at this stuff. JSBSim seems to be doing the right thing *except* for at KMYF. Whatever it was I said to

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-14 Thread Andy Ross
Curtis L. Olson wrote: Ok, looking further, it appears that nothing, no place, no where is setting the runway elevation any more ... it get's initialized at startup, but then never is updated as the aircraft moves. Ah, which explains why I've never seen this. I only ever bother testing in

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-14 Thread David Megginson
David Megginson writes: Hmmm, If I start at KSAN and taxi to KMYF, JSBSim seems happy with the ground elevation and everything jives with where FGFS thinks the ground is. The problem seems to be somehow at startup/init time. Very strange and confusing ... I don't see any

Re: [Flightgear-devel] Crash when KMYF not KSFO

2002-02-14 Thread Tony Peden
On Thu, 2002-02-14 at 09:09, Alex Perry wrote: The current CVS hangs for me when ground started at KMYF, yet is fine at KSFO. Immediate crash. It's a long way to commute, could we fix that sometime? It looks to me like there are at least a couple of problems. 1) the altitude is initially set

Re: [Flightgear-devel] Crash on linux with latest CVS code

2002-01-24 Thread David Megginson
Curtis L. Olson writes: If you're using Emacs, try M-x cvs-examine and then enter the root directory for the base package when propted. Use 'x' to clear any warning messages, etc., then see what's left. Interesting tool. In Debian anyway, make sure you have the

Re: [Flightgear-devel] Crash on linux with latest CVS code

2002-01-24 Thread James Gallagher
On Wed, 2002-01-23 at 19:40, Jim Wilson wrote: James, I rebuilt again from CVS tonight (2nd time this week) and no problems. When I do it I do a full rebuild including all the config and makefiles (even if I think it might not be necessary). This is a gcc2.95.2/glibc2.1 system for what

Re: [Flightgear-devel] Crash on linux with latest CVS code

2002-01-23 Thread Jim Wilson
James, I rebuilt again from CVS tonight (2nd time this week) and no problems. When I do it I do a full rebuild including all the config and makefiles (even if I think it might not be necessary). This is a gcc2.95.2/glibc2.1 system for what thats worth. Ran default just as you did and it loads