Re: [Flightgear-devel] JSBsim C310 crashes the sim on gear retraction.
On Thursday 14 February 2002 01:59 am, you wrote: That's the same error I have on the C172 at simulator startup. FYI. JSBsim C310 crashes the sim on gear retraction. So ... this is an error? This is the same message I get if I do this in real life. ;-) Jon Happens in the air too ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
Some time ago a big company, which shall remain nameless, bought 3dfx. They have now opted to yank the 3dfx site, and all support for old cards with it. (That alone is reason enough not to buy their cards.) Yes, I wish there was more choice in the 3d graphics world. You could always try an ATI card. People have been reporting pretty good results with their cards. especially me, crying very loud :-) The first PeeCee is set up, dedicated to run FlightGear, is using a 3dfx Voodoo3 PCI with 16 MByte. No trouble at all with the moon. This machine has been running XFree86 in 4.0.1, 4.0.3 and 4.1.0. I don't know how much difference there is between Voodoo2 and -3, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-release windows binary
Alex Perry writes: Alex Perry writes: * On a G400 card with lots of memory, I'm getting 4fps out-the-box. This is down from the high 20s previous versions. It improves to 14fps if I get rid of the Textures.high directory temporarily. Thus, the decision making for texture sizing could be better. Is this built --with-logging or --without-logging? Dunno. It was the pre2 prebuilt binary from the Nottingham server ... It was built without logging: CFLAGS=-Wall -O2 CXXFLAGS=-Wall -O2 ./configure --without- logging The JSBSim logging is still output but most of that is not output during actual flight. I get fine framerates with it - they seem to be fill-rate limited at 37fps at 1152x864 on an Athlon 1.2 with Oxygen VX1. On a P350 with a 32MB ATI card (one of the Rage Chipsets - no TL) I get high 30's (probably fillrate limited) most of the time in the UK, dropping into the teens around high polygon areas such as KSFO. I have noticed that some cards get hit very hard at the larger airports (ie KSFO), dropping to low single figures when looking at the airport, but they are generally 8MB cards. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-release Irix binary
Martin Spott wrote: Erik, I've uploaded a pre-release version of FlightGear 0.7.9 at: did you notice that you put the old 0.7.7 binary into that package ? 'inst' complains about installing an older package as the one already installed, Uck, I must have changed the version behaviour. I'll make sure it will work for the official release. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tiled panel background
Hi Dave! I've seen in your fgfs directory nice screenshots with runway lights could you please tell us the method how to make it? Thanx Bye P.S. Currently I try to incorporate loading of runway lights in tileentry.cxx but no still success - Original Message - From: David Findlay [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 13, 2002 9:14 AM Subject: Re: [Flightgear-devel] tiled panel background On Wed, 13 Feb 2002 15:02, you wrote: It turned out to be quite easy to add multiple tiles for a panel background. This simple one could be enhanced to have more detail but it does look quite a bit better than a single 256x256 stretched accross the window. http://www.spiderbark.com/fgfs/c310-tiled-panel.png Definately. I hope this will go into 0.7.9 so it can be thoroughly tested for the 0.8 stable release. David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C310 Gear Retraction
I'm having no problem retracting the C310 gear in flight, using yesterday's CVS version of everything. It's possible that there's a problem in some builds, but it's equally possible that people are letting the plane settle back onto the ground after retracting gear. Try waiting for a higher altitude first, and see if the problem still occurs. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C310 Gear Retraction
On Thu, 2002-02-14 at 04:21, David Megginson wrote: I'm having no problem retracting the C310 gear in flight, using yesterday's CVS version of everything. It's possible that there's a problem in some builds, but it's equally possible that people are letting the plane settle back onto the ground after retracting gear. Try waiting for a higher altitude first, and see if the problem still occurs. Ditto with a clean build of this mornings FG, SG, and base. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Engines start at idle (was Re: [Flightgear-devel] for the upcoming release)
John Check [EMAIL PROTECTED] said: I could bind a toggle for the brakes to the indicator. I think it's fairly likely somebody might click on it Yep great idea. Is the at-startup-parking-brake working? I couldn't seem to make it work last night. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBsim C310 crashes the sim on gearretraction.
On Thu, 2002-02-14 at 02:39, Erik Hofman wrote:
Alex Perry wrote:
That's the same error I have on the C172 at simulator startup. FYI.
A crash at startup is mostly because of stale objects files hanging
around. I think you should do a make clean in src/FDM/JSBSim and
remove src/FDM/JSBSim.o and try again.
JSBsim C310 crashes the sim on gear retraction.
$PATLA,117.30,119.0,111.80,29.0,266*69
182: GEAR_CONTACT 1
183: Crash Detected
184: GEAR_CONTACT 1
185: Crash Detected
186: GEAR_CONTACT 1
187: Crash Detected
188: GEAR_CONTACT 1
189: Crash Detected
190: GEAR_CONTACT 1
191: Crash Detected
192: GEAR_CONTACT 1
193: Crash Detected
194: GEAR_CONTACT 1
195: Crash Detected
Tile not found (Ok if initializing)
Attempting to schedule tiles for bogus latitude and
longitude. This is a FATAL error. Exiting!
This gets fixed by this patch:
--- /home/erik/src/CVS/fgfs/JSBSim/FGLGear.cpp Fri Jan 25 21:10:22 2002
+++ FGLGear.cpp Thu Feb 14 11:26:01 2002
@@ -189,9 +189,11 @@
if (isRetractable) {
if (FCS-GetGearPos() 0.01) {
+ FCS-SetGearPos(0.0);
GearUp = true;
GearDown = false;
} else if (FCS-GetGearPos() 0.99) {
+ FCS-SetGearPos(1.0);
GearDown = true;
GearUp = false;
} else {
Ths problem is that GearPos is decreased to it lowest maximum value
somewhere in the retraction code.
I suspect there is a check for == 0 where 0.01 would be more apropriate.
Erik
In as far as the gear are concerned, once FCS-GetGearPos() is below
0.01 or above 0.99, the gear are up and locked or down and locked
respectively so FCS-GetGearPos() ceases to have any meaning.
(that's what the code above does)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] CTRL+U and JSBsim
On Wed, 2002-02-13 at 15:58, Jim Wilson wrote:
Tony Peden [EMAIL PROTECTED] said:
On Wed, 2002-02-13 at 14:59, David Megginson wrote:
Interesting. I have no objection to removing the binding completely,
but it is showing up a more serious problem with JSBSim's ground
trimming (it tries to trim to the ground on reset even when the plane
is already in flight).
The way its set up right now, it should trim in-air if the speed is
above 10 knots.
From FGJSBSim::do_trim():
if(fgic-GetVcalibratedKtsIC() 10 ) {
fgic-SetVcalibratedKtsIC(0.0);
fgtrim=new FGTrim(fdmex,fgic,tGround);
} else {
fgtrim=new FGTrim(fdmex,fgic,tLongitudinal);
}
If there's a more reliable way to figure out that we want to
be on the ground (aside from a similar hack with altitude)
I'll be happy to change it.
It's doing it at full or near full throttle cruise. Is there an exception
handler that's doing a reset (although it's a bad reset...not going back to
the runway)?
OK, I know what the problem is here, and it's going to take some time to
fix. The easiest workaround is probably to have the reset (and/or
control u handler) reset the speed.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Crashes if no scenery file at startup location
Just wondering if this is a necessary JSBsim feature. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-release Irix binary
Uck, I must have changed the version behaviour. I'll make sure it will work for the official release. Where will you place the final version ? Will you update your FlightGear web page http://www.a1.nl/~ehofman/fgfs/ so we can point to it ? I'd like to update the comments on IRIX in the Getting Started manual accordingly, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Goto airport bug.
On Tue 12. February 2002 22:33, you wrote: This works fine for me. Are you running with the latest fgfs cvs? Yes, with yesterday CVS (plib,SG,FG,fgfsbase) and rebuild after uninstall and distclean, but I must note that I use threads. I find that it occurs only sometimes and have diferent symptomps. I tried frequently switch between KSFO,KEDW(I haven't tile files for this) and LKPR and after some time I get this symptoms. Turn coordinator locked in strange angle. Program terminated with mesage: Bad Psi rotation and some number. Bad Longtitude. Bell upside I get only, when switch from KEDW. I also find that It maybe depend, if all tiles of old airport are loaded or not. At first airport switch I get aircraft on runway of LKPR very occasionaly. Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 13, 2002 at 08:24:14PM -0600, Curtis L. Olson wrote: the moon is using a blend mode other than the default blend mode so that we can blend it into the gradient sky. Thanks, that was exactly the information I needed to get me started. In my first try I changed the call to glBlendFunc(): In SimGear-0.0.17pre2/simgear/src/sky/moon.cxx: sgMoonOrbPreDraw() - line 55: glBlendFunc ( GL_SRC_ALPHA, GL_ONE ) ; + line 55: glBlendFunc ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ) ; That worked, but made the moon look ugly. I could have been satisfied at this point and take the ugly moon for granted. However, on a hunch, I changed line 55 back and in sgMoonOrbPostDraw() uncommented line 65: - line 65: // glBlendFunc ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ) ; + line 65: glBlendFunc ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ) ; That works, _and_ produces a nice moon. So it appears that the problem lies not with the blend function itself, but in the way it is (not) handled by glPushAttrib()/glPopAttrib(). Does anyone object to leaving line 65 uncommented for now? Any leads for a more permanent solution? Yes, I wish there was more choice in the 3d graphics world. You could always try an ATI card. I'd love to. Please send plenty of money. :) I personally have very few complaints about my nvidia card. If it works, it works. As long as it is supported. Not a problem if you have enough financial room for regular upgrades, and don't care what happens to your old cards. And that's all I'm going to say about it on-list. - -- Regards,() =Martin= ASCII Ribbon Campaign Against HTML Mail /\ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] 0.7.9pre2 In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Wed, Feb 13, 2002 at 08:24:14PM -0600 X-S-Issue: [EMAIL PROTECTED] 2002/02/14 13:42:54 f012d29695f35ee4e2e4d2c72a6eae85 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjxrsNUACgkQN880WP6HRIsv5ACgt3uHfI4AvYQ8Wwt/ExYxUmxm qZIAn233KiFrOVUvZvIT5rZ6iwOB5jcK =vN69 -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: KSFO ATIS
As long as we're clearing up odds and ends, should we have COM1 default to 118.85 for KSFO ATIS in 0.7.9? That means that the sim will start with the ATIS text scrolling across the top of the screen, but users might not know how to get rid of it. I dislike it, because it appears to eat about 10 fps Also as long as there's no knob, easy to find to stop ATIS display, I would not vote for setting it a default. Does anyone know there additional 25 fps have gone simply by changes in the base package ? I didn't do a recompile since pre2, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crashes if no scenery file at startup location
I'm only getting this with JSBsim right now. Maybe I've got something screwed up here anyone else seeing this? The symptom is that if I specify an airport that is not in scenery the simulation comes up correctly momentarily and then tries to load a tile and does the fatal bogus long/lat error. This is the output using --airport-id=EHAM: http://www.spiderbark.com/fgfs/scenerynotfound.txt Note that this problem does go away if I set --altitude=0 or some other small number before starting. The problem may be stemming from an improper altitude sent to the FGInterface bus or something ... I don't know. Tony: if we are given an incorrect unsynchronized altitude data what does the trim routine do? I am thinking this is due to differences in the way JSBSim is started up but not explicitly in the JSBSim code. Could be a bug in the way altitude is figured for some airports? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
[EMAIL PROTECTED] writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 13, 2002 at 08:24:14PM -0600, Curtis L. Olson wrote: the moon is using a blend mode other than the default blend mode so that we can blend it into the gradient sky. Thanks, that was exactly the information I needed to get me started. In my first try I changed the call to glBlendFunc(): In SimGear-0.0.17pre2/simgear/src/sky/moon.cxx: sgMoonOrbPreDraw() - line 55: glBlendFunc ( GL_SRC_ALPHA, GL_ONE ) ; + line 55: glBlendFunc ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ) ; That worked, but made the moon look ugly. I could have been satisfied at this point and take the ugly moon for granted. However, on a hunch, I changed line 55 back and in sgMoonOrbPostDraw() uncommented line 65: - line 65: // glBlendFunc ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ) ; + line 65: glBlendFunc ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ) ; That works, _and_ produces a nice moon. So it appears that the problem lies not with the blend function itself, but in the way it is (not) handled by glPushAttrib()/glPopAttrib(). Does anyone object to leaving line 65 uncommented for now? Any leads for a more permanent solution? That seems like a reasonable compromise ... done. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-release Irix binary
Martin Spott wrote: Uck, I must have changed the version behaviour. I'll make sure it will work for the official release. Where will you place the final version ? Will you update your FlightGear web page http://www.a1.nl/~ehofman/fgfs/ so we can point to it ? I'd like to update the comments on IRIX in the Getting Started manual accordingly, Yes, that's the intention. I'm still working with some people from SGI to get this release at the Freeware site. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C310 Gear Retraction
David Megginson writes: I'm having no problem retracting the C310 gear in flight, using yesterday's CVS version of everything. It's possible that there's a problem in some builds, but it's equally possible that people are letting the plane settle back onto the ground after retracting gear. Try waiting for a higher altitude first, and see if the problem still occurs. I'm having no problem running with the c310, started the engines, full throttle, raised the gear as soon as the altimiter needle started to increase. Everything seemed good there. With respect to the c310 flight model math blowing up when you nose over into a dive: If I have the blue levers pushed all the way in (low gear) this happens very reliably. Push the nose over into a dive and in a few seconds everything blows up. But, if I have the blue levers pulled out a bit, I can dive all day long and things stay well behaved. So, this would lead me to suspect something in the constant speed prop code is screwing up at a boundary condition. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C310 Gear Retraction
--- Curtis L. Olson [EMAIL PROTECTED] wrote: David Megginson writes: I'm having no problem retracting the C310 gear in flight, using yesterday's CVS version of everything. It's possible that there's a problem in some builds, but it's equally possible that people are letting the plane settle back onto the ground after retracting gear. Try waiting for a higher altitude first, and see if the problem still occurs. I'm having no problem running with the c310, started the engines, full throttle, raised the gear as soon as the altimiter needle started to increase. Everything seemed good there. With respect to the c310 flight model math blowing up when you nose over into a dive: If I have the blue levers pushed all the way in (low gear) this happens very reliably. Push the nose over into a dive and in a few seconds everything blows up. But, if I have the blue levers pulled out a bit, I can dive all day long and things stay well behaved. So, this would lead me to suspect something in the constant speed prop code is screwing up at a boundary condition. To confirm, it may be worth substituting the c172 prop (prop75in2f, I think) to confirm this. That assumes, of course, that you'll be able to get off the ground ... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Engines start at idle (was Re: [Flightgear-devel] for the upcoming release)
Jim Wilson writes: Yep great idea. Is the at-startup-parking-brake working? I couldn't seem to make it work last night. No, there's some kind of a bug (it might just be that JSBSim is overriding the initial setting), and I'll have to investigate. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: KSFO ATIS
Martin Spott writes: I dislike it, because it appears to eat about 10 fps Also as long as there's no knob, easy to find to stop ATIS display, I would not vote for setting it a default. OK, that's the first objection. Any other comments? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C310 Gear Retraction
Erik Hofman writes: I'm having no problem retracting the C310 gear in flight, using yesterday's CVS version of everything. It's possible that there's a problem in some builds, but it's equally possible that people are letting the plane settle back onto the ground after retracting gear. Try waiting for a higher altitude first, and see if the problem still occurs. Ditto with a clean build of this mornings FG, SG, and base. It still happens over here ... Erik: how high is your altitude AGL before you retract? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: KSFO ATIS
Curtis L. Olson writes: I'd prefer the scrolling text to be off be default. Again for the sake of realism, you don't have scrolling text across your windshield in a real plane. I know this is a compromise because we are in a simulated environment, and it's a nice feature, but I think I would prefer to have it off by default. No problem -- I'll retune COM1 to an inactive frequency. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New manual available.
Michael and Martin have sent me an updated version of the Installation and Getting Started Guide: http://www.flightgear.org/Docs/ Please take a moment to read through it if you can and send Michael or Martin and suggestions or fixes. Only little stuff can be fixed for 0.7.9 but larger suggestions can be considered for subsequent releases. The manual is really quite extensive and impressive and represents a very large amount of work. It is definitely worth reading through. I learned several new things myself. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: KSFO ATIS
Curtis L. Olson writes: I'd prefer the scrolling text to be off be default. Again for the sake of realism, you don't have scrolling text across your windshield in a real plane. I know this is a compromise because we are in a simulated environment, and it's a nice feature, but I think I would prefer to have it off by default. I'd agree with that as well. Logically, the pilot should be tuned to tower when on the runway, having listened to the ATIS transmission prior to startup. Leaving it as the standby frequency means that people can find it very easily if they wish. May I also suggest that we change the primary nav frequency, since it is tuned to a VOR that is just out of range, and hence flicks back and forward. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] New manual available.
Curtis L. Olson writes: Michael and Martin have sent me an updated version of the Installation and Getting Started Guide: http://www.flightgear.org/Docs/ Please take a moment to read through it if you can and send Michael or Martin and suggestions or fixes. Only little stuff can be fixed for 0.7.9 but larger suggestions can be considered for subsequent releases. The manual is really quite extensive and impressive and represents a very large amount of work. It is definitely worth reading through. I learned several new things myself. :-) Even after just a quick skim, WOW! Great work, guys. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Another documentation correction
Regarding this paragraph, Recently, Andrew Ross contributed another flight model called YASim for Yet another simulator. At present, it sports another Cessna 172, a Cessna 182 and a Boeing 747. This one is based on geometry information rather than aerodynamic coefficients. Although it is not that sophisticated like e.g. JSBSim it is intended to be very somple to use and lets you fly many differnet airplanes. YASim also includes a fairly good DC-3 model, along with a 747, Harrier, and A4. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-release windows binary
Alex Perry writes: Alex Perry writes: * On a G400 card with lots of memory, I'm getting 4fps out-the-box. This is down from the high 20s previous versions. It improves to 14fps if I get rid of the Textures.high directory temporarily. Thus, the decision making for texture sizing could be better. Is this built --with-logging or --without-logging? Dunno. It was the pre2 prebuilt binary from the Nottingham server ... It was built without logging: CFLAGS=-Wall -O2 CXXFLAGS=-Wall -O2 ./configure --without- logging I have noticed that some cards get hit very hard at the larger airports (ie KSFO), dropping to low single figures when looking at the airport, but they are generally 8MB cards. Yeah, as I tried to imply, I don't think it's the build. If we're making decisions on which textures to use by asking the GL what size it supports, I should point out that many versions state a size that is twice as big as the hardware supports. In that case, the driver makes four passes through the relevant triangles to pick up all four quadrants of the big textures, leading to a massive hit on framerate. Can we have a command line / preferences option to specify whether to use the hires textures as-is or to forcibly ignore the directory? On several of my (linux) machines, I've got a patch in there for that. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New manual available.
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.02.14 09:58]: Michael and Martin have sent me an updated version of the Installation and Getting Started Guide: http://www.flightgear.org/Docs/ Please take a moment to read through it if you can and send Michael or Martin and suggestions or fixes. Only little stuff can be fixed for 0.7.9 but larger suggestions can be considered for subsequent releases. The HTML versions on the website are trying to load non-existent CSS files (getstart.css FGShortRef.css). NS4 won't even show the page without the CSS files in place. :-/ -- Cameron Moore / The other day, I went to a tourist information booth and asked, \ \ Tell me about some of the people who were here last year./ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New manual available.
Michael and Martin have sent me an updated version of the Installation and Getting Started Guide: http://www.flightgear.org/Docs/ Thanks for the kind announcement. The 'European' website mirror - I believe it's the only one around here :-) - is up to date. You might want to read it from there. Please don't shoot us for some shortcomings in the text layout, this will be fixed until official release, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Crash when KMYF not KSFO
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] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New manual available.
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.02.14 09:58]: The manual is really quite extensive and impressive and represents a very large amount of work. It is definitely worth reading through. I learned several new things myself. :-) First, Michael and Martin have done a fabulous job. Kudos to both of you for a job well done. Please take a moment to read through it if you can and send Michael or Martin and suggestions or fixes. Only little stuff can be fixed for 0.7.9 but larger suggestions can be considered for subsequent releases. I've looked through some of the manual today (don't tell my boss ;-). Here's some notes (I converted the PDF to Postscript, so the page numbers may be off): - p29: I believe binaries are also shipped with SuSE Linux, though I don't think you need to discuss how to install them. - p62: first line reads Alls this project goes back Need to rephrase that to make sense. :-) How about The FlightGear project goes back - p65: the operational radio stack section seems out of place. IMO it should come later to keep the items in chronological order. - p71: my entry needs two changes: I would prefer to use cameron at unbeatenpath.net in that situation, and the word administration needs to be administrator. - p75: Section A.3 starts out with At first:. I think that can be removed. In the same sentence, I'd change until this point to up to this point. I'd start the second paragraph with Despite the current set of features, or Despite all of the progress so far,. Hmm, I'm finding stuff left and right. I'm going to have to be a good husband tonight, but I will try to make a point to read through some more of this and send any revisions to Michael. Thanks -- Cameron Moore [ If you think nobody cares about you, try missing a couple payments. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CTRL+U and JSBsim
* [EMAIL PROTECTED] (Curt Olson) [2002.02.13 15:44]: BERNDT, JON S. (JON) (JSC-EX) (LM) writes: OK. What does Ctrl-U do?? This was a *hack* that incremented altitude by 1000'. It was easy to do in LaRCsim. However, it's ugly, not realistic, and I'd rather have a more sensible and complete set of repositioning options instead. I'd be happy to see us jettison ^U ... Just to provide some historical context, Ctrl+U used to be more useful when you could get caught upside-down after a crash. Now that we freeze everything on a crash, we don't really need it for anything. -- Cameron Moore [ Why is it that doctors call what they do practice? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New manual available.
The HTML versions on the website are trying to load non-existent CSS files (getstart.css FGShortRef.css). NS4 won't even show the page without the CSS files in place. :-/ Hmmm, I can't confirm this - just had a test with Netscape-4.78 on Linux, with and without enabling style sheets in the Advanced Preferences menu it shows the same picture to me: http://document.ihg.uni-duisburg.de/FGFS/HTML.png As Michael said: We'll investigate this. Is there anyone to confirm ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New manual available.
* [EMAIL PROTECTED] (Martin Spott) [2002.02.14 11:55]: The HTML versions on the website are trying to load non-existent CSS files (getstart.css FGShortRef.css). NS4 won't even show the page without the CSS files in place. :-/ Hmmm, I can't confirm this - just had a test with Netscape-4.78 on Linux, with and without enabling style sheets in the Advanced Preferences menu it shows the same picture to me: I'm using Netscape v4.77 under Linux. Thanks -- Cameron Moore [ Where do forest rangers go to get away from it all? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash when KMYF not KSFO
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 constructer is called, and the aircraft config file is loaded. (But JSBSim is not init'ed until after the scenery loads so we can pass in a proper ground elevation to the trimming routine.) - FlightGear continues to load/init various systems. - FlightGear finally gets around to loading the local scenery tile and a valid ground elevation appears on the bus. - FlightGear determines that it is now ok to run the JSBSim init() routine. This triggers a ground trim and JSBSim prints touch down reports and a bunch of other output and finally returns with: Trim successful JSBSim State Trim complete - This is immediately followed by a long sequence of: 0: GEAR_CONTACT 1 1: GEAR_CONTACT 1 2: GEAR_CONTACT 1 3: GEAR_CONTACT 1 4: GEAR_CONTACT 0 5: GEAR_CONTACT 0 6: GEAR_CONTACT 0 7: GEAR_CONTACT 0 8: GEAR_CONTACT 1 etc. . . . 56: GEAR_CONTACT 1 - It appears that JSBSim has trimmed the aircraft to below ground so FlightGear notices this and attempts to force JSBSim to use a higher elevation. This triggers another ground trim, again which ends up several meters underground, again causing FGFS to try to force JSBSim back up above the ground. - There seems to be a long exchange of angry words with subsequent JSBSim trims failing. - This is followed by JSBSim spewing out 985 successive GEAR_CONTACT bool messages. - Again FGFS tries to force/coax JSBSim up to ground level. - More of the same with JSBSim triming under ground, the gear code goes berzerk, spews 100's more GEAR_CONTACT messages. - Eventually JSBSim flags a CRASH. - JSBSim is hosed at this point and copies a completely bogus lat/lon onto the bus. - The flightgear tile pager sees that we have moved to a completely impossible location, flags a non-recoverable error and exits the sim. Wow, that was really ugly. It happens very quickly, and most of those messages scroll right on by before you can see them if you don't run the output through less or more or something similar. 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. :-) I haven't been able to reproduce this at any other airport I've tried, only KMYF. Ok, after all that, I tried the same thing with the YASim c172 at KMYF and something is wierd at KMYF. YASim started just fine and took off fine, but the entire time, FGFS was spewing message about being below ground. I wonder if it is a problem with the scenery models right there? Hmmm, this appears at the moment to be some sort of flightgear problem??? 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. That is really odd ... what got sliced out of the code? It's been a while so I don't remember where this was supposed to happen. The view code has a bit of a hack to force the view height above the ground so it's hard to notice. This is really weird. In theory, you'd see very strange effects if you started at a lower elevation airport and flew to a different elevation aiport and tried to land. 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. YASim assumes that the runway altitude will get set for it externally, that makes a lot of sense, but apparently isn't the case. This sucks. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash when KMYF not KSFO
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 on KEDW - and _only_ on this one, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash when KMYF not KSFO
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 whomever, I'm sorry and I apologize. Can I have my airport back please ? 8-) Actually, one odd thing. Everything looks fine if you airstart and land. It's also fine if you specify --altitude=400 on the command line. The default airports file shows the correct altitude of 423ft, but the HUD and ALT report noticably less, about 412ft, on startup. YASim assumes that the runway altitude will get set for it externally, that makes a lot of sense, but apparently isn't the case. I haven't tried that yet. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Another documentation correction
Alex Perry wrote: Think of it this way: a YASim aircraft will be as close to the real airplane as the real one is to any other aircraft of the same general class. That's good enough for me. And in a lot of situations (military aircraft in particular), this is as good as we're going to get anyway. There isn't any public performance data for these beasts. How about this ? JSB will be exact for every situation that is known and flight tested, but may have odd and/or unrealistic behavior outside normal flight. (Shhht, don't let Jon hear this!) YA will be sensible and consistent in almost every flight situation, but is likely differ slightly from the performance numbers in the POH. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Another documentation correction
Alex Perry wrote: Think of it this way: a YASim aircraft will be as close to the real airplane as the real one is to any other aircraft of the same general class. That's good enough for me. And in a lot of situations (military aircraft in particular), this is as good as we're going to get anyway. There isn't any public performance data for these beasts. How about this ? JSB will be exact for every situation that is known and flight tested, but may have odd and/or unrealistic behavior outside normal flight. (Shhht, don't let Jon hear this!) Ha! Actually, when we get around to it, we do want to be plausible off-nominal, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash when KMYF not KSFO
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 the default scenery (I mean, I live here, right?), where all the useful airports are essentially at sea level. I'll try to remember to move around more. Ok, after all that, I tried the same thing with the YASim c172 at KMYF and something is wierd at KMYF. YASim started just fine and took off fine, but the entire time, FGFS was spewing message about being below ground. I wonder if it is a problem with the scenery models right there? Oh, and a tangent: what is the purpose behind the code in main.cxx that detects aircraft below ground and resets the elevation accordingly? One immediate bug is that it's not strictly correct -- the aircraft's position is by convention its nose. It can easily be in a crashed state with the nose sticking up in the air. There is a hard-coded 3m guard band in the code that presumably is intended to correct for this, but that can break for big aircraft (747) where 3m is juse noise. I actually have it commented out in my source at home, because it interacts badly with the crash detection. It's entierly possible for the aircraft to slip below ground to fgfs but not to YASim (YASim only checks the gear positions right now), resulting in a non-crash. The aircraft lawn-darts at 600 kts and then drifts slowly over the ground, still reporting a huge airspeed. So far as I can tell, there are no bad reactions to removing the check entirely. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash when KMYF not KSFO
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 evidence of a scenery model problem around KMYF. I have a guess about where the problem might be -- I recently modified JSBSim.cxx to copy start-up settings over from the FlightGear before initializing so that we'd get the initial engine values (RPM, etc.) into JSBSim. That might explain the tug-of-war; I'll look at it now. Nope -- that wasn't it (so I'm off the hook for now). Note that there is no problem with It's the JSBSim trimming routine. This works: fgfs --airport-id=KMYF --prop:/sim/startup/trim=false This doesn't work: fgfs --airport-id=KMYF --prop:/sim/startup/trim=true Note that the opposite applies everywhere else; i.e. fgfs --airport-id=KSFO --prop:/sim/startup/trim=false *doesn't* work (the plane flips over). I'll mention again that I'm using scenery I built myself, so this isn't just a glitch in Curt's official scenery build. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBsim C310 crashes the sim on gear retraction.
Tony Peden wrote: Well, I wasn't saying this was the cuase of the problem, just *a* solution. I figured there might be a counter somwhere which decreses GearPos by a certain amount, but the check didn't catch it being close to 0.0 Therefore it would en up in an endless loop or something. It's possible. Do you notice any problem with the flaps? (it's the same code: FDM/JSBSim/filtersjb/FGKinemat.[h|cpp]) No problems with flaps. Gear still doesn't work (did a complete compile from scratch again). :( Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New manual available.
Cameron Moore wrote: - p29: I believe binaries are also shipped with SuSE Linux, though I don't think you need to discuss how to install them. Yes they are. At least since 7.0 but I think it was ever earlier than that. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Gallery
There are two pictures of the OpenGC glass cockpit project running with FlightGear at the FlightGear gallery page now: http://www.flightgear.org/Gallery/ Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Another documentation correction
Ha! Actually, when we get around to it, we do want to be plausible off-nominal, too. Jon Jon, I read that sentence, digested it and promptly started snickering insanely. What a quote. I'm not crazy, I'm plausibly off-nominal! *rofl* ?? Maybe I've been around NASA types too long. ;-) What I meant was that we'd like to have at least *believable* flight dynamics when flying in off-nominal conditions (spin, hammerhead, etc.) But I am glad I made you laugh. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C310 Gear Retraction
Erik Hofman writes: Its' weel above 100 Foot. I tried different altitudes, non worked well. Have you tried different airports? It's strange that we cannot reproduce this. Does the problem occur as soon as the gear are retracted? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
AW: [Flightgear-devel] Another documentation correction
Andy, Oh, and a pedantic comment about the text: the use of the latin e.g. in the middle of English sentences is frowned upon as a matter of style. In almost all cases, the colloquial for example will work ... Thanks a lot. I'll print and keep this for future reference. BTW, we sure wouldn't mind a native English co-author to the Guide. I am sure the core developers have better to do, but just in case someone is lurking. I can't hide I am an amateur only :-( Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New manual available.
On Thursday 14 February 2002 03:38 pm, you wrote: Cameron Moore wrote: - p29: I believe binaries are also shipped with SuSE Linux, though I don't think you need to discuss how to install them. Yes they are. At least since 7.0 but I think it was ever earlier than that. CU, Christian I had it on 6.1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Another documentation correction
Maybe I've been around NASA types too long. ;-) What I meant was that we'd like to have at least *believable* flight dynamics when flying in off-nominal conditions (spin, hammerhead, etc.) But I am glad I made you laugh. :-) You just keep on hanging out with those NASA guys. :) BTW, if you haven't seen it already, check out http://www.orbitersim.com. g. -- I'm not crazy, I'm plausibly off-nominal! http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gallery
On Thursday 14 February 2002 04:11 pm, you wrote: There are two pictures of the OpenGC glass cockpit project running with FlightGear at the FlightGear gallery page now: http://www.flightgear.org/Gallery/ Curt. Now *thats* cool ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
AW: [Flightgear-devel] Gallery
On Thursday 14 February 2002 04:11 pm, John Check wrote: There are two pictures of the OpenGC glass cockpit project running with FlightGear at the FlightGear gallery page now: http://www.flightgear.org/Gallery/ Curt. Now *thats* cool Yes, it is. According to the picture, it IS possible to have FG + OpenGC running on the same machine (obviously at least one person had it :-). I always was under the impression this requires 2 networked machines. Perhaps someone could put together a simple readme for getting this running after the release? (Or is it somewhere and I overlooked it.) Thanks, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gallery
Yes, it is. According to the picture, it IS possible to have FG + OpenGC running on the same machine (obviously at least one person had it :-). I always was under the impression this requires 2 networked machines. Perhaps someone could put together a simple readme for getting this running after the release? (Or is it somewhere and I overlooked it.) Thanks, Michael Keen observation. Also you might notice why this 747 captain is going to have his ATR revoked or, at least, have some explaning to do Don't have any time left today to explain. Once I get it a litle more refined I'll throw together a README. Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash when KMYF not KSFO
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 to 382.53 feet, then later reset to the correct 413 ft. 2) when it is reset, JSBSim still thinks its 382 and trims to that. I'll see what I can do about #2. Finally initializing fdm Starting and initializing JSBsim Start common FDM init ...initializing position... FGJSBsim::set_Longitude: -2.0444 FGJSBsim::set_Latitude: 0.572695 cur alt (ft) = 0 FGJSBsim::set_Altitude: 382.535 lat (deg) = 32.813 ...initializing ground elevation to 382.535ft... common_init(): set ground elevation 382.535 FGJSBsim::set_Runway_altitude: 382.535 ...initializing sea-level radius... lat = 32.813 alt = 382.535 FGJSBsim::set_Sea_level_radius: 2.09052e+07 ...initializing velocities... FGJSBsim::set_V_calibrated_kts: 0 ...initializing Euler angles... FGJSBsim::set_Euler_Angles: 0, 0.0074002, 5.14977 End common FDM init [...] Finished initializing JSBSim FGControls::get_gear_down()= 1 FGJSBsim::set_Euler_Angles: 0, 0.0074002, 5.14977 FGJSBsim::set_Euler_Angles: 6.26822e-20, 0.0074002, 5.14977 FGJSBsim::set_Euler_Angles: 6.26822e-20, 0.0074002, 5.14977 fgFDMForceAltitude: 126.073 FGJSBsim::set_Altitude: 413.625 lat (deg) = 32.813 FGJSBsim::set_Sea_level_radius: 2.09256e+07 (*) Current Altitude = 116.60 123.07 forcing to 126.07 Ground Trim Initial Theta: 0.9126 Trim successful JSBSim State Trim complete [...] Weight:1964 lbs. CG: 43.0, 0.0, 39.6 inches Flaps: Up Gear: Down Speed:0 KCAS Mach: 0.00 Altitude: 387 ft. AGL Altitude: 5 ft. ^^^ Angle of Attack: 0.00 deg Pitch Angle: 0.89 deg Flight Path Angle: 0.00 deg Climb Rate:-0 ft/min Normal Load Factor: 1.00 g's Pitch Rate: 0.00 deg/s Heading: 295 deg true Sideslip: 0.00 deg Bank Angle: -0.00 deg Elevator: 0.00 deg Left Aileron: 0.00 deg Rudder: -0.00 deg Throttle: 0.00% Wind Components: 0.00 kts head wind, 0.00 kts cross wind Ground Speed:0 knots , Ground Track: 0 deg true ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: My Bad (was Re: [Flightgear-devel] Post 0.7.9 priorities)
Jonathan Polley writes: I tried halving the fog values and got something that looked more realistic, for the long distance visibilities at least. Would it be possible to change the fog equations along with the visibility? This would be for post-0.8.0. You can choose between linear, exp, and exp2 equations. GL_EXP corresponds more closely to heavy fog GL_EXP2 corresponds more to haze http://dmawww.epfl.ch/ebt-bin/nph-dweb/dynaweb/SGI_Developer/OpenGL_Porting/%40Generic__BookTextView/5836;uf=0#X You can use 'z' and 'Z' to adjust the fog on the fly. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
