Re: [Flightgear-devel] Aircraft
On Tuesday 12 February 2002 09:31 pm, you wrote: Can we try to make a decision of what aircraft are going to be in the 0.7.9 release, and then get them ready with panels, sounds and models? This way everything it ships with will be good. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel David, As always, licensing is an issue for 3d models. As a compromise I've been including all the markup in the set files so that users only need download models from Wolframs site, unzip them and drop 'em in. TTYL John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tiled panel background
On Wednesday 13 February 2002 12:02 am, 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 The code for this involves fairly minor changes and is contained in this tarball: http://www.spiderbark.com/fgfs/tiledpanel-021202.tar.gz Note that the rgb files and the xml file contained in the tarball should all be placed in $FGROOT/Aircraft/c310. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Looks real good. Where did you pull the background from? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft
As always, licensing is an issue for 3d models. As a compromise I've been including all the markup in the set files so that users only need download models from Wolframs site, unzip them and drop 'em in. That's why we need to create models for each of the aircraft before we ship 0.8. David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] for the upcoming release
John Check writes: We could do it like we do panel_2, it's no biggie. Mind you, 256x256 can only hold so much text, although we could use generated text. Or possibly do it as a HUD with static text. Just a quick note -- right now, I'm using 512x512 textures for the DC-3 model, effectively leaving it untextured for Voodoo3 users (but making my life a lot easier, since I have to map from only 2 texture files rather than 8). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Pre-release Irix binary
I've uploaded a pre-release version of FlightGear 0.7.9 at: http://www.a1.nl/~ehofman/fgfs/download/FlightGear-0.7.9.tardist This release also needs the following package: http://www.a1.nl/~ehofman/fgfs/download/metakit-2.0.1.tardist And either the following, or the equivalent of the SGI Freeware site: http://www.a1.nl/~ehofman/fgfs/download/jpeg-6b.tardist http://www.a1.nl/~ehofman/fgfs/download/zlib-1.1.3.tardist Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tiled panel background
David Findlay [EMAIL PROTECTED] said: On Wed, 13 Feb 2002 15:02, you wrote: Definately. I hope this will go into 0.7.9 so it can be thoroughly tested for the 0.8 stable release. It's probably too late for that. In any case I'd like to revisit the syntax of the xml (take a look at it) and it'd be good to be able to sync the aspect ratio to the most commonly used 4:3 geometry (which hasn't been done yet). The format I'm using for tiling now is this: +---+---+---+---+ | 1 + 3 + 5 + 7 + +---+---+---+---+ + 2 + 4 + 6 + 8 + +---+---+---+---+ Where the numbers represent the textures in the array. It'd probably be fine if it was included...it doesn't break old panels, but I do want to throw in the caveat that it isn't done. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tiled panel background
Jim Wilson writes: It's mine...started with a photo: http://www.aircraftdealer.com/hdmandassociates/list_1/images/panel-1.jpg But as you can see there isn't much resemblence to the photo other than general shape of the corner. It was the wrong perspective etc, etc. I've put a photo of a C310 panel that I took about 15 years ago up at: http://www.nottingham.ac.uk/~eazdluf/C310Panel.jpg in case its of any use to any of the artists. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Observations on latest cvs flightgear
David Megginson writes: Andy Ross writes: The startup stuff, though, should be really simple. What do I do, check the cranking flag and add some delay before it turns over? It would be better to have a cutoff RPM where the engine stops running. As long as the cranking flag is set, keep incrementing RPM slightly; once RPM hits the minimum cutoff, the engine can cough to life and run on its own (assuming available fuel, etc.). That doesn't really mimic what happens though. The torque curve of the starter motor means that the engine should spin up to its cranking speed very quickly. I'd go with the first scheme - just adding a bit of delay before it will fire when cranking. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: for the upcoming release
* David Megginson -- Wednesday 13 February 2002 13:26: Just a quick note -- right now, I'm using 512x512 textures for the DC-3 model, effectively leaving it untextured for Voodoo3 users (but making my life a lot easier, since I have to map from only 2 texture files rather than 8). I'm not amused. m. (Voodoo3 user :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Using the Blender for FlightGear Modelling
I've succeeded in using the Blender to create textured models for FlightGear, thanks to valuable help from Willian Germano. Here's how I did it: 1. Get Blender 2.23. 2. Install Python 2.0 (*precisely* that version). I compiled and installed a copy under /usr/local, even though Debian and already stuck 2.1 and 2.2 under /usr. 3. Download Willian Germano's AC3D export script for Blender from http://igspot.ig.com.br/wgermano/programming/index.html Willian is a PLIB user who designed the script specifically for PLIB-based applications, so it works. 4. Make your model out of meshes (not nurbs, surfaces, etc.) and texture using RGB images with dimensions that are a power of 2 (256x256 is probably the most common size). The Blender UV editor will help you place textures. Note: do not use more than one texture per object, because AC3D format does not support that. 5. Follow the instructions in Willian's README file for exporting an AC3D-format object from Blender, and copy the textures and the *.ac file to the same directory inside $FG_ROOT. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Re: for the upcoming release
* Mally -- Wednesday 13 February 2002 15:08: My old Voodoo Banshee would happily load 512x512 textures but automatically reduce them to 256x256. I suspect these textures will be OK for Voodoo users despite the 256x256 limit. Yes, that also seems to be the case for my V3-3000. The new textured DC3 does indeed work, albeit quite blurry, like Curtis had assumed. I'll fly that machine mainly at dusk/dawn then. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 0.7.9pre2
Thanks for everyone who has been beating on the 0.7.9 pre-releases. I have made the pre2 release available and am currently pushing it out to the mirrors (that I can push to.) Just a couple of tweaks between pre1 and pre2. Hey, should we bump up the release date and make a valentines release? My wife has to work late tomorrow night so it's not like I'd be in the dog house for sitting on my computer all night. :-) Or perhaps as everything seems to always end up being my fault once we've discussed it, maybe I should say I'll be in the dog house anyway so I might as well make the most of my time. :-) 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] prerelease tarballs
I've made prelease tarballs of SimGear-0.0.17 and FlightGear-0.7.9 and put them on the ftp server: The best FlightGear I've ever seen. I'm still hunting for bugs that I knew from previous releases and CVS checkouts (falling down on runways on startup etc.). Even effects similar to this one: http://document.ihg.uni-duisburg.de/fgfs-sky.jpeg (as already mentioned a few weeks ago) don't occur anymore, 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] 0.7.9pre2
The only thing preventing FlightGear from compiling on FreeBSD is the missing gcvt function. Jon and I discussed it some yesterday and I sent him a fix that places the definition in FGJSBBase.h. Hopefully that has made it to him. I know it may be too late now to get it into 0.7.9 though. Best of luck with the release. Cheers, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. Olson Sent: Wednesday, February 13, 2002 8:21 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] 0.7.9pre2 Thanks for everyone who has been beating on the 0.7.9 pre-releases. I have made the pre2 release available and am currently pushing it out to the mirrors (that I can push to.) Just a couple of tweaks between pre1 and pre2. Hey, should we bump up the release date and make a valentines release? My wife has to work late tomorrow night so it's not like I'd be in the dog house for sitting on my computer all night. :-) Or perhaps as everything seems to always end up being my fault once we've discussed it, maybe I should say I'll be in the dog house anyway so I might as well make the most of my time. :-) 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] for the upcoming release
Curtis L. Olson writes: As I understand it, in recent versions of plib, they have fixed the bug/feature that prevented oversized textures from being properly scaled down for voodoo users. So in theory, voodoo owners should still see the textures, but they will be a bit blurrier. This functionality most certainly depends on which version of plib you have installed. If this is working well now, perhaps we can pull the low-res textures from the base package. It's important to check whether the unusable large version of the texture is dropped from memory as well as ignored by the GL subsystem. Many of the machines with low-end graphics cards are short of memory, and having a few megabyte sized textures hanging around doesn't do much for performance, even if they do get swapped to disk after a while. ... No I haven't looked ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 0.7.9pre2
The only thing preventing FlightGear from compiling on FreeBSD is the missing gcvt function. Jon and I discussed it some yesterday and I sent him a fix that places the definition in FGJSBBase.h. Hopefully that has made it to him. I know it may be too late now to get it into 0.7.9 though. Mike: Can you send me the fix one more time, please? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Two more stray couts
In atis.cxx, line 163: cout cloudbase = cloudbase endl; This one can be commented out. And in runways.cxx, lines 84 and 124: cout index = index endl; should be either commented out or turned into an SG_LOG Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
Curtis L. Olson wrote: Thanks for everyone who has been beating on the 0.7.9 pre-releases. I have made the pre2 release available and am currently pushing it out to the mirrors (that I can push to.) Just a couple of tweaks between pre1 and pre2. Hey, should we bump up the release date and make a valentines release? Hmm, I have two issues: Ctrl+U gives an exception c310 doesn't work for me right now. If that get's fixed before I get up tomorow morning, you won't hear me for the rest of the day ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Time Offset Bug
Paul Deppe writes: Gents, With CVS as of 1200 EST, 2/13/2002, --time-offset does not work properly when used in conjunction with --start-date-whatever. For example: --start-date-gmt=2002:02:12:17:00:00 --time-offset=+01:15:00 ...starts up at 1/1/1970 1:15:00. As best as I can tell, these two options are incompatible. Each write's the specified value into /sim/startup/time-offset. There is a bug though because --start-date-gmt sets /sim/startup/time-offset-type to gmt, while --time-offset doesn't reset this back to system-offset which is the default. So, I will assert that this could have never worked as you had hoped, and perhaps before you were specifying the arguments differently or hadn't noticed that it wasn't working. Someone should probably take a look at the initial time specification code after 0.7.9 and clean a few things up. 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
[Flightgear-devel] Second pre-release Windows binary
I've put up a Cygwin compiled binary of the second 0.7.9 pre- release candidate up at: http://www.nottingham.ac.uk/~eazdluf/fgfs-win32-bin-0.7.9pre2.zip in case anyone with windows but without a compiler wants to test it. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] for the upcoming release
One of the original reasons for the preferences file (and heirarchy) is exactly Christian's point. Last time we had this discussion (or whatever you want to call it 8-) the conclusion was that the aircraft should either * Appear on the runway as though told to position-and-hold (which implies takeoff flaps setting, for example) and just waiting to apply power. * Appear in a parking area. For example, tiedown chains may be attached at that future time when we can simulate how an aircraft taxies like that. Each situation should correspond to a clear breakpoint between pages of the checklist. For the former, the checklist is closed, and for the latter, the pilot is just turning over from pre-takeoff to takeoff and (in the presence of an instructor) reading ahead a little bit to engine failure grin. Christian Mayer wrote: To the logical side: as long as the plane start *on* the runway it's IMO very unrealistical that the engine isn't running. Y'know, folks, this is actually a really (really) good point. :) There's nothing wrong with realism, but since we're cheating in the direction of expediency in so many places already, maybe it makes sense to make the expedient mode the default one. Maybe add a --pedantic switch, perhaps, to control the engnie start code for those who really want to do the engine start, and taxi, and runup, etc... Or maybe have a startup environment file along the same lines as the -set.xml aircraft files? The default one would put you on the runway with the engine going, ready for takeoff, but fancy ones would start you on the ramp with everything off. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 0.7.9pre2
Hmm, I have two issues: Ctrl+U gives an exception c310 doesn't work for me right now. Refresh my memory: what's wrong with the C310? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] for the upcoming release
Christian Mayer wrote: To the logical side: as long as the plane start *on* the runway it's IMO very unrealistical that the engine isn't running. Y'know, folks, this is actually a really (really) good point. :) Hilarious. That's right. Why would anyone be on the runway, ready to take off, with the engine off. Put the aircraft on the taxiway? ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
BERNDT, JON S. (JON) (JSC-EX) (LM) wrote: Hmm, I have two issues: Ctrl+U gives an exception c310 doesn't work for me right now. Refresh my memory: what's wrong with the C310? If you don't see the problem it might be a local compile problem. I'm recompiling from scratch right now and I'll see if i gets fixed. I realy wanted to say it because of the statement Curtis made ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C310
David M.: do you see a problem with the C310? I can't fly now - my big machine is in the shop. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fix for autopilot gui
Hi Curt, This is a three line fix for some inconsistancies between the gui dialogs and the panel controls for the autopilot. The heading dialog would only show the last setting you did through it, even if it was later tweaked with the bug on the hsi. The altitude dialog did a similar thing. Now the values default to the same that show on the panel displays. http://www.spiderbark.com/fgfs/autogui-021302.tar.gz Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] for the upcoming release
Curtis L. Olson wrote: What I've seen done in more advanced sims is for the operator gui to provide a set of positioning options such as: - at gate - position and hold - 3 mile final - 7 mile final - etc. Yup, that is what we should aim for. But for 0.7.9 we need a solution *now*. If that's enabled engines or a disabled engines + a big sign telling every newbie hoe to start the ending doesn't matter. But shipping 0.7.9 as it is currently will only result in additional work and bad comments. 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
Re: [Flightgear-devel] for the upcoming release
On Wed, Feb 13, 2002 at 12:43:05PM -0600, BERNDT, JON S. (JON) (JSC-EX) (LM) wrote: Hilarious. That's right. Why would anyone be on the runway, ready to take off, with the engine off. It happens - with multi-engine aircraft anyway. Some years ago a plane (747 I believe) taking off from Tokyo had trouble starting one of the engines. The captain said something to the effect, 'no problem. once we go to full power there will be plenty of air pressure to get the other engine started. They did start the engine as suggested and got partway down the runway before the first stage turbine (somewhere around 200lb spinning at 15000rpm!) literally fell out of the engine. It started digging a hole in the runway before taking off running. Every 10-20 feet it would hit the ground and take a divot out of the runway. Since the runway is built out into Tokyo Bay it soon hit the water. It is estimated that it went about 1/2 mile out, running on the water, before it finally sunk. It was never found. IIRC they had a light load and managed to take off. Be very happy when you hear the engines start up after they close the doors. They aren't wasting fuel, but letting the engine come to thermal equilibrium. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 0.7.9pre2
On Wed, 2002-02-13 at 09:05, [EMAIL PROTECTED] wrote: The only thing preventing FlightGear from compiling on FreeBSD is the missing gcvt function. Jon and I discussed it some yesterday and I sent him a fix that places the definition in FGJSBBase.h. Hopefully that has made it to him. I know it may be too late now to get it into 0.7.9 though. Mike: Can you send me the fix one more time, please? Sure. I've re-sent the patch. So hopefully this time it'll get to you. Cheers. Mike ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] C310
BERNDT, JON S. (JON) (JSC-EX) (LM) writes: David M.: do you see a problem with the C310? I can't fly now - my big machine is in the shop. It's OK, but I haven't tried a lot of long cross-countries. I haven't put much work into the prop model for the C310 compared to the C172 or C182, so I wouldn't be surprised if it's spinning out of control by producing excess power at high speed. A bigger problem is the C182. It has a strong tendency to pitch up in a power climb, even though most of the coefficients are identical to those in c172.xml. If people could look over the file and try to find the problem, I'd be very grateful (perhaps it's just the excess thrust from the more powerful engine). All the best, David -- David Megginson [EMAIL PROTECTED] ___ 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)
David Megginson wrote: If Curt and the rest of you hate this change, I'm happy to roll it back out, but I've been hearing some very strong arguments against putting 0.7.9 out with engines off by default and no arguments in favour. Since this is a config-file change rather than a change to the code base proper, I hope no one minds slipping it in. We can always reverse this after the release of 0.7.9, if wanted. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: C310
* David Megginson -- Wednesday 13 February 2002 21:15: It's OK, but I haven't tried a lot of long cross-countries. I haven't put much work into the prop model for the C310 compared to the C172 or C182, so I wouldn't be surprised if it's spinning out of control by producing excess power at high speed. You don't need high speed to crash the c310 instantly. Just push the nose down. And I don't agree that this is OK. m. :- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] for the upcoming release
* [EMAIL PROTECTED] (Curt Olson) [2002.02.13 12:51]: Alex Perry writes: One of the original reasons for the preferences file (and heirarchy) is exactly Christian's point. Last time we had this discussion (or whatever you want to call it 8-) the conclusion was that the aircraft should either * Appear on the runway as though told to position-and-hold (which implies takeoff flaps setting, for example) and just waiting to apply power. * Appear in a parking area. For example, tiedown chains may be attached at that future time when we can simulate how an aircraft taxies like that. Each situation should correspond to a clear breakpoint between pages of the checklist. For the former, the checklist is closed, and for the latter, the pilot is just turning over from pre-takeoff to takeoff and (in the presence of an instructor) reading ahead a little bit to engine failure grin. What I've seen done in more advanced sims is for the operator gui to provide a set of positioning options such as: - at gate - position and hold - 3 mile final - 7 mile final - etc. Perhaps after 0.7.9 we need to find someone to take a look at setting up these various preset positions. It would also be nice to be able to 'reset' yourself at any of these common positions at any time. I've been meaning to bring this up for a while, but I've always wondered why we don't have a --runway-id= option so we can choose which runway we start on. Just a thought... -- Cameron Moore / Why do people without a watch look at their \ \ wrist when you ask them what time it is? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
BERNDT, JON S. (JON) (JSC-EX) (LM) wrote: Hmm, I have two issues: Ctrl+U gives an exception c310 doesn't work for me right now. Refresh my memory: what's wrong with the C310? Alright, the c310 doesn't cause (a real?) problem at once (no long run tested though). About the Ctrl+U, this is still not working correctly but at least it doesn't halt the program with an exception. I'll leave it up to others if they think this is a show stopper. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] White stips in the scenery
Hi, I just wanted to let you know I almost completely elliminated the white spots in the scenery by explicitly telling the compiler *not* to optimize floating point opperations. This might be true for other compilers also. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
* [EMAIL PROTECTED] (Erik Hofman) [2002.02.13 12:31]: Curtis L. Olson wrote: Thanks for everyone who has been beating on the 0.7.9 pre-releases. I have made the pre2 release available and am currently pushing it out to the mirrors (that I can push to.) Just a couple of tweaks between pre1 and pre2. Hey, should we bump up the release date and make a valentines release? Hmm, I have two issues: Ctrl+U gives an exception Doh...that reminds me. The last time I flew FG (about a week ago), using Ctrl+U while not off the ground moved me horizontally instead of vertically in JSBSim. I seem to remember getting a bunch of gear touch messages, but, once again, I'm not 100% sure. If you can't reproduce this, let me know. Thanks -- Cameron Moore / If a man says something in the woods and\ \ there are no women there, is he still wrong? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Time Offset Bug
* [EMAIL PROTECTED] (Curt Olson) [2002.02.13 12:32]: Paul Deppe writes: Gents, With CVS as of 1200 EST, 2/13/2002, --time-offset does not work properly when used in conjunction with --start-date-whatever. For example: --start-date-gmt=2002:02:12:17:00:00 --time-offset=+01:15:00 ...starts up at 1/1/1970 1:15:00. As best as I can tell, these two options are incompatible. Each write's the specified value into /sim/startup/time-offset. There is a bug though because --start-date-gmt sets /sim/startup/time-offset-type to gmt, while --time-offset doesn't reset this back to system-offset which is the default. So, I will assert that this could have never worked as you had hoped, and perhaps before you were specifying the arguments differently or hadn't noticed that it wasn't working. Someone should probably take a look at the initial time specification code after 0.7.9 and clean a few things up. Regards, Curt. Curt, If the --time-offset option is incompatible with the other time options, we need to change options.cxx and the fgfs.1 man page to remove the can be used in combination with other time options lines describing --time-offset. 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] Re: C310
Melchior FRANZ [EMAIL PROTECTED] said: * David Megginson -- Wednesday 13 February 2002 21:15: It's OK, but I haven't tried a lot of long cross-countries. I haven't put much work into the prop model for the C310 compared to the C172 or C182, so I wouldn't be surprised if it's spinning out of control by producing excess power at high speed. You don't need high speed to crash the c310 instantly. Just push the nose down. And I don't agree that this is OK. m. :- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Melchior, What I'm seeing is that you have to hold the nose down for two or three seconds so that the plane goes into a dive. The values go whacky as soon as the craft hits that steep downward pitch, before it accelerates. Is that the same as what you get? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CTRL+U and JSBsim
Just wondering if we should comment out the binding for this since it still doesn't work with the default FDM. Best, JIm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
Martin van Beilen writes: Whoa there! I didn't even have the opportunity to try pre1 yet. Anyway, this is my first try since the FlightGear-2.7.8 release. Build status: Success Processor:Intel Pentium II 233 MHz Graphics Card:the venerable Voodoo2 OS: RedHat Linux 7.2 (w/ updated gcc) OpenGL: Mesa 4.0.1 (compiled from tarball) PLIB: 1.4.2 Unfortunately, the problem I had with 2.7.8 is still there. (0.7.8) :-) Whenever the moon enters view, the cloud layer becomes extremely bright, the intrument panel becomes tranlucent, and a large white rectangle covers most of it. http://www.iradis.org/gallery/fgfs-screen-014.jpg Switching to the small translucent panel keys/key gets rid of the large rectangle and leaves the instruments readable. It still looks weird though. Strangely enough this doesn't happen to me when flying in the States, so you might want to try with - --airport-id=EHAM. (That's Amsterdam Schipol, the Netherlands, Europe, for non-flying folks.) This sounds a lot like it could be a driver issue. Or we could be running out of texture ram and your driver isn't behaving well (not many handle this situation well.) I am currenty doing a complete rebuild and logging the configure and make output. I also removed every trace of metakit and SimGear to be absolutely certain that I compile against the correct libs. I'll keep you posted. In the process I found one small glitch: [mvb@localhost SimGear-0.0.17pre2]$ ./configure lots of stuff Metakit not found, you will need to install this first. Please read the README.metakit for more information. However, there is no README.metakit in the distribution. (And yes, I know metakit is no longer part of SimGear.) Ahhh, good catch, I'll add that and README.zlib to the next distribution. 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: Engines start at idle (was Re: [Flightgear-devel] for the upcoming release)
David Megginson writes: I am convinced that we're best off starting with the engines idling rather than off, since our default start is always on a runway (even if you specify a different airport). No C++ code changes are necessary, other than a small bug-fix to JSBSim.cxx; I've just changed some properties in the default settings for the c172, c182, and c310 so that they now all start at an idle (you'll note that the C-310's idle is too high, but we'll have to fix that after 0.7.9). If Curt and the rest of you hate this change, I'm happy to roll it back out, but I've been hearing some very strong arguments against putting 0.7.9 out with engines off by default and no arguments in favour. Since this is a config-file change rather than a change to the code base proper, I hope no one minds slipping it in. I'm not entirely sure I like it, but I acknowledge that starting on the runway with engines off is not very realistic. We do need to make sure that proper engine start modeling doesn't get lost because no one is testing it anymore ... Hopefully after 0.7.9 is out someone will take it upon themselves to create several default positioning options. I think all the pieces are there, it's just a matter of assembling them in the right order. 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] for the upcoming release
Cameron Moore writes: I've been meaning to bring this up for a while, but I've always wondered why we don't have a --runway-id= option so we can choose which runway we start on. Just a thought... It's a good thought, please submit patches / additions to impliment this option at any time. :-) It will have to go into the code after 0.7.9 though. 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] for the upcoming release
On Wednesday 13 February 2002 11:23 am, you wrote: Jim Wilson writes: This is what I'm getting: http://www.spiderbark.com/fgfs/dc3-leaving-bangor.png http://www.spiderbark.com/fgfs/dc3-on-runway.png Does it look like the mapping is off on the right wing? Yes, it is. I had a lot of trouble UV-mapping to a duplicated, flipped object. The problem's fixed in my local copy (which also has a lot of triangle-reduction, thanks to Blender's Decimator, and also needs to be re-UV-mapped), but I'm going to hold off on uploading that until after 0.7.9final. Thanks for the screenshot -- the Voodoo3 isn't looking that bad. All the best, David This is *great* news. This combined with Jim's patch for texture tiling on panel backgrounds pushes us over the hump to have really nice looking panels, etc. On that note... David, do you have the source files for your instruments? I'd like to have a CVS module for the postscripts at least, so that we can regenerate fresh copies and go with 1 instrument per texture. TTYL John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 0.7.9pre2
On Wed, 2002-02-13 at 09:05, [EMAIL PROTECTED] wrote: The only thing preventing FlightGear from compiling on FreeBSD is the missing gcvt function. Jon and I discussed it some yesterday and I sent him a fix that places the definition in FGJSBBase.h. Hopefully that has made it to him. I know it may be too late now to get it into 0.7.9 though. Mike: Can you send me the fix one more time, please? Sure. I've re-sent the patch. So hopefully this time it'll get to you. Where is it? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: C310
From: Jim Wilson [EMAIL PROTECTED] [...] Melchior FRANZ [EMAIL PROTECTED] said: Sorry from this strange heading - as I'm reading this list from my news server I am posting from 'tin' You don't need high speed to crash the c310 instantly. Just push the nose down. And I don't agree that this is OK. What I'm seeing is that you have to hold the nose down for two or three seconds so that the plane goes into a dive. The values go whacky as soon as the craft hits that steep downward pitch, [...] You mean as soon as the craft hits the ground . Right ? ;-)) This is exactly what I'm experiencing. I was surprised that such a small twinmot is that difficult to fly :-) 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] CTRL+U and JSBsim
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 ... 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
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, 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] CTRL+U and JSBsim
Jim Wilson writes: Just wondering if we should comment out the binding for this since it still doesn't work with the default FDM. I does work, but not when the plane is still and on the ground. That's because of a new on-ground property that JSBSim uses. Try starting in flight: fgfs --altitude=5000 --vc=100 then use Ctrl-U, and it should work as expected. 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] for the upcoming release
John Check writes: On that note... David, do you have the source files for your instruments? I'd like to have a CVS module for the postscripts at least, so that we can regenerate fresh copies and go with 1 instrument per texture. Yes, I have. They're in TGIF's native format, but I can export PostScript if you'd like. Let me know what to send. 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] for the upcoming release
On Wednesday 13 February 2002 01:24 pm, you wrote: Christian Mayer wrote: To the logical side: as long as the plane start *on* the runway it's IMO very unrealistical that the engine isn't running. Y'know, folks, this is actually a really (really) good point. :) There's nothing wrong with realism, but since we're cheating in the direction of expediency in so many places already, maybe it makes sense to make the expedient mode the default one. Maybe add a --pedantic switch, perhaps, to control the engnie start code for those who really want to do the engine start, and taxi, and runup, etc... --props:/sim/pedantic=true and have a conditional in the set file (do conditionals work outside the panel code?) to load a scenario where the plane is parked Or maybe have a startup environment file along the same lines as the -set.xml aircraft files? The default one would put you on the runway with the engine going, ready for takeoff, but fancy ones would start you on the ramp with everything off. Andy The only thing I see thats a problem (barring conditionals not working outside panel code), is that we'd need a scenario for every airport, unless we can pull an appropriate point on the taxiway automatically. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] for the upcoming release
John Check writes: There's nothing wrong with realism, but since we're cheating in the direction of expediency in so many places already, maybe it makes sense to make the expedient mode the default one. Maybe add a --pedantic switch, perhaps, to control the engnie start code for those who really want to do the engine start, and taxi, and runup, etc... --props:/sim/pedantic=true I disagree. We're not talking about pedantry (or realism) here, but rather, the starting scenerio: on the runway with the engine running, or parked with the engine off. Since we don't have a generic way to specify the parking location for every airport, it makes sense to default to the former. For 0.8.0, as John and Curt have suggested, it will be nice to have a lot of canned startup scenarios (perhaps in an $FG_ROOT/Scenarios directory), like the canned aircraft config files, and some of those can start the plane parked with the engine off. 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] for the upcoming release
John Check writes: There's nothing wrong with realism, but since we're cheating in the direction of expediency in so many places already, maybe it makes sense to make the expedient mode the default one. Maybe add a --pedantic switch, perhaps, to control the engnie start code for those who really want to do the engine start, and taxi, and runup, etc... --props:/sim/pedantic=true I disagree. We're not talking about pedantry (or realism) here, but rather, the starting scenerio: on the runway with the engine running, or parked with the engine off. Since we don't have a generic way to specify the parking location for every airport, it makes sense to default to the former. For 0.8.0, as John and Curt have suggested, it will be nice to have a lot of canned startup scenarios (perhaps in an $FG_ROOT/Scenarios directory), like the canned aircraft config files, and some of those can start the plane parked with the engine off. 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] for the upcoming release
John Check writes: There's nothing wrong with realism, but since we're cheating in the direction of expediency in so many places already, maybe it makes sense to make the expedient mode the default one. Maybe add a --pedantic switch, perhaps, to control the engnie start code for those who really want to do the engine start, and taxi, and runup, etc... --props:/sim/pedantic=true I disagree. We're not talking about pedantry (or realism) here, but rather, the starting scenerio: on the runway with the engine running, or parked with the engine off. Since we don't have a generic way to specify the parking location for every airport, it makes sense to default to the former. For 0.8.0, as John and Curt have suggested, it will be nice to have a lot of canned startup scenarios (perhaps in an $FG_ROOT/Scenarios directory), like the canned aircraft config files, and some of those can start the plane parked with the engine off. 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] for the upcoming release
John Check writes: There's nothing wrong with realism, but since we're cheating in the direction of expediency in so many places already, maybe it makes sense to make the expedient mode the default one. Maybe add a --pedantic switch, perhaps, to control the engnie start code for those who really want to do the engine start, and taxi, and runup, etc... --props:/sim/pedantic=true I disagree. We're not talking about pedantry (or realism) here, but rather, the starting scenerio: on the runway with the engine running, or parked with the engine off. Since we don't have a generic way to specify the parking location for every airport, it makes sense to default to the former. For 0.8.0, as John and Curt have suggested, it will be nice to have a lot of canned startup scenarios (perhaps in an $FG_ROOT/Scenarios directory), like the canned aircraft config files, and some of those can start the plane parked with the engine off. 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] CTRL+U and JSBsim
Curtis L. Olson writes: 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 ... Personally, I'd like to provide a way to switch to slew (magic carpet) mode dynamically, then back to the current FDM. That will involve using a current_fdm stack. 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] CTRL+U and JSBsim
David Megginson writes: Curtis L. Olson writes: 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 ... Personally, I'd like to provide a way to switch to slew (magic carpet) mode dynamically, then back to the current FDM. That will involve using a current_fdm stack. It would be nice to be able to save the important current fdm state variables and reinitialize with any new aircraft or fdm+aircraft with those as input, then call the trimming routine, and be on our way. This would allow us a lot of 'reset' functionality. Reset to a specific location, reset to a new aircraft, etc. But, we should probably be concentrating more on 0.7.9 this week if possible. :-) 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: Engines start at idle (was Re: [Flightgear-devel] for the upcoming release)
Curtis L. Olson writes: David Megginson writes: I am convinced that we're best off starting with the engines idling rather than off, since our default start is always on a runway (even if you specify a different airport). No C++ code changes are necessary, other than a small bug-fix to JSBSim.cxx; I've just changed some properties in the default settings for the c172, c182, and c310 so that they now all start at an idle (you'll note that the C-310's idle is too high, but we'll have to fix that after 0.7.9). If Curt and the rest of you hate this change, I'm happy to roll it back out, but I've been hearing some very strong arguments against putting 0.7.9 out with engines off by default and no arguments in favour. Since this is a config-file change rather than a change to the code base proper, I hope no one minds slipping it in. I'm not entirely sure I like it, but I acknowledge that starting on the runway with engines off is not very realistic. I think its probably for the best, certainly for 0.7.9, if only because the obvious way to work the magnetos - left mouse clicking round and then holding down for the starter - doesn't work yet, and the full set of items to check isn't done yet anyway, such as master power and fuel selector switches. We will undoubtably get a lot of how? posts from users if we leave the engines unstarted, especially as we don't currently have a checklist that can be brought up from the menu. Of purely historical interest, ProPilot99 started on the runway with engines off. I hated it at first, since I was used to MSFS and had to actually read something to get in the air! However, once I got used to the sequence and managed to remember it I liked the fact that it had forced me to learn it. We do need to make sure that proper engine start modeling doesn't get lost because no one is testing it anymore ... I'll still be testing it :-) Cheers - Dave -- [EMAIL PROTECTED] ___ 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 Update: I deleted, rebuilt and re-installed fgfs-base-0.7.9pre2, metakit-2.4.2-32 (included tarball from SimGear), SimGear-0.0.17pre2 and FlightGear-0.7.9pre2 from scratch. Build logs are available on request. Unfortunately my problem persists, and my assertion that it doesn't occur in the USA was wrong. I can reliably reproduce it with: fgfs --start-date-gmt=2002:02:27:15:00:00 --disable-clouds --disable-sound Which immediately yields the following result: http://www.iradis.org/gallery/fgfs-screen-015.jpg Any clues? PS: Rest assured that I'm not writing to you from the future and I'm not actually using FlightGear major version 2. That was just a snafu on my part. :) - -- Regards, I RADIS, do you? =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen [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:33:36PM +0100 X-S-Issue: [EMAIL PROTECTED] 2002/02/13 22:59:41 d5bfa51141621e4defec43793f92b0dc X-S-Issue: [EMAIL PROTECTED] 2002/02/13 23:10:48 2e483c875b6b54198a3a42f416b1471c -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjxq5G8ACgkQN880WP6HRIs1VQCeMzE27P++eKqnnUT5WdSAvXjS TPUAoLVKhGDl9/KKUf9yaq1g+tRKCn7j =nHrA -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9pre2
Martin van Beilen writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Update: I deleted, rebuilt and re-installed fgfs-base-0.7.9pre2, metakit-2.4.2-32 (included tarball from SimGear), SimGear-0.0.17pre2 and FlightGear-0.7.9pre2 from scratch. Build logs are available on request. Unfortunately my problem persists, and my assertion that it doesn't occur in the USA was wrong. I can reliably reproduce it with: fgfs --start-date-gmt=2002:02:27:15:00:00 --disable-clouds --disable-sound Which immediately yields the following result: http://www.iradis.org/gallery/fgfs-screen-015.jpg Any clues? PS: Rest assured that I'm not writing to you from the future and I'm not actually using FlightGear major version 2. That was just a snafu on my part. :) From your image, it really looks like you may have a driver bug. Do you know if there is a more recent version of your voodoo2 driver available to install? How much memory does your voodoo2 have? 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] for the upcoming release
On Wednesday 13 February 2002 04:49 pm, you wrote: John Check writes: On that note... David, do you have the source files for your instruments? I'd like to have a CVS module for the postscripts at least, so that we can regenerate fresh copies and go with 1 instrument per texture. Yes, I have. They're in TGIF's native format, but I can export PostScript if you'd like. Let me know what to send. All the best, David I can deal with TGIF, or Postscript, or both. Whatever you got. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[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. 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] CTRL+U and JSBsim
Jim Wilson writes: Hmmm...that does work, but I'm talking about in flight after starting on the ground. Using it while in flight seems to put the plane on the ground instantly (throws an exception or something). 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). 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] CTRL+U and JSBsim
On Wed, 2002-02-13 at 14:59, David Megginson wrote:
Jim Wilson writes:
Hmmm...that does work, but I'm talking about in flight after starting on the
ground. Using it while in flight seems to put the plane on the ground
instantly (throws an exception or something).
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.
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)
David Megginson [EMAIL PROTECTED] said: I am convinced that we're best off starting with the engines idling rather than off, since our default start is always on a runway (even Is there a way to set the parking brake at startup so that the plane doesn't roll down (or off) the runway as soon as it loads? I tried a couple things and they didn't work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: KSFO ATIS
David Megginson wrote: 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 think that's great as it shows the users a feature they normally wouldn't see (unless they'd know how to get it the first place) So I vote for keeping it. 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
re: [Flightgear-devel] CTRL+U and JSBsim
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)?
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] CTRL+U and JSBsim
Tony Peden [EMAIL PROTECTED] said:
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.
Ah...one more thing. When it does this jbssim reports that it's setting the
correct altitude, then it goes to the same elevation as the starting position
(just doesn't change the long/lat). Then it seems if you aren't in the right
place it crashes with a Fatal error: Tile not found, attempting to schedule
tiles for a bogus long/lat.
This link below is the output from such an event. It appears that the ground
level at the location where the program crashed was actually 539ft or about
200-300 feet higher than the initial altitude at take-off. Not sure if I'm
reading this right, but maybe you can see something here:
http://www.spiderbark.com/fgfs/ctrlubug.txt
Best,
Jim
___
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 04:19:00PM -0600, Curtis L. Olson wrote: From your image, it really looks like you may have a driver bug. Yes, that is indeed likely. However, it doesn't appear to be a memory issue. The problem is very specifically triggered by the moon entering the active view. I have flown fgfs far and wide with --disable-skyblend, which works just fine. No moon, no problem. So what I'd like to know is what's so special about that moon. I tried running with --disable-textures, same result. (But this option doesn't affect moon texturing.) Do you know if there is a more recent version of your voodoo2 driver available to install? Do you know how hard it is to _find_ a voodoo2 driver these days? 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.) How much memory does your voodoo2 have? Hard to tell. It was a gift, and I have no idea how to probe it. These cards usually have 8 megs, or if I'm lucky, 12. - -- 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 04:19:00PM -0600 X-S-Issue: [EMAIL PROTECTED] 2002/02/14 02:21:52 e212f6d2444ae9e045cf1944d20c9c7a -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjxrETcACgkQN880WP6HRIvXFwCgryryM0XiL5aUPmY8I3yJYyX1 3m4An2Rs4MYt8daVexWUUtJlXwbesTcU =c//5 -END PGP SIGNATURE- ___ 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 04:19:00PM -0600, Curtis L. Olson wrote: From your image, it really looks like you may have a driver bug. Yes, that is indeed likely. However, it doesn't appear to be a memory issue. The problem is very specifically triggered by the moon entering the active view. I have flown fgfs far and wide with --disable-skyblend, which works just fine. No moon, no problem. So what I'd like to know is what's so special about that moon. Have a look at the moon rendering code in simgear if you like, but the moon is using a blend mode other than the default blend mode so that we can blend it into the gradient sky. I wouldn't be surprised if your driver doesn't handle all the blend modes correctly. It's off the beaten path, but not by a lot. I tried running with --disable-textures, same result. (But this option doesn't affect moon texturing.) I don't think it is a texturing issue from what you have said. Do you know if there is a more recent version of your voodoo2 driver available to install? Do you know how hard it is to _find_ a voodoo2 driver these days? 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. I personally have very few complaints about my nvidia card. 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] Pre-release windows binary
Jon S. Berndt 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. I remember this happening to me over a period of a couple months about a year ago. Eventually I upgraded my video card. In your case this doesn't sound right or good. Something is wrong. I wish I could try it too but my machine is still in the shop. I hope it's not something in JSBSim, but I don't see what it could be. Was the binary compiled --with-logging or --without-logging? That unfortunately can have a large negative impact on windows performance. 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] 0.7.9pre2
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [2002.02.13 20:45]: On Wed, Feb 13, 2002 at 04:19:00PM -0600, Curtis L. Olson wrote: How much memory does your voodoo2 have? Hard to tell. It was a gift, and I have no idea how to probe it. These cards usually have 8 megs, or if I'm lucky, 12. Look through /var/log/XFree86.0.log to see if the X driver tells you. Might also try snooping around in /proc. -- Cameron Moore [ Why are there 5 syllables in the word monosyllabic? ] ___ 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)
Curtis L. Olson writes: I would think that if we are going to have the engine running at startup, we really should have either the parking brake set, or the sim come up paused/frozen. Perhaps, but if we get the idle speeds reasonable, it won't be too bad. Having the brakes on by default would be a bad thing, since first-time users might have trouble figuring out how to release them. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] httpd null entry bug
Sorry I don't have time to track this down right now, but the httpd interface shows a null () entry when viewing the root path. It even presents you with a page to change null's value (supposedly). Could someone look into fixing this? Thanks -- Cameron Moore / What do you do when you see an endangered \ \ animal that eats only endangered plants? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-release windows binary
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 ... ___ 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 ... Is it dumping a lot of console output when it runs? 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 windows binary
Alex Perry writes: Dunno. It was the pre2 prebuilt binary from the Nottingham server ... Curt asked: Is it dumping a lot of console output when it runs? It was dumping at least the first dozen screenfuls that I'm used to seeing under Linux ... then I minimized the batch file's window. That probably doesn't help and I'm not near that machine right now - sorry. ___ 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: David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: I would think that if we are going to have the engine running at startup, we really should have either the parking brake set, or the sim come up paused/frozen. Perhaps, but if we get the idle speeds reasonable, it won't be too bad. Having the brakes on by default would be a bad thing, since first-time users might have trouble figuring out how to release them. True, but for that matter first time users might have trouble figuring out how to open the throttle :-) Sounds like we need to organize a focus group. :-) I'm worried though that if the new user goes scooting off down the runway at 40 knots before they get a chance to focus in on what is going on, that will leave a negative impression just as much as starting with the engine off or anything else that diverges significantly from the 'expected'. We always manage to save a few glaring wart suprises for the final release so maybe we'll just have to live with whatever we end up with here? 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: Engines start at idle (was Re: [Flightgear-devel] for the upcomingrelease)
On Thursday 14 February 2002 12:32 am, you wrote: Jim Wilson writes: David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: I would think that if we are going to have the engine running at startup, we really should have either the parking brake set, or the sim come up paused/frozen. Perhaps, but if we get the idle speeds reasonable, it won't be too bad. Having the brakes on by default would be a bad thing, since first-time users might have trouble figuring out how to release them. True, but for that matter first time users might have trouble figuring out how to open the throttle :-) Sounds like we need to organize a focus group. :-) I'm worried though that if the new user goes scooting off down the runway at 40 knots before they get a chance to focus in on what is going on, that will leave a negative impression just as much as starting with the engine off or anything else that diverges significantly from the 'expected'. We always manage to save a few glaring wart suprises for the final release so maybe we'll just have to live with whatever we end up with here? Curt. I could bind a toggle for the brakes to the indicator. I think it's fairly likely somebody might click on it ___ 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 upcomingrelease)
Sounds like we need to organize a focus group. :-) Yeah, that's what the conferences are for ... to _prove_ to the doubting new users that the simulator does actually work ... I'm worried though that if the new user goes scooting off down the runway at 40 knots before they get a chance to focus in on what is going on, that will leave a negative impression just as much as starting with the engine off or anything else that diverges significantly from the 'expected'. Oh, I don't know. Given the number of real aircraft that take off with pieces missing (like ailerons or rudder or the pilot) or unwanted pieces (like the towbar or the tiedown chain); having the plane quickly take off completely on its own, before the user has a chance to do anything to confuse things, at least proves to the user that the simulation is working. Perhaps we should have it start up with the engine at full power, and two notches of right rudder installed using the keyboard (i.e. it will stay that way until they touch the joystick) ? I used to need four notches of up-elevator on LaRCsim, but (from memory) the autotrim on JSBSim avoids even that chore. This (a) makes show demonstrations easier (b) enhances the experience for the younger community and (c) can be explained to veteran pilots as the expedited departure method. After some thought, I recommend this for the 0.7.9 release. ___ 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 upcomingrelease)
I could bind a toggle for the brakes to the indicator. I think it's fairly likely somebody might click on it Good idea, in any case. However, instead of setting the brakes, how about configuring the weather to have non-zero wind directly down the runway, just enough to keep the aircraft from rolling forward with the throttle at idle ? It also makes the takeoff roll shorter for the impatient, and provides veteran users with a crosswind challenge on the north-south runways without any reconfiguration effort. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBsim C310 crashes the sim on gear retraction.
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! ___ 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.
That's the same error I have on the C172 at simulator startup. FYI. 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! ___ 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] JSBsim C310 crashes the sim on gear retraction.
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
