Re: [Flightgear-devel] Anyone likes helping with italian scenery?
On Wed, 25 May 2005 23:01:52 +0200 Frederic Bouvier wrote: > > > No kidding, you are the first to show a convincing scenery enhancement > without using photo-scenery. > Generic textures are not dead ;-) At one point, I used fgsd to do what I thought was some nice work in the Washington, D.C. area as preparatory to laying out ground structures I had done or was going to do. The course of the Potomac River is about 500m from its correct location in the FG scenery as is, so I fixed that, changed material settings for various ground triangles, made some "inlet" areas that didn't exist in the FG scenery, etc. It looked nice, I thought. And KDCA no longer sat on a table that hovered out in the middle of nowhere like it previously did (and does now). Then a new version of the FG scenery came out, and one of its big advantages was a fix to a bug which occasionally produced sharp steps in ground elevation where the ground should slope more smoothly. This was significant because this bug had made the main runway at KDCA unusable because of a sharp step in the middle. I went with the new scenery, getting full access to the runway; but I lost the terrain changes I'd done with fgsd in the process. I haven't re-done them since, out of fear that I'd either have to throw them out again with the next FG scenery set, OR would keep them and at the very least have odd artifacts around the tile edges where one transitions from old scenery tile to the new stuff (and of course miss out on any improvements to the scenery generation algorithms that would have impacted the tile(s) in question). I think fgsd is cool, and I really enjoy playing with it; but if I had the infinite amount of free time all of us wish we had, I'd work on TerraGear drawing its info from some kind of GIS, and implementing some way (in fgsd and/or other tools) to update that info, so that "fixes" to the terrain could propagate upstream and be included in future scenery builds, removing the need to fix the terrain over and over and over. I know, I know, we've all talked about this before, and pretty much everyone thinks its a good idea, and no one has the time. I really really wish I did. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgporAeJM6Gm2.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGInterface is beeing called without scenery below the aircraft
On Mon, 16 May 2005 10:16:35 +0100 Jon Stockill wrote: > > Mathias Fröhlich wrote: > > Hi, > > > > Can you reproduce this? > > And, if yes, how? > > I can confirm this problem - it's rare, and I haven't been able to track > > down why it's happened, but the sim freezes in the same way as when the > aircraft is crashed - the few times I've seen this the aircraft has been > > at a few thousand feet, with nothing to crash into though. Yeah, I had this happen to me last night for the very first time while on approach to KSFO. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpm70noDLNCE.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Dialog problem
On Sun, 15 May 2005 17:28:25 +0200 Melchior FRANZ wrote: > > * Frederic Bouvier -- Sunday 15 May 2005 17:12: > > I didn't follow the property problem closely, so this may be related, > > but this is what I am getting today : > > Yes, that's exactly what we talked about. A quick fix is in the thread > that you didn't follow closely. Ah, OK, looks like a solution to this of the two bugs I posted about in the 3d clouds thread is already in the works. Never mind. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp64QZ8d2FIb.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Sun, 15 May 2005 16:21:52 +0200 Melchior FRANZ wrote: > > This is extremely impressive. Very well done, not only the clouds > (fading in in the distance!; brighter?), but also lightning and rain. > (BTW: we could extract some more lightning info from metar IIRC, such as > lightning frequency; I didn't do this before, because we had no use for > it). It's been gorgeous stuff so far. Does it solve the two most noticeable bugs I've seen: - static 3d ground objects seen through the clouds with unlimited visibility distance? - after having viewed menus like the Autopilot or Rendering Options menus once normally, and then having flown around for a while, bringing them up again causes them to appear in the lower left hand corner, partially off-screen, unmoveable, and transparent? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpZFjau0ZEiU.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] City signs
On Sat, 14 May 2005 14:04:17 +0200 Paul Surgeon wrote: > > A better way would be to generate the textures dynamically at runtime. > Dynamic scenery in FG ... I must be smoking grass seeing as we can't > even do multitexturing yet. I suppose you'll be working on that, then. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpRjnNhimpTC.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in theHimalayas
On Tue, 03 May 2005 23:59:15 +0200 Paul Furber wrote: > > Flying WNW towards the summit in the Cessna. How in the world did you get the Cessna up there! -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp01G1H2JOMu.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Weather - Clouds
On Sun, 17 Apr 2005 20:32:13 +0200 Harald JOHNSEN wrote: > > I did some research on 3D clouds for some time and finaly got something > not too bad. I've started to add that to SimGear this week end, here are > > the first alpha screen shots : > > http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-011.jpg > http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-013.jpg Good work! My compliments. > I have alse some code nearly ready for rain, snow and lightnings. I await stuff to try with baited virtual breath! Cool. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp730ntEMSG3.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] World Wind as moving map display
On Sun, 17 Apr 2005 06:02:53 +0200 Arnt Karlsen wrote: > On Sat, 16 Apr 2005 15:16:13 +0200, Roy wrote in message > <[EMAIL PROTECTED]>: >> >> Hi all! >> >> I've whipped together a python script that reads position from >> FlightGear and instructs World Wind to goto that position. A couple >> of screenshots show just how accurately the FlightGear scenery and >> the World Wind images correspond. >> >> http://82.164.122.241/~royvegard/ >> >> I stripped down the playback.xml generic protocol into a new one >> called ww.xml. The new one only outputs position and orientation. >> FlightGear ran on a linux box sending the data to a winXP box with >> World Wind and my simple python socket reader running. > > ..hey, hang on a sec here, you're competing _against_ GPL > http://earth3d.org/ (http://earth3d.org/faq.html) and favoring > Wintendo-only http://worldwind.arc.nasa.gov/ !!! ;o) So I guess you'll be working on getting a GPL'd, general-use option available. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgphSoFUpTdNm.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear version 9.2 Help Request
On Wed, 16 Feb 2005 21:11:13 +0200 Paul Surgeon wrote: > > No, the xml files are used to change attributes of models (animations, > visual range, scale, etc) > > Here is a quick rundown on how to add a shared model to the current > version of FlightGear - I'm not sure if this is applicable to 0.9.2 > since I never ran that version and wouldn't have remembered anyway. :) [ snip ] > Step 2 : > Inside the data/Models/MyModels drirectory create an xml file called > foomodel.xml with the following contents : It's worth noting that you don't *have* to create an .xml file. The entry in the *.stg file can refer to a model file (e.g. foomodel.ac or foomodel.3ds) rather than an .xml file (e.g. foomodel.xml). You probably *want* to use an .xml file, with the .xml file containing the model filename, as noted here, because then you get all the additional bells and whistles possible through the .xml file. But you don't *have* to do it that way. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpcWJXRIfPb7.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
On Mon, 31 Jan 2005 23:37:49 +0100 Frederic Bouvier wrote: > > That's really nice ! > But if all these models are placed automagically, what would happen to > model that represent the real buildings ? I mean : if I create the > Empire State Building and put it in fgfsdb, would there be a hole around > > it or would it be in collision with its generic clone ? It already > happens at SFO with the radio towers and they need to be removed > manually. Yeah, the plan is that when a "correct" model for a bldg gets added to the DB, the entry in the DB for the generic building would get removed at that time. That should be straightforward to do, and not very demanding since the rate at which stuff gets added isn't huge. Since the DB is browseable, someone adding specific structures could make life easier by noting "delete the generic bldg at _" when adding their specific one. Radio towers are another matter. One of the original goals of this exercise with the DOF was in identifying which towers in the scenery are most likely buildings with antennae on the top, so that those towers aren't placed in the scenery to begin with (so removing them manually, like you've done with SF, wouldn't be necessary -- they wouldn't be placed there to begin with). That's what I was referring to when I said there's still stuff to work out about the radio towers. I have code that compares the FCC and FAA databases and tries to identify likely counterparts within stated positional uncertainties, but I'm still tweaking it. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpn5Td3SXg4t.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Fun with the FAA DOF.
With building positions and heights from the FAA Digital Obstruction File, and a few new buriable (thus, height-adjustable) models, here's an approach into La Guardia Rwy 04, starting over Staten Island. http://www.speakeasy.org/~cmetzler/KLGA_04_approach_001.jpg thru http://www.speakeasy.org/~cmetzler/KLGA_04_approach_023.jpg Some highlights: lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg over downtown brooklyn, show detail on some of the models -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_010.jpg view of midtown manhattan -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_011.jpg adjusting to final with manhattan in background -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_015.jpg over the tarmac, manhattan in the distance -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_021.jpg The plan is for the models to go into Jon Stockill's model database, and for the DOF data to go in there too, once some stuff about radio towers gets worked out. Then the downloadable scenery adds will include tall buildings, smokestacks, and other things. Other than the radio tower stuff, my main holdup is getting the models to look nicer. The way I'm proceding for the generic tall building models: I have a set of Blender models, all meters tall, with cross-sections of 50m square, 60m square, 60m quare with a 5m/side right triangle taken out of the corners, 30m x 60m, 25m radius circle, etc. I am in the process of making small (typically 32x32, sometimes 64x64, rarely 128x128) textures of building sides, typically tiny sections cropped from photos and then processed in the Gimp. My plan is to mix and match these to create a very wide variety of buildings that can be drawn from randomly when the .stg files are created. I'm not yet happy with the way most of them look. Some of them have alignment issues with horizontal/vertical features on the texture tiles that I thought I'd fixed, but haven't really. Some look very good close up, but from a distance look like odd solid color blocks. Most need roofs. None have hazard lights. And there will be more of them. So this isn't ready yet. But the pics should give an idea of how this can go. Re: frame rates. You can see the frame rates I was getting in the lower-right-hand corner. This is with a Gf4 Ti4600, but at 1600x1200. I did this approach again without the buildings in the scene, and got framerates that were 1-4 fps larger. And Manhattan is a worst-case scenario. So I don't think framerates are going to be much of a problem. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpq2gk8suAuy.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway distance remaining signs + placement script "done".
On Sat, 29 Jan 2005 11:06:04 +0100 Erik Hofman wrote: > > I finally got time (or actually made some time) too look at this. > I was wondering, wouldn't it be saner to make only textured, > single-sided polygons (two triangles) containing the numbers (blank, > 1-16) and put two of these objects (back-to back) at the specific > location instead of creating 152 models? Yes, it would, and I don't know why I didn't think of that. It's a trivial change to make; I should be able to do it today or tomorrow. Thanks. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpUwSbolgAKt.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please use meaningful subject lines
On Tue, 25 Jan 2005 12:13:49 +0200 Paul Surgeon wrote: > > But that breaks the message threading capabilites of mail readers which > some people dislike. > One ends up with 2 or 3 threads on the same topic and you have to jump > between them. Most mailreaders these days thread not on the subject, but on the References: or In-Reply-To: headers or stuff like that. But out of consideration to ones that thread on Subject:, one can solve this the way Usenet folks have for ages -- use the "was:" convention. e.g. given a thread with subject Subject: fgrun improvements when someone in the thread starts to discuss lighting, they can change the subject line to Subject enhanced lighting fps (was: fgrun improvements) If *that* isn't enough, then we're talking about trying to accomodate bugged/broken mail readers. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgptEOjQgAuo5.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] B1900D FDM (Test pilots req'd)
On Wed, 19 Jan 2005 21:34:24 -0600 Curtis L. Olson wrote: > > The model was updated to work with FlightGear-0.9.8 and plib-1.8.4. Sigh . . .I should really subscribe to the CVS log mailing list. I thought I was current; but I wasn't 11 hours current. Thanks for the tip. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpyhdtUuI3Tk.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] B1900D FDM (Test pilots req'd)
On Thu, 20 Jan 2005 00:16:07 + Dave Martin wrote: > > Let me know what you think :-) > > FDM: http://www.cyfinity.com/fgfs/b1900d.xml - copy to your > Aircraft/b1900d/ directory after backing up the original. Hi Dave. It appears to be a lot more stable (and as a note to Syd -- the model itself is gorgeous, especially the cockpit). But I can't check your numbers because I'm running into the "transparent gauge" problem that also afflicted the dhc2F. Where the gauges should be, I see right through to the runway. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpR1PKhvBJPN.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Wed, 19 Jan 2005 20:57:13 -0500 David Megginson wrote: > > In combination with this change, I'd like us to start thinking about > changing the starting airport to Palo Alto (KPAO) rather than KSFO. > It's more in proportion with the C-172, and with a few buildings, > etc., we could have it looking quite nice. A few minutes after taking > off from there and flying in a straight line, a new user will pass > over KSFO, which will be more exciting to look at from the air, and > then San Francisco, adding a nice sense of discovery. I agree with this, except I might suggest KSQL instead of KPAO, for three minor reasons. One is that we have a set of new user docs, designed to teach the basics of flight and flying the circuit in the c172, that come with the release; they presume that you started at KSQL. The second is that KSQL is closer to KSFO, and the Oracle buildings and Dunbarton bridge are very nearby, so there's quicker aesthetic gratification. Finally, KSQL and KPAO both need work as far as their taxiway layouts are concerned; but KSQL's will come from TaxiDrawers more quickly because KPAO's main apron area is circular and enclosed by a circular taxiway. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp5wcIvQw7ld.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wed, 19 Jan 2005 21:38:18 + Dave Martin wrote: > > I think I misworded that a bit. I was meaning the 'one liner' that is > often added to the GPL copyright notice which includes the originating > Author's name. > > > one line to give the program's name and an idea of what it does. > > Copyright (C) name of author > > I was always under the impression that was the notice to remain intact? Yes, that's exactly right. But a lot of packages these days go out with a file with a name like CREDITS that lists who did what. For example, the FlightGear source distribution comes with a file called "Thanks" that lists various people and what they've contributed. That file is fair game under the GPL; if someone redistributing FG wanted to edit it to say different things about who did what, the GPL does not restrict that. Of course, their new claims would be flatly contradicted by the original; and if they're continuing to obey the GPL, then their redistribution should contain or point to the original where people can see the truth about the credits. But most people won't go and look. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpcXHWRz5L72.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wed, 19 Jan 2005 15:59:07 -0500 David Megginson wrote: > > Note that he said that the changed the credit to hide the origin of > the sounds: that violates the GPL. Yes, if the credit they're changing is in the accompanying copyright notice. No, if it's some statement of credit in an accompanying CREDITS or THANKS or README file. > The redistributors either have > to include the full original distribution, unmodified (including any > README files, etc.) or else they have to provide a way to get it -- > that tells their customers that there's a way to get the same stuff > for free, Yes, and this is the protection against monkey business like I mention above. However, lots of recipients won't realize or discover they can do this, even if a copy of the GPL and directions to the original content come with the redistribution. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp4LV2isSt9Z.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wed, 19 Jan 2005 21:02:10 + Dave Martin wrote: > > The authors would have no recourse then. If they had willingly licenced > their work under the GPL, they are permitting anyone to make commercial > use of their models / work providing that credit is not removed Just for clarification, you have to be careful about that last bit. The GPL allows this because you copyright your creation and you write a copyright notice in your name. The GPL requires that all the copies come with a copyright notice. However, things like "CREDITS" files and so forth are not protected under the GPL; the GPL does not require that credit not be removed, apart from protecting the copyright notice. In fact, the GPL prevents such a restriction from being placed on a work released under it. That fact was at the heart of the conflict over the new XFree86 license; most Linux distributions have dumped XFree86 over its subsequent incompatibility with the GPL. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpHLfFFDbENV.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
On Wed, 19 Jan 2005 18:21:39 +0100 Oliver C. wrote: > > Personally i think that it is not a good idea to advertise aircrafts for > FlightGear that are not free. > > Here's the reason why: > Advertising none free aircrafts or scenery addons on the flightgear > website could lead to a common behaviour that people tend to not > release their aircrafts or addons under the GPL license when other more > restrictive ways like simple Freeware licenses are possible and > accepted. I think this is true. I differ with you in how awful I think this would be. I would absolutely *prefer* that people use the GPL. Everything I do is licensed that way. But if someone who has put a lot of effort into creating something decides they want to make it available to the community, but do not want other people to be able to make money off of it without the original author getting any credit, I'm not going to tell them that they're bad people for wanting that. The more people creating add-ons for FlightGear, the more attractive it will look. The more attractive it looks, the more users it will have. The more users it has, the more people will create add-ons for it, *some* of which will doubtless be licensed under the GPL. Those are GPL'd add-ons that those new contributors would not have created otherwise, because they never would have tried FlightGear in the first place. > This has also many other disadvantages like: > > - you can't modify or correct the aircrafts, scenery addons etc. This depends on what non-GPL license is used; it's not universally true. > - aircrafts and scenery addons might get outdated or incompatible to > newer versions of FlightGear This is true anyway, even with GPL'd stuff. You might be saying that license restrictions might make it difficult for third parties to fix such future incompatibilities, in which case my answer is as above: it depends on the license. It's not universally true. > - users are forced to collect their aircrafts and scenery addons from > different places, which is a bad thing, because it is extremly > cumbersomely and annoying. MS Flight Simulator people know what i am > talking about. FlightGear should make use of the fact that it is open > source, it allows users to get everything in one piece without the > hassle to visit hundreds of different websites. This is going to be true no matter what. People are always free to create add-ons for FlightGear, and they're always free to put whatever licenses they want on it and/or make them available in other places. The only way to prevent the scenario you describe would be to somehow make it impossible for anyone creating add-ons to license them under anything other than the GPL. I don't know how you'd do that, but I definitely wouldn't support it. > - the amount of GPL'd flightgear data like aircrafts and scenery would > grow slower when simple freeware addons are okay and linked to on the > flightgear website. I'm not sure this is true. Your thinking is presumably that an add-on licensed under a typical "freeware" license is an add-on that could have been licensed under the GPL, but wasn't. However, it's not a zero-sum exercise. One of the reasons there are so many add-ons for MSFS is because there are so many people using it, and one of the reasons there are so many people using it is because there are so many add-ons for it. If the availability of "freeware" -licensed add-ons causes the FlightGear community to increase in size, and thus the number of people creating scenery and aircraft increases, then it's quite possible that the amount of GPL'd add-ons would increase also. I think we should always *encourage* people making stuff for FlightGear to license stuff under the GPL. But I don't think we should ostracize enthusiastic users who opt for other licenses for the things they create for the community to use. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpKE5bQaJXZK.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Tue, 18 Jan 2005 20:57:48 -0600 Curtis L. Olson wrote: > > 737 - large commercial jet. Reasonably well done. Flies pretty well. > Nice 2d panel with some simple glass elements. I like the 737 -- I've probably spent as much time with it as I have with the c172. I'm sure it's giving me bad habits; but it's fun. It has a couple of issues I think need to be resolved before it should go in the base package, IMHO. The most important is that when you run it from the command line, you get the huge "Beta" warning message telling you that it may not fly as expected and should be used for development purposes only. If that's not its status in FlightGear, the message should go; if that *is* its status, then it shouldn't be included. A casual user would find that message unsettling, IMHO. The second -- it's had a contrail submodel added to it, and I don't think the project is done. The contrails don't start until 7k feet, and they look OK at altitude. But they continue on as you descend through 7k feet and all the way to landing. When they're created at the engines, they have forward momentum, and their deceleration is less than what the aircraft experiences while braking on the runway. The result is that when you land, as you brake, your contrails go shooting forward past you and pile up on the runway ahead of you. This continues until you stop decelerating. The third -- I don't know when this happened, I can't find it from browsing the CVS logs, but right now the localizer arrow is hardwired to NAV1 and the DME is hardwired to NAV2, meaning anyone coming in on a localizer/DME has to have both radios set to the localizer and can't use a second navaid. This doesn't seem right to me, and I'm pretty sure it wasn't like this at one time. I haven't submitted a patch because I'm not sure about this and wanted others' input. So, I guess this is a request for that input. > c172, c172-le, c172p, c172r, c172x - I don't have the energy to sort > out the dependencies so throw it all in. I hope someone who does understand the dependencies and can sort it all out will. This has confused me in the past, so I guarantee there will be users who get confused. > p51d - A classic WWII fighter ... also well done. Full 3d cockpit. Just out of curiosity, what remains to be done with the Spitfire? If it's in production, are there any reasons to favor it over the P-51, or vice versa? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpSArqOZwMUd.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Mon, 17 Jan 2005 12:49:49 -0600 Curtis L. Olson wrote: > > For the upcoming release of FG, I'm working on a couple scripts to > create/manage a web page for individual downloads. Here is where I'm at > > so far. There is plenty room for improvement, but this will at least > get us started: > > http://www.flightgear.org/Downloads/aircraft/ Cool. The one thing I'd recommend is including info about development status (at the very least, the one-word status that's used in the --min-status command line switch). Without it, there will be users d'l'ing a plane with great enthusiasm only to be disappointed to find that it's in alpha with no panel and no real FDM, etc. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpL767vpkFiL.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Airport codes (was Re: plib-1.8.4_RC)
On Sat, 15 Jan 2005 09:04:08 +0200 Paul Surgeon wrote: > > BTW: Is Robin going to give us a fixed airport db before we release > 0.9.8? i.e. The appended K's to the FAA codes is not pretty and caught > me out today. Can you elaborate on what you mean here? What is it that you're saying is broken, and why? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpFwW6Cok156.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [BUG] crash in FGTower::CheckCircuitList() (tower.cxx:392)
On Sat, 15 Jan 2005 02:36:51 +0100 Melchior FRANZ wrote: > > Can't say exactly where, because the gdb frame #0 was unusable. > (Stack violation?) Anyway, it was in FGTower::CheckCircuitList(). > Not reproducible, but I saw this a few times already. That's all I > could collect: Similar stuff: http://baron.flightgear.org/pipermail/flightgear-devel/2004-October/031481.html -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpzxCX9Xwn8H.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Google adwords?
On Fri, 14 Jan 2005 03:14:50 - Jim Wilson wrote: > > Sort of a little off topic: Something that would be really cool (at > least in the US) is to have a registered non-profit that just collected > donations (like United Way) and then uses those funds to make grants to > individual projects like flightgear. I'm not sure of the legalities, > but perhaps such an organization could accept tax deductable gifts from > individuals that are directed to specific projects by the donor. Maybe > there is already something like this? FSF supports official "gnu" > projects, and allows a limited number of directed donations, but only at > their discretion. The one thing I'm aware of that's similar to this is Software in the Public Interest ( http://www.spi-inc.org/ ). Donations to SPI are passed on to free software projects that they've chosen to support (primarily Debian, the LSB, and the OSI). People can also make earmarked donations to SPI that are then passed on to the relevant organizations. SPI is a 501(c)(3) organization. I don't know how you get to be one of the projects they support. The Board of Directors is mainly made up of current or former Debianistas (Ian Jackson, Bruce Perens, and so on), and SPI is normally spoken-of in terms of being the donation route for Debian. I don't think it'd be a bad thing to contact them and see if FlightGear can get added to their list of supported projects -- it'd be a comparatively painless way to effectively have 501(c)(3) status. I expect the worst that can happen is for them to say "no, sorry, can't add you on." -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpyS0cnxZR2N.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Google adwords?
On Thu, 13 Jan 2005 13:39:07 -0600 Curtis L. Olson wrote: > > Is this worth looking into, or would it be crossing some sort of > open-source ethical line? I don't think it's crossing an ethical line. That doesn't mean we wanna do it, though; just that I don't think *that's* the reason not to. I remember this thread on banner ads from July; there may be some insightful points there: http://baron.flightgear.org/pipermail/flightgear-devel/2004-July/029398.html One question I have is how binding the agreement would be. Suppose after a couple of weeks of GoogleAds, everyone says "this sucks" and wants to get rid of them. Could we? Or would we be stuck with having them on the website for 3 months/6 months/a year because those were the terms of the agreement? I'd feel less favorable to them if I thought there was no way out if they turned out to be more trouble than they were worth. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpc4AjgQcXx1.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Wed, 12 Jan 2005 08:29:43 + (UTC) Martin Spott wrote: > Chris Metzler wrote: >> One other possibility you might wanna consider is allowing uploads/ >> dloads of terrain (e.g. tiles modified through fgsd). > > This is not as easy as it sounds because you'd have to redo the tiles > on every scenery update. Right -- I'd commented elsewhere in this thread about how I'd spent a lot of time fixing up a tile in fgsd (moving riverbanks, changing ground poly materials, etc.), only to have to start over when a new scenery update came out (and I needed the new scenery for that tile because one of the TerraGear improvements fixed a glitch in an runway in that tile). It's still something people will do from time to time; I note that Frederic seems to "touch up" some of the default area tiles prior to releases, with the touched-up tiles going into the release/CVS. One probably would only need to re-edit the tiles if the scenery update results in either a major change to the tile (so that you're missing something important if you use an old tile), or to the boundaries of the neighboring tiles (thus creating a boundary mismatch if you use an edited old tile). Anyway, I think it'd be a good thing to offer. But you're absolutely right that editing the tiles this way isn't the best way to do it. > The "right way" to incorporate manual scenery > changes would be to parametrize these changes and provide a method > to add them to the automatic scenery build. I agree completely. > Typically this sort of undertaking is called GIS - Geographic > Information System (like GRASS). Currently there is one drawback as the > available OpenSource database add-ons (PostGIS, this is one reason why > I love PostgreSQL so much) can handle 2D objects of almost any type > really fine (it's fun so see a map being drawn out of a database) but > they don't handle elevation data. OK, I'm very ignorant about this. Is that a major limitation in that it'd be very hard/time consuming for someone competent to adapt PostGIS to include elevation data? If you're currently up to speed on this stuff, can you describe how hard it is *to* come up to speed on it if you're not? (IOW, how comparatively hard is it to figure out this stuff) > We might start this by putting roads, railways, rivers and lakes into > such a database to allow for manual tweaking if someone is willing to > add a PostGIS interface to the TerraGear toolbox - and Curt agrees on > to proceed on this path I don't know anything about this stuff; but if I'm not working on the Zope site (I don't see the point in redundant effort, and I do think your approach of organizing the contributions in the same way as the FG scenery makes more sense), I'd be willing to look into this. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpIsg6U2krpK.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Wed, 12 Jan 2005 00:09:43 + Jon Stockill wrote: > > Chris Metzler wrote: > > Oh, one other thing. If the plan is to combine Jon's UK info with > > info submitted by others to develop a model location database, you > > might find my post from that "Scenery" thread interesting -- it's > > something I'm willing to contribute annually or whatever . . . > > I would imaging it should be fairly easy to import that information > automatically, assigning appropriate models based on the description. If > > these are put into their own group then it also becomes easy to remove > them from the database before importing an updated version - I'd > definitely be interested. I already have a python script for pushing the magic carpet around from lat/lon to lat/lon in FG for extracting ground elevations. If it seems to you like a reasonable thing for me to do, I'll start generating ground elevations for chunks of this dataset? There are over 100,000 objects in the FAA's Digital Obstruction File, so it's bound to take a while. If there's an ASCII format you'd prefer to get the data in, I'd like to see a line or two of it so that I can send stuff to you in a way that's simplest for you. Also, if there's a particular subset of the data (e.g. cooling towers) you'd like to see first, that's easy enough to do as well. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpY6MbYQM0SC.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Wed, 12 Jan 2005 07:13:46 + (UTC) Martin Spott wrote: >Chris Metzler wrote: >> >> So to make sure I'm getting it, your plan is to have an FTP site >> for uploads and the website for dloads (what's the procedure for >> stuff making it over from one to the other)? > > Well, what would you expect us to do ? I have no idea; that's why I asked. > I believe we won't ask for > everyone's approval before placing an object on the website Of course. I was simply curious whether stuff would get automatically moved over, or whether you had plans to test out the robustness of contributions beforehand (which seems liked it could evolve into a huge task), and how you might resolve conflicting contributions (someone uploads and object that someone else has already done), and things like that. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpRZkkOMRkHl.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Wed, 12 Jan 2005 00:06:17 + Jon Stockill wrote: > > 3. From this we'll generate an archive of scenery models (this may or > may not be broken down into scenery areas - it depends on the size), and > > the objects tree, which is likely to be broken down into the standard 10 > > degree square scenery chunks - to use it you'd download the chunks that > match your scenery, and the model archive. Oh! I get it now (I think) -- so your plan is not to necessarily distribute objects (e.g. a dload of the Eiffel Tower) or unified groups of objects (e.g. a dload of the buildings at Orly), but instead portions of the Scenery/Objects tree that have been fleshed out with the uploaded objects (e.g. a dload of Scenery/Objects/e000n40). If someone uploads the Sears Tower, another person would dload it not by dloading the Sears Tower, but by dloading the 10x10 or 1x1 scenery chunk that contains it, which might also contain other objects (shared or static) that people have uploaded. Right? That's a neat idea -- I hadn't been thinking in terms of that paradigm at all. I'd been thinking just in terms of the way the other FS dload sites do it, which make sense for e.g. MSFS but is probably not the best way to proceed for FG. One other possibility you might wanna consider is allowing uploads/ dloads of terrain (e.g. tiles modified through fgsd). I don't know what the best way to handle this is, especially given the possibility of conflicts with later official terrain builds. I have objects I've placed where if I put them at their GPS-measured coordinates, they'd be in water, because the river's a quarter-mile off its correct location. It'd be nice to be able to pass along fixed-up tiles. Anyway, just a thought. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpqGZWAfbIiE.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
Oh, one other thing. If the plan is to combine Jon's UK info with info submitted by others to develop a model location database, you might find my post from that "Scenery" thread interesting -- it's something I'm willing to contribute annually or whatever . . . http://baron.flightgear.org/pipermail/flightgear-devel/2005-January/033478.html -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpuyex7JEuCt.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Tue, 11 Jan 2005 19:17:35 + Jon Stockill wrote: > Martin Spott wrote: >> >> and in continuation of the recent "Scenery" thread we are currently in >> the process of developing this into a solution that meets our >> expectations concerning interface standardization. >> We'll combine this with an FTP upload site (already present) and >> different sorts of frontends that enable us to import, export, >> replicate the object/model database and browse the contents. >> An early shot can be seen here - the thumbnails are already read from >> the database (many thanks to Jon !!): > > Where "already" = about 15 mins before Martin posted that :-) I have lots of questions, hehe. So to make sure I'm getting it, your plan is to have an FTP site for uploads and the website for dloads (what's the procedure for stuff making it over from one to the other)? Presumably when they upload, they include a description of some sort (separate file? entered through a web form?) and possibly an image showing what the object looks like in fgfs, and that gets displayed on the webpage? And maybe some sort of category for organizational purposes. Is it oriented towards individual objects, or will sets be handled (e.g. someone comes along and uploads a set of building models/ textures to flesh out downtown Chicago -- do they get broken up into individual buildings for dload)? When someone dloads a static object (e.g. Jon's Millenium Dome), do they also get an install script? What's the plan for interfacing this with the database of shared object locations (stacks and cooling towers and so forth) in the UK that Jon's worked up? If someone dloads the cooling tower model, do they get a script that inserts cooling towers into .stg files everywhere a cooling tower is known to be? Will the database be searchable? Are you using a CMS, or building from scratch? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpTrLbpHEt9K.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Tue, 11 Jan 2005 08:14:41 -0800 Stewart Andreason wrote: > > Would it be helpful to report on anomolies, or errors? If by anomalies/errors, you mean things that clearly look like bugs, like seams/rips/etc., it makes sense to report them. However, it probably makes more sense to report them on terragear-devel than here. And it also makes sense to put a small amount of effort into googling the list archives (for terragear-devel and flightgear-devel) to make sure nobody's reported it before. But if you mean anomalies/errors such as "road is a little off position and thus cuts through airport area" or "riverbank off in detail" or "city boundaries aren't like that in this area" or stuff like that, see below. > Or is the scenery generator pretty much automated in combining > topographic, tower, and roadway features? I'm not the best person to be answering this; but nobody else has, so I'll stick my neck out. The generation of that stuff is automated, from publicly available datasets. There are errors associated with inaccuracies in the datasets as well as errors associated with matching the datasets up. To the best of my knowledge, no system exists for passing along corrections or refinements to the copies of those datasets used to generate the terrain (if I'm wrong about this, I hope like hell someone will jump in). This would be a very cool thing to have. Recently I used Frederic's fgsd to redo the banks of the Potomac and Anacostia rivers in the Washington, D.C. area -- they were way off. And I drew out the Mall, and changed its materials (terrain types), so that it'd look right. Then a new set of scenery came out. I needed to go with it, since it fixed a big airport bug that afflicted some airports, including National Airport. But that meant throwing away all the work I'd done fixing the terrain. If there were a system for feeding this info back into the datasets used by TerraGear to generate the terrain, so that corrections would show up in future scenery releases, that would be uber-cool. But it's not like everyone doesn't have a ton of ideas to pursue or problems to solve; someone with the skills to make it possible finding the *time* to make it possible is the hardest part of all. (so if you're interested in contributing and looking for a problem to work on . . .hehehehe) (TerraGear cognoscenti encouraged to jump in and correct anything I said above that's bogus) -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpvIVLO36fAC.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Tue, 11 Jan 2005 16:41:54 + (UTC) Martin Spott wrote: >"Roberto Inzerillo" wrote: >> >> Please let me know about the repository. > > We'll announce it here as soon as we have something that works and > looks neat enough not to disgrace ourselves :-) Can you elaborate, though? Because this has been discussed here several times over the last year and as a result, other people (e.g. me, Mat Churchill, etc.) have been working on this as well. I've been working on making a site in Zope that one can upload to/download from, with the intent of having pictures, a description, download links, and a comment log for each item. Mat Churchill and I had been discussing buying hosting for it. I'm curious what you've got in mind so I know if my efforts are better spent elsewhere. >> Should I consider buying a portable GPS, going in place and check what >> the machine says? Is there a way I could use aerial/staellite pictures >> [...] > > I believe others can give a more reliable comment on this. For my own > use I tend to rely on satellite images and I so far didn't get > disappointed. Although for some regions of our earth there are no > pictures available for free or they probably don't contain detailed > coordinates (see the end of the "Scenery" thread). > > Does anyone have experiences with portable GPS recievers ? Do they tend > to increase the precision of their coordinate output if you remain at > a location for several minutes ? I've been using a portable GPS around town here for a while now. Unfortunately, I have to be careful because I live in a metro area where walking up to landmarks or airport facilities with a portable GPS receiver and making notes is liable to get you stopped by the cops or worse. Anyway, in answer to your last question, I'm not sure whether you mean to be asking about precision or accuracy. Precision is a fixed property of the receiver; but as far as accuracy is concerned, yes, standing still at a location for a while tends to improve the accuracy of the coordinates given. Because of the risk of hassle here if I run around with a GPS at sites I'd wanna model, the main thing I've done with it is run around and take measurements at clearly defined locations (e.g. intersections), and then feed those coordinates into http://www.mapquest.com/maps/latlong.adp and see how Mapquest does . . .basically checking Mapquest's lat/lon accuracy. Surprisingly (for me anyway), I've found that in this metro area, Mapquest is consistently spot-on with its lat/lon coordinates -- its error appears to be within the fluctuations I get from the GPS receiver directly. This has in turn allowed me to use Mapquest for placement of some objects where measuring GPS coordinates directly could get me hassled. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp6nMgbHX3aj.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: fun with SGI images
On Tue, 11 Jan 2005 10:04:34 -0600 Curtis L. Olson wrote: >Melchior FRANZ wrote: >>> >>> after a while I forget who on this list is completely insane and who >>> isn't. :-) >>> >> >>I am only partly insane. I'm trying to hide it as good as I can. ;-) > > I'm still trying to decide where I fall in the continuum ... and I'm > still waiting for a few angry responses from people irritated that I > have just accused them of being insane (then I'll know where to classify > them.) :-) >From _Serial_ (1980): Little Boy: In an insane society, the sane man must surely appear insane. Martin Mull: Where did you get that? Little Boy: Star Trek. (exits) Martin Mull: God I miss that show. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgprYQZsF1AjI.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
stributed with FlightGear after conversion to FlightGear's formats. But it doesn't prevent someone from converting it to FlightGear's formats and redistributing it to other FlightGear users, under the same license as the original and independently of the "official" FlightGear distribution . . .sorta like how sites like avsim.com or flightsim.com work. I think this would be pretty cool; but again, it requires extracting models and animation info from the .bgl files. And, like mentioned earlier, it requires the distribution site, of course. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpllnuws5Ptb.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Budget 'display-only' system?
On Sat, 08 Jan 2005 12:37:23 + Jon Stockill wrote: > > > I think you'd struggle to maintain 35FPS in complex scenery areas with > the 5200 - although you could probably replace that with an older > GeForce4 card of a higher spec or about the same price. The > motherboard/CPU is perfectly adequate though - I've run flightgear on > far less. I was going to comment on this as well. Tom's Hardware's website has a number of good graphics card comparison articles; they suggest very strongly that an FX5200 isn't really a good buy for the buck, and that *at that price point*, your money would be better spent on eBay going for a GF4 Ti 4x00 card. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpdSBqRIIjcn.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Fri, 7 Jan 2005 21:12:01 + Lee Elliott wrote: >On Friday 07 January 2005 07:35, Chris Metzler wrote: >>On Tue, 4 Jan 2005 19:48:27 +0200 Paul Surgeon wrote: >>> It would be really nice if the level of development was >>> listed as well as a brief description about the aircraft. >>> That would help people decide whether they really want to >>> download the aircraft or not. >>> >>> For example : >>> --- >>> Development level : Beta >>> Description : This Airbus XYZ was built in 19xx. >>> 2000 of them were build before production stopped in 19xx. >>> Please note that the hydraulic system is not fully >>> operational at this stage. >> >> I think this is a good idea. Even if it's just at the >> "alpha"/"beta"/ "finished" level. > > Wasn't this addressed via the tag in the set files? Yes. But that doesn't directly help the potential downloader of an aircraft, since they can't look at that info without first downloading the aircraft -- unless it's incorporated into Curt's webpage somehow, which is what Paul suggested. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp6Uny4IXegA.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Fri, 07 Jan 2005 11:02:32 +0100 Erik Hofman wrote: > > No wait, this is the only option where the order is important. This does > > work: > > fgfs --min-status=production --show-aircraft Right, but doesn't this presume that they already have the aircraft installed? I just checked -- the min-status flag appears to act as a filter on the list of aircraft that you already have installed. So if you're looking at installing an aircraft from Curt's web page, you won't get that info until after you've installed it . . .hence the suggestion to include that info, at least in terse form, on the page. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpyZ25YoE35E.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Happy New Year
On Wed, 05 Jan 2005 10:17:53 -0600 Curtis L. Olson wrote: > > Looking forward to 2005 there are a few things I hope we can accomplish. > > 1. I'd really like to do a version 1.0 release. Other than bug fixes, what would this be like? IOW, what's missing from the feature set a 1.0 release would have? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpX2sj4lNswP.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Tue, 4 Jan 2005 19:48:27 +0200 Paul Surgeon wrote: > > It would be really nice if the level of development was listed as well > as a brief description about the aircraft. > That would help people decide whether they really want to download the > aircraft or not. > > For example : > --- > Development level : Beta > Description : This Airbus XYZ was built in 19xx. > 2000 of them were build before production stopped in 19xx. > Please note that the hydraulic system is not fully operational at this > stage. I think this is a good idea. Even if it's just at the "alpha"/"beta"/ "finished" level. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpO1kzM8ATH6.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 747 PFD Problem
On Wed, 05 Jan 2005 21:32:41 +0800 Innis Cunningham wrote: > > Hi All > > Has anyone else noticed that the airspeed display and > the altitude display go to all zero's when the aircraft nose > goes below the horizon in FG 9.6.Also on T/O roll on 28R at KSFO they > go to zero when the A/C gets to about 100 kts.I guess something > is broke because the problem dose not happen in 9.5.Very strange > because the airspeed tape and the altitude tape work just fine. > I guess not a lot of people fly the heavies or this would have > been noticed earlier.Unless it only happens on the windows version. I can't reproduce this with current CVS. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpncIQwQHu0x.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery, plus an offer
On Thu, 06 Jan 2005 18:30:15 +0100 Erik Hofman wrote: > > Chris Metzler wrote: > > > Jon, are you agreeable to getting this stuff into the downloadable > > scenery (that is, putting the models into the data tree and making > > their placement part of the TerraGear/scenery generation process)? > > Curt, are you? It would be cool to have this stuff in the scenery. > > There is no need to include it in the official release since we now have > > a Terrain directory and an Objects directory in the Scenery directory. > This makes it easy to add additional objects after you have installed > the Scenery Terrain. I don't mean the official release (although there where appropriate) so much as the downloadable scenery available at e.g. http://www.flightgear.org/Downloads/scenery.html . . .in other words, just as we have radio towers decorating the landscape, having cooling towers and might be good as well; and just as we have control towers and windsocks at airports, having checkerboarded buildings at the airport navaids locations might also look very nice. Yes, it's true that the stuff can (with some effort if you wanna do it globally) be downloaded and installed; but so could be the radio towers and the control towers and the windsocks and so forth. If we know that they're present, and we know their locations, and we have models for them, and it doesn't consume a lot of disk space to include them or bandwidth to download them, why not include them? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp3rt5yJ5hIW.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery, plus an offer
On Thu, 06 Jan 2005 13:21:36 + Jon Stockill wrote: > > I can position all the navaids for you if you like. If you have any > lists of object positions (I've got lighthouses, wind farms, power > stations, radio masts, and Ordnance Survey triangulation points in the > database so far - but this only covers the UK) then I'd be happy to add > them to the data I have and produce scenery object data for you. Jon, are you agreeable to getting this stuff into the downloadable scenery (that is, putting the models into the data tree and making their placement part of the TerraGear/scenery generation process)? Curt, are you? It would be cool to have this stuff in the scenery. On a related note: I have a copy of the FAA's Digital Obstruction File dated May 9, 2004, covering the U.S. and at least some of Canada. This document is released periodically (quarterly?); and as near as I can tell, is unencumbered by IP restrictions, although not released for free. I think it'd be very useful for improving the generic scenery in the U.S. Its contents look like this: NOS V LATITUDE LONGITUDE OBSTACLEAGL AMSL STROBE ACCUR MARK FAAACTION 308294 ST NO S ST CITY DEG MIN SECDEG MIN SECTYPE FREQ HT HT IND H V IND STUDY NO JDATE 284460 --- 300150 01-1307 O AL DAUPHIN ISLAND 30 10 45.00N 088 04 39.00W RIG0236 00236 R5 DY 90SO1578 C92125 235361 01-1472 O AL FORT MORGAN 30 11 20.00N 087 57 10.00W STACK 0193 00193 R5 DY 92SO2230 C96309 238951 01-1459 O AL DAUPHIN ISLAND 30 11 20.00N 088 07 15.00W RIG0240 00241 R5 DY 92SO2229 C93277 234894 01-2567 O AL GULF SHORES 30 13 49.00N 087 52 25.00W BLDG 0223 00242 R5 DN 00SO3180 CA4005 231225 01-2558 O AL GULF SHORES 30 13 49.00N 087 52 30.00W BLDG 0223 00242 R5 DN 99SO3256 CA4005 233277 01-2363 U AL FORT MORGAN 30 14 16.00N 087 52 01.00W TOWER 0300 00317 M N 00SO3108 AA0284 226782 01-1173 O AL DAUPHIN ISLAND 30 15 01.00N 088 04 45.00W TOWER 0201 00205 R5 DY 88SO2440 C89163 245470 01-1330 O AL DAUPHIN ISLAND 30 15 54.00N 088 07 32.00W RIG0186 00186 D5 EY 91SO0652 C91350 233927 01-0196 O AL FOLEY 30 16 46.00N 087 41 33.00W T-L TWR 2 0130 00140 N5 EY C84144 188870 01-2870 O AL ORANGE BEACH30 16 58.00N 087 35 04.00W TOWER 0155 00170 N2 CN 03SO0528 CA3341 239458 01-0291 O AL FOLEY 30 17 12.00N 087 36 23.00W TOWER 0300 00317 Y 66ME0248 D79163 212543 The obstruction types in the list are ARCH, BALLOON, BLDG, BLDG-TWR, BRIDGE, CATENARY, COOL TWR, CRANE, DOME, ELEVATOR, MONUMENT, OBSTACLE, PLANT, POLE, REFINERY, RIG, SIGN, SPIRE, STACK/STACKS, T-L TWR, TANK, TOWER/TOWERS, TRAMWAY, and WINDMILL. Some of these correspond to types of objects that Jon has spent a lot of time creating very nice looking models. I think this would help make scenery in the U.S. and Canada look a lot nicer with very little help. My good news for the new year is that I got a new job. While I'm employed, I'm willing to buy a copy of this file annually for TerraGear to use in object placement, and work on scripts to add to TerraGear to do it, if the interest is there. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpuZAeb06XMU.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ac model exporting from blender
On Sun, 02 Jan 2005 23:23:36 + Jon Stockill wrote: > > I have a hangar model in blender which is using 2 texture files. It all > appears correctly in blender, but when exported only 1 of the texture > files is referenced in the ac3d file. Has anyone seen this before? Is it > > something I'm doing wrong, or is there a problem with using multiple > textures when exporting to other file formats? Yes -- I ran afoul of the same thing. It's another limitation of the ac3d file format. There are two simple solutions. One is to create a big texture that contains both the textures you want to use, and UV map to the appropriate portions. The other solution: individual objects in an ac3d file can only use one texture. But the ac3d file doesn't capture an object -- it captures a scene, which can contain multiple objects (in blender, different meshes). So in blender, take your object, and break it into 2 logical objects (that is, two different meshes), each of which only needs one texture file. Then texture each object. It should then export OK. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpYrBSF124vO.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] What was decided about the guy on -user who's bouncing everything back to sender?
The [EMAIL PROTECTED] guy is still bouncing back to sender everything posted to flightgear-users. Looking back through the archive, I can't decided if anything got decided about what (if anything) to do about him . . . -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp2s7WjIk4bn.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Real weather fetch
On Wed, 29 Dec 2004 13:16:48 -0600 Curtis L. Olson wrote: > > I know different people will have different opinions on this, but I feel > that simply interpolating over time to the "closest" data is just as > good as anything. Interpolating spacially between the closest 3 > stations is attractive, but remember this data is already starting to > get old by the time we get it so we will never be exactly correct with > current conditions. [ snip ] > Personally, I think it would be a *lot* simpler, and arguably just as > accurate to do a temporal interpolation towards the latest data at the > closest weather station. Another issue is the fact that the data available from the METAR station seems sometimes *very* old (e.g. a day or more). I've flown (in FlightGear) around a metropolitan area where I know exactly what the weather's like (e.g. clear skies), and found it change from roughly correct weather to something *wildly wrong* (e.g. overcast down to 900 feet, which it was like earlier in the week but definitely not today) to something correct again (back to clear skies) as I fly 5 miles in a straight line over the metro area. So instead of spatial interpolation, one might consider weighted spatial averaging (e.g. a gather scheme with a broad Gaussian kernel or whatever) to lessen the effect of anomalous stations in densely sampled areas. > Lot's of > fun to be had if someone had the time to play with it ... I used to do stuff that bears some similarities to this for a living. Unfortunately, it was in FORTRAN. Heh. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgptjRd60lF7A.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bad elevation data in most recent scenery (was: Scenery concerns)
On Tue, 28 Dec 2004 14:35:34 +0100 Frank Olaf wrote: > > To where should I direct concerns about the scenery? Stuff like this, which looks like a bug or other such problem, is probably best for the developer list. > There is quite a large portion of scenery near my home which is terribly > > incorrect. From N60.50 to N61.00, E11 there is a large strip running > east and west with apparently no elevation data. > > I'm not sure if this is reported somwhere previously, but someone should > > be notified about the problem. I'm using scenery I downloaded > about 1 month ago with the 9.6 windows binaries. Confirmed with the most recent scenery (generated this past few weeks). It's not a case of missing tiles. The scenery is there -- it's just anomalously flat (in the midst of a region with a lot of hills), with sharp edges, as if all the DEM data for this region reads 0. -c (Reply-To: set to flightgear-devel@flightgear.org) -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp9PXHa45Xzl.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sat, 25 Dec 2004 18:05:15 + Dave Martin wrote: > > What I'm getting at is that the .ac file supports a line drawn between 2 > > vertices whereas Blender *seems* to require at least three (to make a > thin triangle) > > Am I correct with this or is there some way to do vertex-vertex lines in > > Blender? Yes. Go into edit mode, select the two vertices, and hit the "f" key. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpVf0QJUUK53.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sat, 25 Dec 2004 10:54:41 -0500 Norman Vine wrote: >Chris Metzler writes: >> >> A plib loader for .blend would, IMHO, be an incredible boon for FG. > > PLib is Open Source and "If it itches ..." :-) Absolutely -- that's why I wrote that I don't think plib developers are opposed, but rather it's just that no one has contributed it. If I knew more than how to do "Hello World" in C/C++ at this point, I'd be game! Barring that, my doing it has to wait until I *do*. -c (now, if plib had been written in Fortran, hehehehe) -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpoyozBO4M3V.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sat, 25 Dec 2004 03:48:29 - Jim Wilson wrote: > > > Wasn't this a blender model? Do we want to go the route of breaking > away from the blender artists by working on the converted ac3d format > files? If we don't, then we should probably have blender sources > available along with the base distribution. I like ac3d a lot, but > after getting gypped by the developer, I'm looking at the whole idea of > developing open sourced models with a closed source tool in a much > different light. No kidding. It's really surprising that plib supports several proprietary 3d modellers, but doesn't support the one really powerful and popular open source modeller. But I don't suppose it's because they're opposed, but rather because no one has sent in code. It's a shame, too, because .blend files can include a lot of detail that e.g. ac3d files cannot. > Those using blender, what exactly (if anything) needs to be done to the > ac file after exporting it to ac format now? Are there any unresolvable > problems. I'm just wondering if using the exporter code it might be > reasonable to write a loader for blender files. A plib loader for .blend would, IMHO, be an incredible boon for FG. As noted, ac3d file format can't include specular/diffuse shading info. Blender/.blend files also give you the ability to texture an object's faces in a fashion other than UV mapping -- by assigning (named) materials to faces, and then assigning different textures to the different materials. ac3d files can't do this. There's a lot of other .blend functionality that ac3d can't do (e.g. procedural textures), but these two are the ones that have bitten me so far. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp30vapz59hS.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sat, 25 Dec 2004 12:38:53 + Dave Martin wrote: > > I have noticed that Blender seems to strip specular material settings > when exporting to .ac > > Not sure if this is something I'm doing wrong or an issue with Blender. Neither. Blender strips them out because the ac3d file format doesn't support them. http://projects.blender.org/tracker/?group_id=9&atid=125&func=detail&aid=1461 -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp6xGEH8sWYG.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Comm radios broken
On Thu, 23 Dec 2004 23:18:33 + David Luff wrote: > > With the latest CVS of Simgear, FlightGear and base package, comm radios > are completely broken, both attempting to set through the panel, http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/032990.html > and > through the property tree. This, OTOH, I don't see. H. A fix to simgear that Melchior committed this morning was supposed to have fixed the problem with the panel. My CVS fgfs compile dates from 36 hours ago so I haven't checked it. When did you update and compile? I d'loaded and compiled the pre-release this afternoon, and the radios in it work fine. I don't quite understand that because it came out after the patch that introduced the panel problem, but before the fix was submitted. But anyway, the panel works for me there. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpNwIP5K8cbN.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announce: FlightGear-0.9.8-pre1 and
On Thu, 23 Dec 2004 10:28:23 -0600 Curtis L. Olson wrote: > > I'm sure I'm using plib-1.8.3 here without problems. Anyone else seeing > > a problem? I'm currently dloading, to see what the status is of CVS bugs discussed here recently . . . -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpbE0yv9eG7r.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bug in CVS: radio panel hot spots no longer work
Reported in the IRC channel; Melchior and I have since confirmed. Mouse-clickable hot spots on the panel were working fine for me until I updated plib/openal/simgear/flightgear from CVS and recompiled all this morning. Now *some*, but not all, of the hotspots are unresponsive. Specifically, radio stack switches (frequency swap, frequency tuning, etc.) don't work, while altimeter calibration, NAV radial adjust, etc., do work. I've observed this on the c172 and the c310. Reported on the 737 as well. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp9pP614Io8x.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Weather reporting stations
On Wed, 22 Dec 2004 11:03:07 + (UTC) Martin Spott wrote: > > I believe I didn't grasp the difficulties she's running into ;-) I thought she wanted to know the difference between the various types of automated stations. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp63XhTdR8Zm.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
On Fri, 17 Dec 2004 10:49:56 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > I believe Erik just synced the flightgear tree up with the latest JSBsim > > cvs, so there could be some portability issue that has crept in. I > haven't had a chance to compile the latest cvs commits myself. It's definitely not generic: I just synced to CVS and built on linux with no problem at all. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpLNwupCPY2F.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] PATCH: two changes to data/Aircraft/737/Instruments/pfd2.xml
The first: In going from version 1.3 to 1.4, Melchior Franz noted that there was no /velocities/vertical-speed-fpm property to display, and changed the property referenced to /velocities/vertical-speed-fps, which does exist. But the display should show fpm; so a parameter is inserted to make what's displayed feet-per-minute. The second: In going from version 1.1 to 1.2, properties with '[0]' indices had the '[0]' dropped. But for some reason, a reference to property dme/indicated-distance-nm[0] got changed to dme/distance-nm. In other words, not only did [0] get dropped, but 'indicated-' got dropped from the property name. This broke DME on the 737 -- there is no 'dme/distance-nm' property. This patch fixes it back. Index: pfd2.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/737/Instruments/pfd2.xml,v retrieving revision 1.4 diff -u -r1.4 pfd2.xml --- pfd2.xml13 Dec 2004 20:35:34 - 1.4 +++ pfd2.xml17 Dec 2004 01:51:56 - @@ -353,6 +353,7 @@ number-value /velocities/vertical-speed-fps + 60 %6.0f @@ -387,7 +388,7 @@ number-value - /instrumentation/dme/distance-nm + /instrumentation/dme/indicated-distance-nm %6.1f -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgph5hjqoBKHh.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
On Thu, 16 Dec 2004 23:04:30 + David Luff <[EMAIL PROTECTED]> wrote: > > Well, I've had a very good pan round the Chicago scenery in the ufo with > both the old and new materials.xml on a Linux box with a Geforce3, and I > can't find a shred of difference in any of the runways, regardless of > surface or marking type. FWIW, I just did the same with a GF4 Ti4600, checked asphalt and concrete rwys with both materials.xml's, took snapshots from identical perspectives so I could compare them directly, and I can't see any differences . . . -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpTMp8npj6Oz.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next release planning ...
On Wed, 15 Dec 2004 13:15:34 -0500 Chris Metzler <[EMAIL PROTECTED]> wrote: > > - attempting to load a saved state from the menu crashes the program. ADDENDUM: This appears to be a/c dependent. Flying a c172, saving the state, quitting, restarting, and loading the saved state works. Flying a c310, saving the state, quitting, restarting, and loading the saved state gives you the correct (saved) flight parameters, but in a c172! Flying a 737, saving the state, quitting, restarting, and loading the saved state crashes fgfs. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpivvmMLQNY8.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next release planning ...
On Wed, 15 Dec 2004 13:15:34 -0500 Chris Metzler <[EMAIL PROTECTED]> wrote: > > - the "inner marker" sound immediately upon startup, while sitting on > the runway, that can only be stopped by starting your takeoff roll and > getting far enough along into it. AMENDMENT: as noted when this got brought up in another thread, this one doesn't happen for me. I was mentioning it from memory; but I'm told that if you are experiencing this problem, you don't have to move away to make it stop. You only have to sit through five beeps or so. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpjaDL0fu4PK.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next release planning ...
On Wed, 15 Dec 2004 10:18:04 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > Are there any major outstanding bugs or issues we need to resolve before > > the next release? I realize there are perpetual things (such as our gui > > interface is crude) that we won't be able to address immediately, but if > > there are little bugs or glitches that have crept in, let's try and get > those fixed as quickly as possible. The four things that users come into the IRC channel and complain about most often: - the "inner marker" sound immediately upon startup, while sitting on the runway, that can only be stopped by starting your takeoff roll and getting far enough along into it. - the stall warning sound immediately upon startup, or well after landing, while sitting still on the runway, that can only be stopped by throttling up and rolling. - attempting to load a saved state from the menu crashes the program. - attempting to change airports from the menu does nothing. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp7J2PvghX1g.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS: data/Aircraft/737/737-set.xml -- odd change, starts with empty tanks now.
Hi. data/Aircraft/737/737-set.xml was changed from v1.5 to v1.6 in an effort to get a first shot at contrails working. However, it also changed the starting fuel in the fuel tanks from: ! 1540 ! 1540 ! 0 to ! 149 ! 149 ! 149 . . .giving the 737 about 20-30 minutes of flying time. I'd submit a patch to change it back, but maybe there's something going on here and this is a necessary change for now? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgptrF1U4LDkm.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..there _is_ Glut to be had off cvs or tarballs somewhere???
On Wed, 15 Dec 2004 11:53:39 +0100 Arnt Karlsen <[EMAIL PROTECTED]> wrote: > > ..this ofcourse means I don't have glut set up properly on this old > server box running This means I need Glut off cvs or tarballs or > somesuch, but from where??? Google is your friend. I typed "glut" into google and the third entry was GLUT's homepage, which has a downloads link from where you can get a tarball. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpSIu0PZ2giS.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Advice needed: rwy dist rem sign installation
Hi. So, I recently got a chance to pick this back up. In principle, everything is finished: I have a set of signs which are designed as per the U.S. FAA regs (FAA AC-150-5340-18C, Standards for Airport Sign Systems, and FAA AC-150-5345-44G, Specification for Taxiway and Runway Signs). I also have a script for generating .stg file entries. Features: - can read in airport data in either apt.dat or runways.dat format. - will generate sign placements either for a single airport, a list of airports (a list of ICAOs in a file), every airport in apt.dat or runways.dat (but not heliports or seaplane bases), or every airport in apt.dat that has the "has runway distance remaining signs" flag set. - can place signs using any of the three layout methods given by the FAA regs. - makes sure that there are no signs placed on top of intersecting or nearby runways or taxiways. Specifically, it makes sure that no signs are placed within 50' of any other runway/taxiway at the airport. It attempts to adjust the positioning of a sign to avoid such a conflict, omitting the sign entirely if it'd have to be moved by more than 50' along the runway length, as per the FAA regs. I'd like to contribute this to FlightGear -- I think they'd make a nice addition to the scenery at the airports where it'd be appropriate to have them. However, I'm stuck on one thing that I'm hoping those who build scenery will advise: what's the best way to write this stuff out? Is the best option to: - have the script determine the tile numbers, go to the .stg files, and insert the sign entries directly? - have the script create an "installation" script, into which the sign entries are embedded (e.g. as a here document); such a script could also have a removal option, to take the signs back out? - do things monolithically, or by airport (could be lots of files if doing all relevant airports)? To be of most use to the project, how should this script write its info? -c P.S. As an aside, the routines for determining whether a sign hits a runway/taxiway, and adjusting its position, could be trivially adapted to get beacons and windsocks off of runways where that happens currently. I'd be happy to do that. Yes, the right thing to do is to fix the numbers in apt.dat/runways.dat. But in the short term, replacing a wrong location that puts a beacon right in the middle of a runway with another nearby wrong value that *doesn't* put the beacon on top of a runway seems like a good idea to me. -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpPBfOFps6a9.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] DAFIF comment period: there will be one after all.
So, I emailed the contact given in the FR notice regarding the termination of public distribution of the DAFIF. I noted that there was no mention of a public comment period, as is common for these things, and asked if there was to be one. They wrote back this afternoon, indicating that they'd decided to have one. I've excerpted the email below. I have no idea whether comments from folks outside the U.S. are taken into consideration; I'd bet not. But it *is* the case that comments matter; as I noted elsewhere, they're required to respond to all the substantive points raised in comments they receive when they make their final decision. So commenting is worthwhile. Perhaps it makes sense to discuss here what comments one *would* make, so that USians here who choose to comment won't lack for good points to make. Robin Peel probably already knows about this change, but I'm cc'ing this to him in case. -c } Thank you for your recent inquiry regarding the proposal to remove NGA's } aeronautical products from public sale and distribution. } } After initial feedback from the public NGA has determined that a period } of public comment will benefit the final decision on this policy issue. } So the Agency is inviting public comment on its proposed action to } withdraw aeronautical data and products from public distribution. The } period of comment will be open from 3 December 2004 until 30 June 2005. } NGA will consider all comments when making the final decision to go } forward with this proposed action, in part, in whole, or not at all. } } Your e-mail has been forwarded to the office collecting public comments. } If you have further suggestions, or wish to express any other issues or } concerns please direct them to one of the addresses below. } } Comments may be returned to: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> } or mailed to: } National Geospatial-Intelligence Agency } Mail Stop D-111, Attn: Public Release of Aeronautical Products } 4600 Sangamore Road } Bethesda, MD 20816-5003 -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpXWAMPO4uBv.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DAFIF Will No Longer Be Available to Public
On Sun, 12 Dec 2004 16:34:19 -0500 David Megginson <[EMAIL PROTECTED]> wrote: > > Originally, the excuse for pulling DAFIF was the Australian > government's attempt to sue Jeppesen for royalties on Australian aero > data, or something similar. Now, the reason is simply national > security. I wonder if the Australian thing died out, or if it was > just easier to use the security boilerplate than to get into the > complex legal details. I'd bet the latter -- I suspect the national security-ish lines in the FR entry are in there only because every decision the Federal government makes anymore gets some kind of "national security" justification. What I didn't see was some kind of notification about an official comment period. Normally, when a policy change takes place, the first announcement in the FR mentions a period during which comments can be made. I didn't see that in there. This is significant in that comments made in response to policy changes like this actually do matter. I had breakfast yesterday with two senior executives in the Federal bureaucracy (both GS 15 or higher) who were very emphatic that commenting during the comments period is worthwhile: in subsequently making their decision official or in changing it to something else, the agency in question *must* substantively address the comments received. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpnsNQmBlsEr.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NAV radios still borked on three a/c
On Sun, 12 Dec 2004 12:22:35 +0100 Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote: > On Sunday 12 December 2004 09:05, Chris Metzler wrote: >> >> the pa28-161, > > I tried the pa28-161 and it seemed to work fine. Really? I just checked it again, and both NAV1 and NAV2 are dead for me. I'm running CVS, current as of last night. >> and the >> beech99. [ snip ] >> Lots of things don't work about the latter, including various >> gauges, so the problem may be something other than this transition. > > Hmmm... I just tried it, and all gauges seemed to work fine (alt, vs, > turn, airspeed, ai) The gauge that was messed up for me in particular was the artificial horizon; it was starting out tumbled, and wasn't resetting after a few seconds. But I just tried it again, and it came up OK. So I dunno. Thanks. -c P.S. The patch for C310/beech99 worked just fine. -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpXbiY0qxkOY.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] NAV radios still borked on three a/c
Hi. From the CVS logs, it looks like a whole lot of radios/instrumentation changes went through last week to finish the transition (and thus fix the NAV radio problems). I just went through and manually checked all the a/c which have relevant gauges, and found that the c172 and 737 and so on all work; but three planes still have broken NAV radios: the c310 (and its children), the pa28-161, and the beech99. Lots of things don't work about the latter, including various gauges, so the problem may be something other than this transition. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpo7UAUWciGe.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] World scenery rebuild
On Sat, 04 Dec 2004 19:17:30 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > You can track and download the latest world scenery rebuild graphically > here: > > http://www.flightgear.org/Downloads/scenery-0.9.7.html Good stuff with runway glitches! BEFORE: KDCA Runway 04, takeoff roll, slamming on the brakes: http://www.speakeasy.net/~cmetzler/kdca_intersection_old.jpg AFTER: the same, but no problem now: http://www.speakeasy.net/~cmetzler/kdca_intersection_new.jpg Thanks! You probably know this already, but there are still "seam" issues near the ends of many runways, e.g.: http://www.speakeasy.org/~cmetzler/ksdf_17Rend_seams.jpg These are present both in the old scenery and the new. You are making these now with apt.dat, right? The runways.dat format is gone? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpDeOYjFLFSn.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Inner marker sound
On Sat, 4 Dec 2004 09:46:00 +0200 Paul Surgeon <[EMAIL PROTECTED]> wrote: > > Is there anyway of stopping the inner marker sound going off whenever > starting at an airport on the runway? > > This is a bug I presume because I do not know of any inner markers > located directly on the runway thresholds and it stops once the sim is > loaded. > > I have to turn my sound down when starting FG, it's so loud. Just to follow up on this -- I can't confirm this; it doesn't happen for me. But it does happen for people other than Paul; there've been users coming into the #flightgear IRC channel asking about how to fix this. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpv6m9cxOQvx.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] NAV1 and NAV2 borked in CVS
NAV1 and NAV2 are broken in CVS, apparently independent of choice of aircraft. I've tried them on the c172, c310, and 737; Melchior checked the last two and found the same thing. Doesn't matter what frequency/radial you set or your distance from the transmitter -- the display is dead. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpUNWhE3B62E.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Wed, 1 Dec 2004 17:39:43 + (UTC) Martin Spott <[EMAIL PROTECTED]> wrote: > "David Luff" wrote: > > > J,K = 0.1 degrees > > Shift+J, K = 3 degrees > > Ctrl+Shift+J, K = 0.01 degrees > > > > R, D, F, C move objects 0.5 meters, or 10 meters with shift down. > > Thank you! Does anyone have a current copy of Robin's 'AptNavFAQ' ? > Robin's pages on the X-Plane site have disappeared and the copy on the > FlightGear pages is totally outdated, They haven't disappeared; they just relocated (with a very slight path change). If you go off the links on the x-plane.org front page you'll get to them. Directly, for the FAQ, see: http://x-plane.org/home/robinp/AptNavFAQ.htm -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp2PPrQRVVNN.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Tue, 30 Nov 2004 06:33:36 +0200 Paul Surgeon <[EMAIL PROTECTED]> wrote: > > > It's pretty neat technology. No decompression is required as reading a > texture is done on the fly when it's required. If only a portion of the > compressed texture is used in a scene then only the required pixels of > the texture are decoded and used. > > One would be able to stick nearly 768MB of textures onto a video card > with 128MB of VRAM. The IO saved is enormous if you were trying to send > all those textures to the video card for each frame. It does sound really, really cool. One concern: how widespread is the availability of these two OpenGL extensions? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpeZQZYAZHXF.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Mon, 29 Nov 2004 22:25:49 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: > > This is true . > but don't forget the gain achieved by reducing the disk to memory > bandwith required Absolutely; but this issue (whether the video card can render the compressed textures without decompressing first) is what Paul and Curt were unsure of, if I'm following this. Of course, this also presumes that the guy I quoted knew what he was talking about. I know *I* don't know much about this stuff, thus don't know enough to say. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpesaHYWTr3e.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Tue, 30 Nov 2004 01:15:27 +0200 Paul Surgeon <[EMAIL PROTECTED]> wrote: > On Monday, 29 November 2004 20:53, Curtis L. Olson wrote: >> >> Do the textures stay compressed in video ram, does the texture render >> unit render from the compressed texture, or does it have to uncompress >> it in video ram before rendering it? > > I'm not sure about that - I'll have to makes some inquiries and find out > how video cards actually handle the rendering of compressed textures. > There would be no point if all the textures were uncompressed at the > same time into VRAM. >From http://www.simforums.com/forums/forum_posts.asp?TID=4958&PN=1 [ snip ] } The compressions are not meant to save disk drive space (plenty of it) } but to: } } -reduce the video card memory useage, as since the Geforce2, video } cards can directly render a compressed texture on a 3D polygon without } decompressing it [ snip ] -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp1XF3p2GhAi.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Mon, 29 Nov 2004 17:30:51 +0100 Durk Talsma <[EMAIL PROTECTED]> wrote: > > After solving the multiple copy problem, the AI system became a lot more > > flexible and I was able to load close to 1200 aircraft, but when > multiple aircraft came into view, I experienced some nasty problems, > including DList stack overflows. Reducing polygon count by creating > special AI versions of all our common aircraft (i.e. omitting the > cockpits, and instruments) reduced this problem further. You might consider increasing the size of the DList stack, and/or commenting out the warning written to the screen (the flood of warning messages slows things down dramatically all by itself). I understand that this isn't a decent solution, since one can't expect all the users to do this. But it's informative. I mention this because I ran into a similar problem after modifying some terrain with fgsd. Frederic commented that the DList stack size set by plib was arbitrary, and suggested increasing it and commenting out the warning. See the bottom of this message: http://sourceforge.net/mailarchive/message.php?msg_id=9861990 It would be interesting to see if that solves your problem. If so, and if there are no obvious deleterious effects (I'm ignorant about this stuff), maybe changing the stack size can be suggested to the plib folks. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgprxYdWZ86i1.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: openal & wind.wav: correct pitch?
On Tue, 23 Nov 2004 13:44:55 +0100 Melchior FRANZ <[EMAIL PROTECTED]> wrote: > > Should have been: "is *everyone* else happy with it?" I guess my tendency is to say I'm happy with it if it's closer to how it sounds in real life. And my problem is that I have no idea which one is closer to real life. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpTbRinodewf.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Sun, 28 Nov 2004 20:34:51 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > I can think of 4 approaches to defining taxiways and lines. [ snip ] > 2. Draw the taxi lines as separate polygons over the top of the taxiways > > and runways. [ snip ] > But this scheme would burn a > lot of polygons and it would require some complex preprocessing of the > line polygons to clip them against all the underlying triangles. That > would be no small task ... (writing the code to do that.) > > 3. Cut the lines right into the geometry ... i.e. cut holes for the > lines. [ snip ] > . . .we'd still be burning a fairly high > number of polygons. So while #2 and #3 hold the most promise in the near term, the fact is that they require a lot of polygons. If I remember correctly, the issue with using vmap1 data (rather than vmap0) to improve the accuracy of roads/railroads/land use contours/etc. is also polygon count, right? What I'm wondering is how well known the constraints here are? Presumably some time in the past, someone created a scenery tile that had tons and tons of polygons and their framerate went into the dirt. Was it really old hardware? How high was the visible poly count, and how bad did their framerate get hit? That kind of thing. IOW, do we know that fgfs framerates are basically polygon-count-limited at this point? Maybe this is just a fool's hope on my part, but perhaps we worry about this more than we need to? Maybe everything will be fine. -c P.S. Maybe even vmap1 would work. Or has someone tried it recently, and the results were awful? -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpFO9PkXPhMC.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Wed, 24 Nov 2004 07:29:02 +0100 Durk Talsma <[EMAIL PROTECTED]> wrote: > [ snip ] > > Another thing I noticed is that when the AIModel subsystem loads > multiple copies of an aircraft, separate copies of each model are loaded > each time, instead of referencing to the already loaded copy in the ssg > scene graph. Having multiple copies of a polygon heavy AI aircraft led > to severe memory problems on my system. Wow. > For this and other reasons, I'm currently leaning toward favoring having > a separate set of low-polygon count models for AI aircraft. Maybe I'm not following, but it seems like you're saying that the problem is the multiple loading of the same 3D model (for each AI aircraft) rather than reusing one existing copy in memory. Right? If that's the case, it would seem like trying to minimize how bad this is by using low-resolution models is not so much solving the problem as working within it; and the best solution would be to get plib to be able to only load the model once and to reference it for additional aircraft. But maybe that's really, really hard? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp50ta8Co7Ib.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Traffic Management screenshots
On Sat, 27 Nov 2004 09:13:09 +0100 Durk Talsma <[EMAIL PROTECTED]> wrote: > > Hi Folks, > > This morning I decide to post a selection of FlightGear sceenshots on my > > website illustrating the development of the TrafficManager subsystem, > and its interface with the AIManager. > > http://durktalsma.xs4all.nl/FlightGear/web/index.html Looking cool! I'm curious whether you have ideas on how to generate traffic data (flights and flightplans) for the aircraft that the TrafficManager and AIManager will handle. Are you thinking of doing real-world flights? If so, is there a good place to harvest that data? Thoughts on how to convert it into flightplans of the style you use? Given the work that still needs to be done, there's clearly no urgency to this. I'm just curious what direction you're going . . . Anyway, cool stuff. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpYd8kME92w0.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Want to confirm: X-Plane file format in immediate future?
I just want to confirm re: some stuff I'm doing: the next big scenery build, and the next "release" of fgfs, will be based on the switch from basic.dat and runways.dat to X-Plane's apt.dat? Thanks, -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpQL8VA6en3x.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] When can we have roads like this
On Mon, 15 Nov 2004 06:01:43 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: > > > I think that the newer OpenGL cards can handle *many* more polygons > in the scenery then we are currently throwing at them as long as we > present them clumped according to 'OpenGL state' which shoud be the > case with the basic scenery. Do you have a feel for what "many" means? Is vmap1 data for roads/railroads/etc. becoming a possibility? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpLKOX0Z5XcC.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] TaxiDraw -- runway changes
Hey Dave -- what's the chance of adding: 1) displaying displaced threshholds and stopways along with the runway and taxiway layout; 2) the ability to change runway info, specifically displaced threshholds and stopways? I started to work on an airport and noticed that the runways in the background image seemed longer than the runways as drawn by TaxiDraw. Zooming in, I saw there were stopways present that TaxiDraw wasn't drawing. I then checked runways.dat and noted that the info for the airport was wrong in that stopways weren't present in the dataset, but displaced threshholds (that don't exist in real life) were. So I'd like to remove displaced threshholds and add stopways. But I can't do that directly with TaxiDraw; and as far as doing it by hand, the only way I've come up with to do it is to place a taxiway on top of the runway, including the stopway, check the length, and compare to the length of the runway as given. And then add by hand. No major deal, but if it were possible to view/tweak this stuff in TaxiDraw that'd be cool. Cheers, -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpeFYkGSGdVw.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bug in calc-tile.pl?
Keeping in mind that I don't really speak perl . . .I was trying to understand the tile number calculation, and came upon a bit that doesn't make sense to me in the tile_index function. It looks like it doesn't handle near-polar latitudes correctly -- like it resets the longitude (which never gets used again, so why reset it?) when it should be setting the variable "x" that covers the low-order bits of the tile number. "x" gets set for latitudes in the range -83 <= lat <= 82; but for latitudes closer to a pole than that, "$x" is unset before adding to the tile index number. Should those resettings of $lon be setting $x instead? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpO9Cg0aCKb6.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiheaded video cards?
On Wed, 03 Nov 2004 23:07:01 -0800 "Dale E. Edmons" <[EMAIL PROTECTED]> wrote: > Chris Metzler wrote: > >> What I can tell you, though, is that DRI and OpenGL support for Matrox >> cards under Linux sucks rocks. First of all, Matrox' drivers are open, >> and their proprietary HAL module doesn't really buy you anything, so > > > No real arguments here, but there is useable code for the card in the > native X11. Sure; it's just broken. The DRI project people agree that it's broken; they just don't have anybody that can fix it right now (or, rather, didn't as of late summer. things may have changed). >>for just a taste. There's a lot more there too. Personally, I had >>constant hard lockups requiring a full system reset, with lots of >>DMA idle timeout messages to my X log, whenever I tried flightgear >>for very long with the Matrox card. From other messages in the Matrox > > Sounds like the ASUS (junk!) motherboard I had. My 1GHz athalon on its > > ASUS > board sits collecting dust (it doesn't even do that very well). The > G450 I have is very > robust as is the code. I run Debian Linux without a single lockup in > over a year now. Hmmm, well, yes, this is with an Athlon (XP 2000+) on an Asus a7v333. However, the exact problem I encountered with the Matrox drivers has been reported by several other people on e.g. the X.org and DRI project bugzillas, and they weren't running Asus motherboards. And when I dumped the G550 for a GF4 Ti4600, I never had another problem. I would only get the DMA idle timeout lockups on very intensive OpenGL stuff. fgfs would routinely do it, tuxracer would rarely do it, glxgears would never ever do it. If there were support for the Matrox X11 drivers, I would have been happy to patch the drivers with diagnostics and fail some more and collect info. But since they're not supported by either Matrox or the X/DRI folks, I just couldn't rationalize sticking with it. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp8dXBSisVl7.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem
On Wed, 3 Nov 2004 17:19:09 -0500 Chris Metzler <[EMAIL PROTECTED]> wrote: > > I'll check my algebra again, Checked; I can't find a mistake. As a third check, I ran it through Maple and got the same result. It appears to have the correct limiting behavior for both pitch --> 0 and roll --> 0 independently. And the problem seems straightforward to me. The compass needle is constrained to move on the horizontal plane in the aircraft's reference frame; the question is simply what's the (perpendicular) projection of the magnetic field vector onto that plane, and what direction does that point? You can move the plane by from level flight towards the north pole by yaw, then pitch, then roll; or you can do the opposite transformations on the magnetic field vector itself (same order, but opposite value of angles), and get the same relative orientation of the field vector to the aircraft. So I think this is analytically correct. What's the weird behavior? For what part of parameter space? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpWXAX5R5Qip.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem
On Wed, 3 Nov 2004 16:47:37 -0500 David Megginson <[EMAIL PROTECTED]> wrote: > > Thanks for all the work on that. I just tried it out, though, and it > gives strange behaviour with negative (left) roll angles, even when > pitch is close to 0. It's possible that I caused some confusion by > using theta for pitch, when the original equation used it for roll -- > here's the original equation from the Web page, translated into our > normal phi/theta/psi variables, mu for magnetic dip, and preserving Hc > for the indicated compass heading: > > Hc = atan2(sin(psi)cos(phi) - tan(mu)sin(phi), cos(psi)) > > In other words > > a = sin(psi)cos(phi) - tan(mu)sin(phi) > b = cos(psi) > > Your suggested equation, using the same variable names, is > > a = cos(phi)sin(psi)cos(mu) - sin(phi)cos(theta)sin(mu) > - sin(phi)sin(theta)cos(mu)cos(psi) > > b = cos(theta)cos(psi)cos(mu) - sin(theta)sin(mu) > > I'm really bad at this kind of thing, but when I set theta to 0, I end > up with > > a = cos(phi)sin(psi)cos(mu) - sin(phi)sin(mu) > b = cos(psi)cos(mu) > > Does that actually work out to the same thing by messing around with the > trig? Yes, it does. Basically, just leave the cos(psi) in the denominator, and divide the cos(mu) that's in the denominator into a. In other words, cos(phi)sin(psi)cos(mu) - sin(phi)sin(mu) - cos(psi)cos(mu) = cos(phi)sin(psi)cos(mu)sin(phi)sin(mu) ---- --- cos(psi)cos(mu) cos(psi)cos(mu) (in the first term, cancel out the cos(mu) in the numerator and denominator; in the second term, take the sin(mu)/cos(mu) and replace it with a tan(mu) in the numerator) = cos(phi)sin(psi) sin(phi)tan(mu) - --- cos(psi) cos(psi) = (cos(phi)sin(psi) - sin(phi)tan(mu))/cos(psi) which is what you have above. So yeah, it does work out. I'll check my algebra again, but what are the chances that the strange behavior (you didn't describe what it was) you're seeing are numerical? In other words, when it occurs, what's the typical value of the argument of the arctan? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgprkfqCL2EnT.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem
On Wed, 3 Nov 2004 10:17:34 -0500 David Megginson <[EMAIL PROTECTED]> wrote: > > I'm fixing the magnetic compass instrument to make its behaviour more > realistic. I'm starting with the northernly turning error, and found > a useful site that actually gives an equation: > > http://williams.best.vwh.net/compass/node4.html > > Here's the equation (radians for all angles): > > Hc: indicated compass heading > Hm: actual magnetic heading > phi: bank angle (right positive; the original web page uses theta) > mu: magnetic dip angle (down positive) > > Hc = atan2(sin(Hm)cos(phi) - tan(mu)sin(phi), cos(Hm)) > > The result is very realistic as far as bank/turning errors go, much > better than anything I've seen in a desktop sim. I've checked in the > changes so that others can take a look. > > The problem is that this equation assumes that pitch (theta) is 0. > Now, I need to adapt this equation to incorporate theta as well, so > that the compass will show an error when the nose is pitched up or > down relative to the earth's surface. > > I imagine that the problem is fairly obvious to people with a basic > knowledge of geometry and trig, but unfortunately, I am not one of > those people. I would be very grateful for someone could reply with > an adaption of the above equation integrating theta. A simple adaptation doesn't really work. Using the variables as you've defined them, and taking theta to be positive for pitched up, write Hc = atan2(a, b) with a = cos(phi)sin(Hm)cos(mu) - sin(phi)cos(theta)sin(mu) - sin(phi)sin(theta)cos(mu)cos(Hm) b = cos(theta)cos(Hm)cos(mu) - sin(theta)sin(mu) I'd appreciate it if someone would check my matrix multiplication (Euler rotations), but I'm pretty sure this is correct. It reduces to the equation you gave for the case of zero pitch (theta = 0). The way to solve this problem is to imagine not that you're changing the attitude of the plane, but that you're changing the orientation of the vector instead. So you start with the plane heading magnetic north; the plane's aligned with the B vector in the XY plane (+X = east, +Y = north) but the vector has a -Z component. Rotating the plane to a magnetic heading Hm is equivalent to rotating the XY components of the B vector counterclockwise Hm. Then pitching the plane up/down corresponds to rotating the YZ components of the vector. Then banking the plane corresponds to rotating the XZ components of the vector. You have to do it in this order. I first tried it by creating the state described on the web page you gave (plane at magnetic heading Hm, and banked). I then tried to apply the pitch. But that won't give you the right answer because pitching the plane up and down in its own reference frame won't correspond to what we call pitch since the plane is already banked. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpBGhx0JxHeH.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem
On Wed, 03 Nov 2004 17:25:16 +0100 Boris Koenig <[EMAIL PROTECTED]> wrote: > David Megginson wrote: > > On Wed, 3 Nov 2004 15:36:33 + (UTC), Martin Spott > > <[EMAIL PROTECTED]> wrote: > > > > > >>Explaining in pictures is easier than dealing with single-line- > >>equations :-) We'll see, > > > > > > Multiple, sequential equations are welcome as well. Anything, really > > ... > > Could you go into detail about what kind of compass/error we're > talking ? The link that he gave goes into it in detail. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp3oE2zfBMM9.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiheaded video cards?
On Tue, 02 Nov 2004 12:37:40 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > I periodically get asked about multiheaded video cards for FlightGear. > My standard answer is that I don't know for sure, but I suspect they > wouldn't work well for FlightGear. However, the questions keep coming > and I feel like I'm not able to give a really good answer. > > So can anyone help me out? For instance, has anyone tried one of these > sorts of cards? > > http://www.matrox.com/mga/products/parhelia/series.cfm > > What kind of opengl support is available under linux? I haven't used these cards. However, the card I used before the one I have now was the immediate predecessor to the Parahelia, the Matrox Millenium G550. It was equipped for multihead, but I never used it. What I can tell you, though, is that DRI and OpenGL support for Matrox cards under Linux sucks rocks. First of all, Matrox' drivers are open, and their proprietary HAL module doesn't really buy you anything, so you'd naively think to be in good shape. Wrong, though. As of early summer, Matrox was not actively maintaining their Linux drivers. The G series and Parhelia series forums at forum.matrox.com are filled with complaints, requests for driver updates, etc., with no real responses. See this thread: http://forum.matrox.com/mga/viewtopic.php?t=10864&highlight= for just a taste. There's a lot more there too. Personally, I had constant hard lockups requiring a full system reset, with lots of DMA idle timeout messages to my X log, whenever I tried flightgear for very long with the Matrox card. From other messages in the Matrox forums, and the DRI/X.org/XF86 mailing lists and bugzillas, that wasn't so unusual. Well, since their drivers are open, maybe someone else can fix things? Unfortunately, at least up until late summer (when I gave up on Matrox), the contributors to the DRI project responsible for working on the Matrox drivers weren't active, and nobody else was picking it up. Matrox bug reports were getting acknowledged but no one was working on them. Furthermore, Matrox doesn't provide a Linux-compatable OpenGL, so you have to use the Mesa libs. That isn't really such a bad thing compared to the issues above; but if the difference between nVidia's libGL and the Mesa libGL are indicative, it's another performance hit. I don't mean to knock Matrox completely. I think their 2D performance is absolutely fantastic. But they're a bad choice for 3D work even under Windows, so I'm told; while from personal experience, they're awful for 3D under Linux, and they really don't seem to care about it. Their response to questions on the topic is often simply "we're sorry, but OpenGL is unsupported under Linux." No info re: your other questions, which were the meat of your post, I know, sorry. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgps4LY9e50B3.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On Tue, 26 Oct 2004 19:08:23 -0700 Curtis Olson <[EMAIL PROTECTED]> wrote: > Chris Metzler wrote >> >>I'm wondering whether we know what the X-Plane format really *is*. >> > > Robin does a pretty good job of documenting his format on his website. Sorry, I wasn't clear. I knew that; I know/knew what the format is now. What I was trying (apparently poorly) to say was that I was getting the impression that that formatting was about to change. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpp4QCHNPs8S.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
On Fri, 22 Oct 2004 17:11:18 +0200 Frederic Bouvier <[EMAIL PROTECTED]> wrote: > Quoting Martin Spott <[EMAIL PROTECTED]>: >> >> Now, here comes the next feature request > > Speaking about feature requests, do you considered using libcurl instead > of wget to fetch images ? That would remove those ugly console popup on > windows. > > I will see what I can do in this direction. The fetch option show me a > bunch of interesting possibilities for fgsd. It's funny you should mention this. Just last night, I finally got some time to build fgsd with CGAL, and built it with no problem. The task I first wanted to try it out on -- fixing the river edgelines around KDCA and the DC monuments -- was one for which I have no topo map. So I started looking online for suitable aerial images from which to draw the riverbank path, when suddenly the light bulb went on -- I can use TaxiDraw's fetch to make me some images for use in fgsd. It worked great. Incorporating the ability to fetch images into fgsd would be cool. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp2ArZWNXPL7.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
On Thu, 21 Oct 2004 18:26:15 +0200 Erik Hofman <[EMAIL PROTECTED]> wrote: > > > Has anybody got TaxiDraw 0.2 to compile? I got problems compiling it > with gcc 3.3 (IRIX and Linux) and MIPSpro (IRIX). For some off reason I > could probably get MIPSpro to compile it if I was able to get wxwindows > to (later than version 2.3.3) to compile, but gcc gives me all kinds of > errors (both IRIX and Linux). I compiled the most recent one (0.2.2) under Linux just fine. With gcc-3.3, it looks like. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpytfM8J4Bkh.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Other segfaults -- the same? (was Re: segfault in AI code)
On Thu, 21 Oct 2004 15:55:24 +0100
"David Luff" <[EMAIL PROTECTED]> wrote:
>
> Uggh, that's me in the firing line then! I haven't added any features
> or code to the AI-traffic system for quite a while, probably pre-0.9.5.
> I thought I had all the bugs worked out, but it seems not :-( It's been
> switched off by default for the last couple of versions so I guess
> that's why it hasn't been generating complaints before. Can you get a
> backtrace?
Here's what I see from gdb . . .
(gdb) run
Starting program: /home/cmetzler/Projects/FlightGear-0.9/source/src/Main/fgfs
--enable-fullscreen --prop:/environment/params/real-world-weather-fetch=true
--airport=KDCA --offset-azimuth=45 --offset-distance=7.0 --altitude=4000 --vc=100
--heading=0
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 3690)]
Failed to find runway 28R at airport KDCA
[New Thread 32769 (LWP 3693)]
[New Thread 16386 (LWP 3694)]
Object PanelInstruments not found
Object ControlsGroup not found
[New Thread 32771 (LWP 3696)]
[New Thread 49156 (LWP 3697)]
Altitude = 74
Temp at alt (C) = 11
Temp sea level (C) = 11.1425
Altitude = 74
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.0148
Trim Results:
Angle of Attack: 0.44 wdot: 9.13e-06 Tolerance: 1e-03 Passed
Throttle: 0.75 udot: 8.47e-02 Tolerance: 1e-03 Failed
Pitch Trim: 0.22 qdot: 4.09e-03 Tolerance: 1e-04 Failed
Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 126 average: 2.07 successful: 57 stability: 3.96
udot: 1148 average: 18.82 successful: 1 stability: 14.47
qdot: 121 average: 1.98 successful: 61 stability: 4.26
Run Count: 22370
Altitude = 15
Temp at alt (C) = 12
Temp sea level (C) = 12.029
Altitude = 15
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.003
Error: base = 0,858.14 course = 0.881677 dist = 8.88574e+06
Error: base = 0,-1099.45 course = 4.56981 dist = 8.88574e+06
Error: base = 0,857.26 course = 0.881679 dist = 8.88573e+06
Error: base = 0,-1099.45 course = 4.56981 dist = 8.88573e+06
Error: base = 0,857.261 course = 0.881681 dist = 8.88572e+06
Error: base = 0,-1098.97 course = 4.56898 dist = 8.88294e+06
Error: base = 0,855.813 course = 0.880004 dist = 8.88294e+06
Error: base = 0,-1098.97 course = 4.56898 dist = 8.88294e+06
Error: base = 0,855.808 course = 0.880004 dist = 8.88294e+06
Error: base = 0,-1099.38 course = 4.56978 dist = 8.88522e+06
Altitude = 74
Temp at alt (C) = 11
Temp sea level (C) = 11.1425
Altitude = 74
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.0148
Altitude = 15
Temp at alt (C) = 12
Temp sea level (C) = 12.029
Altitude = 15
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.003
Altitude = 280
Temp at alt (C) = 11
Temp sea level (C) = 11.5399
Altitude = 280
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.056
Altitude = 15
Temp at alt (C) = 12
Temp sea level (C) = 12.029
Altitude = 15
Dewpoint at alt (C) = 11
Dewpoint at sea level (C) = 11.003
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3690)]
0x080b0705 in FGTower::ProcessDownwindReport (this=0xd041ee8, t=0xd87d8c8)
at AIPlane.hxx:80
80 inline PatternLeg GetLeg() {return leg;}
(gdb) backtrace
#0 0x080b0705 in FGTower::ProcessDownwindReport (this=0xd041ee8, t=0xd87d8c8)
at AIPlane.hxx:80
#1 0x080af97c in FGTower::Respond (this=0xd041ee8) at tower.cxx:520
#2 0x080aee7d in FGTower::Update (this=0xd041ee8, dt=0.17272)
at tower.cxx:356
#3 0x0808d428 in FGATCMgr::update (this=0x98727e0, dt=0.034546)
at stl_list.h:167
#4 0x08052e20 in fgMainLoop () at globals.hxx:278
#5 0x08083dc5 in GLUTidle () at fg_os.cxx:114
#6 0x400a9c67 in glutMainLoop () from /usr/lib/libglut.so.3
#7 0x08054bd5 in fgMainInit (argc=9, argv=0xb570) at main.cxx:943
#8 0x0805166d in main (argc=0, argv=0x0) at bootstrap.cxx:185
HTH.
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear
pgpkRWhsT03So.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Other segfaults -- the same? (was Re: segfault in AI code)
On Thu, 21 Oct 2004 09:06:14 -0500 David Culp <[EMAIL PROTECTED]> wrote: >> >> Just downloaded a fresh CVS FlightGear and found that the AI code is >> causing segfaults now. I'll recompile and run it through gdb. In the >> mean time beware that some aircraft that set up AI scenarios by >> default, like the T-38 or the hunter-2tanks, are crashing the sim. > > I've run it through gdb and didn't get any useful output. After a few > hours of detective work with cout's I'm getting this: > > [EMAIL PROTECTED] bin]$ ./t38 > FGPropertyManager::GetNode() No node found for fcs/throttle-cmd-norm[0] > Creating new property > FGPropertyManager::GetNode() No node found for fcs/throttle-cmd-norm[1] > Creating new property > Starting FGAIManager::bind() > Finished FGAIManager::bind() > Creating new scenario: refueling_demo > Creating an AIAircraft > Created an AIAircraft > Scenario has been processed. > ./t38: line 24: 662 Aborted /home/dave/bin/fgfs > $cmdline > > > > The sim is crashing before the first call to FGAIManager::update(), > however the init() is working fine, and the scenario gets processed and > an AI aircraft is created properly. AFAIK the AI subsystem doesn't do > anything else between bind() and update(), so the property system (as > pointed out by Fred) might be a good place to look. Hmmm. I was having a problem that I was starting to write up the night before last, until I saw your post. I thought it was the same problem, and you'd reported it. But now I'm beginning to wonder if they *were* the same problem. I get the impression from the above that your segfaults are occuring promptly, at the beginning of the scenario. I'm getting segfaults that seem related to the AI subsystem. They occur when I turn AI traffic on through the menu. They seem more frequent as I turn the AI traffic density up from 1 to 3. But they don't occur promptly upon start; instead, they almost always occur when I'm on final for a landing. --log-level=debug shows no useful messages -- there's just an abrupt end. But if I don't enable the AI traffic, I don't get the segfaults. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpzeOeBaGdJt.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw and choice of images from terraserver-usa
On Thu, 21 Oct 2004 10:24:45 +0200 Boris Koenig <[EMAIL PROTECTED]> wrote: > > Chris Metzler wrote: > > [...] > > The "Urban Areas"/"T=4" dataset is fabulous, btw -- it goes down to > > 25cm resolution (TaxiDraw fetches 1 meter resolution images, it > > appears). I'd recommend just changing fetch.cpp to "T=4", and getting > > the highest resolution images available; but not all areas are covered > > by the better dataset. That's why I'm recommending tests -- try to > > fetch from the higher resolution dataset, and drop down to the > > lower-res one if the first fetch fails. > > LOL, sounds as if Chris has hacked terraserver.com to provide him with > their payware imagery for free ;-) Oh man, I don't know if I explained this well enough. The stuff on terraserver-usa.com (as opposed to terraserver.com -- same company, different website), including the images I fetched, are all free through the web interface. Try it out with the browser of your choice; you'll see it all just by clicking on links. Before, terraserer-usa only had one dataset of free aerial images. Now they have a second, which improves coverage in U.S. urban areas. > Did you also try numbers greater than 4 ? :-) > > And I don't even mention what their logs are going to look like if > Chris adds your "brute force" method of trying to look for available > images :-) Heh. But again, I wasn't fishing for available images by tweaking the URL Dave uses in TaxiDraw. These images are available normally, through normal use. There was no detective work on my part in finding the images, because they provide them to you with nice informative links. The only thing I did was figure out how to get fetch.cpp to draw from the new dataset instead of the old one-- something that would have been trivial for anyone who knows c++ (but I don't). -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpNmgN3Kj8B6.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] TaxiDraw and choice of images from terraserver-usa
Hi Dave (and anyone else interested in this), There's one other request I'd make of TaxiDraw at this point. Is it possible to revisit fetch.cpp, the routines that fetch background images from terraserver-usa.com, and tweak it to enable fetching of better images when terraserver-usa has them available (which, for large city airports, is almost always)? Here's the problem I'm running into. I brought up the raw data for KSDF, an airport with which I'm very familiar, and sent TaxiDraw off to get a background image from terraserver-usa. It returned with an image that's at least eight years old, with an incorrect number of runways, wrong apron location and runway/taxiway layout and so forth. http://www.speakeasy.net/~cmetzler/KSDF_t1fetch.jpg It's not merely a misalignment problem -- our data for 11/29 is aligned correctly with the image, but the two 17/35 runways aren't present in the image at all. It's an old image, predating a lot of changes and improvement, and it's no surprise that the runway and taxiway layouts are way off. So I went off to terraserver-usa's website and clicked through Advanced Find --> Place --> "Louisville, KY, USA". I then find that they have a direct link to aerial images of the airport, from two separate datasets. One, a dataset labelled "Aerial Photo 6/6/1996", is clearly where TaxiDraw got its info. But another dataset present, labelled "Urban Areas 4/7/2002", is not only more current but goes down to much higher resolution. I picked a point feature at the airport, zoomed down to the same resolution using each of the two datasets, and looked at the URLs for the two images I got. I found that they were exactly the same except for "t1" in the old image, and "t4" in the newer image. Looking in fetch.cpp, I see this: }string urlroot = "\"http://terraserver-usa.com/tile.ashx?";; }string scale = "S=10"; }string scale2 = "S10"; }string type = "T=1";// Not actually sure what this is - type is a guess }string amper = "&"; I don't know C++ at all, but on a hunch I changed that to "T=4", and bingo: TaxiDraw fetched and built an image from the newer dataset. http://www.speakeasy.org/~cmetzler/KSDF_t4fetch.jpg I suspect that the "T" in the image URLs refers to dataset. And what I'm wondering is whether fetch.cpp can do a test to see if "T=4" data is present and use it if so, or drop to "T=1" data and use that if not. The URL change seems to be stable. Here's what I got for KDTW, with "T=1" -- it fetched old data, missing an entire runway as well as a ton of apron/taxiway that's now present: http://www.speakeasy.org/~cmetzler/KDTW_t1fetch.jpg hacking fetch.cpp to "T=4" fetched a newer image, showing the new runway, its taxiways, the completed new terminal and its apron, and so on. http://www.speakeasy.org/~cmetzler/KDTW_t4fetch.jpg The "Urban Areas"/"T=4" dataset is fabulous, btw -- it goes down to 25cm resolution (TaxiDraw fetches 1 meter resolution images, it appears). I'd recommend just changing fetch.cpp to "T=4", and getting the highest resolution images available; but not all areas are covered by the better dataset. That's why I'm recommending tests -- try to fetch from the higher resolution dataset, and drop down to the lower-res one if the first fetch fails. Would it be possible to implement something like this? The complicated airports are much easier to handle with more current, higher-resolution imaging; and since the complicated airports tend to be in/near big cities, those are just the ones for which the better images will likely be available. Anyway, just an idea . . . -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpkc6uxJEYSc.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On Wed, 20 Oct 2004 11:12:11 +0100 "David Luff" <[EMAIL PROTECTED]> wrote: > On 10/19/04 at 11:57 AM Chris Metzler wrote: > > Well, I guess we'll find out eventually. Converters are easy to write, > if somewhat tedious. The current X-Plane format contains a flag > indicating whether to include runway distance remaining signs or not, so > the change to it should be good for you in that respect. Yeah, I'd read his specification before, and I don't know how I didn't notice that in there before you pointed it out. I can be pretty oblivious sometimes. It'd be really nice if info was provided on the *method* used to place the signs (there are three FAA standards for how to lay them out; I presume things are similar to one or more of them elsewhere than the U.S., but really have no idea). > I think that your idea to put a taxiway designator in the 'xxx' (bet > this message gets flagged as spam now!) HA. > part of the record is an > excellent one. The downside of course is that it would require X-Plane > itself to understand it before it could be applied to the master > dataset. Well, yes and no. We could collect this data, but not include it in the upstream updates until they do have the ability either to understand it or to at least ignore it when it's present (that is, they could consider anything other than "xxx" as "xxx"). > On the other hand, genapts could be made to understand it as > an extension to the default format. And in the short term, similar to above, genapts could be made to simply ignore that field -- it shouldn't need it now anyway since the "T" identifier in the first column of the record in runways.dat identifies the record as referring to a taxiway. The "xxx" isn't used for anything, is it? So it should be harmless to put info there; if genapts really does care about what's in that field, I'd naively think it wouldn't be too hard to just have it ignore that field for now. Then we could collect this data as we get it. > And if as you say the X-Plane > format is likely to contain it soon then that's excellent. Well, I dunno what "soon" is; you know how this can go. Robin Peel says: } Enhancements to the X-Plane airport and nav-aid data that are currently } under development (and to be available in X-Plane 7.x or 8.x) include: } [ snip ] } } * Completely revised airport data file (apt.dat) that will allow many } new features, such as smoothly-curved taxiways, polygonal aprons, } airport boundary fences, enhanced taxiway markings (centre lines and } lights, edge lines), taxiway signs, and many other goodies. . . .which suggests the taxiway idenfication info will be in there in some form, either as labels on the records or as fixed signs (like the beacons or windsocks). In the latter case, it'd be possible to infer taxiway identifiers, albeit with some work. > What I suggest is that the TaxiDraw project file be allowed to keep > extra information such as this, perhaps in xml format. Then, when > exporting one can simply export the information relevant at the time for > the format exported to. One could possible generate the airport signage > directly from the TaxiDraw project files, or maybe by exporting the > extra data into the X-Plane data as an extension that genapts > understands. Once X-Plane format officially includes it, it can be > exported from the TaxiDraw project files into whatever format it uses to > understand it. I think this all sounds really good. > Some of the other issues you bring up in the archived post you mention > are similar to those that Paul Surgeon brings up in this thread - I'll > think about it and reply again. Cool. I have one other request that's specifically TaxiDraw related; I'll put it in another thread just to keep things straight. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgp9wULF26nKW.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DeHavilland Beaver
On Tue, 19 Oct 2004 13:00:12 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > Syd Adams just submitted a DeHavilland DHC-2 Beaver for inclusion in > CVS. > > I've had a chance to take it for a spin and it is really nice. It is a ton of fun. Does the flight modelling seem right to you? I went online and found a page that gives stall speeds for the Beaver of 40-55 knots; but in FG, the Beaver seems to stall for me below 80mph no matter what flaps or power. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpQok3Vhxmjp.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
