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] 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] 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] 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] 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] 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] 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
[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] 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
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] 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] 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: 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: 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: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: [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: [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] 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] 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
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
[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] 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] 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] 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?
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: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 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?
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] 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] 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?
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] 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, 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] 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 status 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] 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] 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] 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] 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] 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
[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 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=9atid=125func=detailaid=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] 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 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] 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
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] 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
[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] 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
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
[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 scale 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 @@ chunk typenumber-value/type property/velocities/vertical-speed-fps/property + scale60/scale format%6.0f/format /chunk /chunks @@ -387,7 +388,7 @@ chunks chunk typenumber-value/type - property/instrumentation/dme/distance-nm/property + property/instrumentation/dme/indicated-distance-nm/property format%6.1f/format /chunk /chunks -- 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] ..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] 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: consumables fuel tank n=0 ! level-gal_us archive=y1540/level-gal_us /tank tank n=1 ! level-gal_us archive=y1540/level-gal_us /tank tank n=2 ! level-gal_us archive=y0/level-gal_us /tank /fuel /consumables to consumables fuel tank n=0 ! level-gal_us archive=y149/level-gal_us /tank tank n=1 ! level-gal_us archive=y149/level-gal_us /tank tank n=2 ! level-gal_us archive=y149/level-gal_us /tank /fuel /consumables . . .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] 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
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 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
[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] 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
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
[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
[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] 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
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
[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] 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
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] 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] 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] 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] 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=4958PN=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] 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 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
[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, 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] 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, 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 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] 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=10864highlight= 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] 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] 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] 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] 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
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] TaxiDraw-0.2.2 released
Hi Dave. This is great work. Seriously, it's a fabulous contribution, and I'm pumped to get started using it. I have a couple of quick questions: Version 0.2.2 fixes several serious bugs in the X-Plane format writer present in 0.2.0 and 0.2.1. All users should upgrade, since X-Plane format is becoming the default format for FlightGear in the very near future. I'm wondering whether we know what the X-Plane format really *is*. Since the beginning of September, Robin Peel has been saying that a new set of files are coming out next weekend, September 18. But he also says that these files won't work at all with earlier versions of X-Plane. That may simply be because of the new information content in fields that were basically dummy (see below) choking reads that don't know how to handle them; but it made me wonder if there's a file format change coming up. At the very least, his comments about being able to declare aprons separate from taxiways suggest a new record type. On a related note, since the X-Plane files are apparently going to support this soon, is there any possibility of being able to label taxiways with identifiers (e.g. taxiway A)? I know that right now, we don't do anything with that information; but we might in the future, with sign placement or ground control instructions or whatever, and if people have that information and the opportunity to add it to the database, we might as well, rather than having to go back and add it later. Something along these lines (re: taxiways and aprons): http://baron.flightgear.org/pipermail/flightgear-devel/2004-July/029106.html Finally, I'm wondering how you're going to handle conflicts between future X-Plane data releases, and changes that people have sent to you. For example, suppose an FG user sends some changes to an airport to you; and suppose some X-Plane user sends some changes to the same airport to Robin Peel (or the DAFIF changes for that airport). The next X-Plane dataset contains the changes that Robin Peel received, which are different from the ones you have. How would that get resolved? Go with theirs? Go with ours? Contact the person who sent you changes to review the situation and update? Thanks muchly. And thanks again for TaxiDraw! -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 pgpUU2HyF4GW3.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
On Tue, 12 Oct 2004 21:27:54 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: Forgot the Dlist patch that was posted on the list by Erik and get the all new 0.9.6 or CVS Now I'm a bit confused (again!). I thought that Erik's patch, like Matthias', was a patch to plib. I saw a bunch of CVS commits for SimGear and FlightGear relating to his patch; but they looked like they were merely efforts to determine whether one was using a plib that had the patch in it or not. And over on plib-devel, I saw Erik discussing a patch with Steve Baker that I thought was the final version of the DList patch, http://sourceforge.net/mailarchive/message.php?msg_id=9755451 after Horst Wobig fixed what he thought (and Erik seemed to agree) was the problem. http://baron.flightgear.org/pipermail/flightgear-devel/2004-October/031161.html So I would naively think that in addition to fetching the latest SimGear CVS, one still needs to patch it into plib. Where am I mixed up here? -c -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- 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 pgpJYYSvJyYDN.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] How is property /position/ground-elev-m assessed/constructed from the elevation data?
Hi. Is there something other than what I'd expect done in determining the value of the property /position/ground-elev-m ? Is it taken from the terrain point immediately below the aircraft; or below it in some cone of some angular size, or something like that? I ask because at fixed lat/lon, the value you get for this property depends on the altitude you're at when you check it. If you're at 16,000 feet and you check this property, the value you get is different from if you're at 5,000 feet over the exact same lat/lon. The difference is normally not that large -- a few centimeters, typically. But sometimes it's a meter or more. This matters for e.g. scripts used to place scenery objects that move from point to point around the landscape and measure this quantity through the telnet interface, such as what Curt's written and what Jon and I are using. In my case, one out of a hundred or so airport signs is half-buried or slightly levitating . . . -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 pgphxOc8CF33u.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
On Fri, 8 Oct 2004 10:59:36 + (UTC) Martin Spott [EMAIL PROTECTED] wrote: Mathias Fr??hlich wrote: flightgear-devel This patch is great - it works and it significantly increases the frame rate on a simple Linux-PC (old 600 MHz PentiumIII with Radeon9200) from 4-5 to 7-8 fps on the default location, OK, well, I have gotten away with using the current stable release of plib with my CVS simgear/flightgear for quite some time (not wanting to have to deal with plib's insistance on being in /usr/lib, and not wanting to prevent having both CVS FG and Debian's stable packaging of FG installed). But I may have to bite the bullet here, since framerates are the single biggest subject about which I wish I knew enough to contribute to FG. -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 pgpXTlMg1dqjx.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
On Fri, 08 Oct 2004 19:38:29 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Chris Metzler wrote: OK, well, I have gotten away with using the current stable release of plib with my CVS simgear/flightgear for quite some time (not wanting to have to deal with plib's insistance on being in /usr/lib I've plib installed in /opt on my O2 and in /usr/local on my PC for quite some time now. Doesn't the following work for you: configure --prefix=/usr/local --libdir=/usr/local/lib Most likely when I tried it before, I was a neophyte about passing arguments to configure. -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 pgpUnyq7dL4S5.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ESR's Smart Questions (was ATLAS ? (navaids *symbols* ?))
On Mon, 27 Sep 2004 19:40:50 +0200 Boris Koenig [EMAIL PROTECTED] wrote: Chris Metzler wrote: On Mon, 27 Sep 2004 12:01:06 -0400 Norman Vine [EMAIL PROTECTED] wrote: OK here you go :-) http://www.catb.org/~esr/faqs/smart-questions.html#volume Completely independently of this conversation right now, lol, Norman: we scared him ! :-) Not exactly; I just don't have anything useful to add to that topic. I'd just like to give my opinion that this document is, for participants in mailing lists and Usenet newsgroups, absolutely 100% essential reading. agreed, at least if they are new to online discussions ... Actually, I think it's useful period. I first read it years ago; but still today, when I post things, I often do so while looking at that document, trying to see how I can make life easier on my readers. People get guided to it a lot on the debian-user mailing list -- because even when simply asking questions of other users, following the ideals set out in this document make things better for everyone involved, including oneself. Are you indirectly suggesting to add references to these documents to the FlightGear mailing list webpage on flightgear.org ? :-) Of course not. It'd likely be of value, sure; but so would a lot of other things, and everybody's really busy, and that's bound to be comparatively low on anybody's priority list. If I start making lots and lots and lots of suggestions to other people about things that they should go and do -- no matter how good my ideas are -- it's going to get really annoying. -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 pgpq70EhWCULV.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATLAS ? (navaids *symbols* ?)
On Sat, 25 Sep 2004 14:18:20 +0200 Boris Koenig [EMAIL PROTECTED] wrote: This might be worthwile to consider for the Atlas developers: they would merely have to use FlightGear's navaids database and fetch the positions of navaids, and OPTIONALLY display their symbols at the corresponding position within the map. I'm confused. Other than just that the symbol is different, how is this different from what Atlas already does? It already uses nav.dat to place VORs (with radials), NDBs, etc. on the map, at their correct locations, at the user's option. I use it all the time for FG pre-flight planning . . . -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 pgpBwP1pcZoBq.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VIRTUAL ATC: a feedback from IVAO (A voice for FG)
On Fri, 24 Sep 2004 21:14:56 +0200 Boris Koenig [EMAIL PROTECTED] wrote: Hi ! I have just received a reply from IVAO's 'chief developer' - as soon as he says that it's okay to post his reply to this list, I'm going to post the full text. However, in summary: they would support an opensource client for their network, PROVIDED that their rules are respected, ***BUT*** they DO NOT want to publish their protocol specs, because of security issues they had in the past, so what they're trying to do is to provide security by hiding the details of the exact implementation (pretty Micro$oft-like). I _interpreted_ their reply like that: they would provide a binary library that we could link 'our' client/FG to. But the protocol would still be theirs, and not known to us. One solution to these sorts of issues is that taken by the Netrek folks of years past. The Netrek clients, the Paradise Netrek clients, etc., were open source. You could do with them whatever you wanted, and their protocols for passing data back and forth with the server were thus obvious. However, in order to avoid people hacking their clients to give their ships superpowers in the networked multiplayer games, they restricted access to their servers to only blessed clients -- clients that successfully passed an authentication procedure (e.g. signed md5sums of themselves which match keys and md5sums on file) Hacking the source will cause the client to fail the authentication, and the server won't accept its connection. This didn't violate the GPL -- you could do whatever you wanted with the source, and you could always set up your own servers (using available source) with no such restrictions on blessed clients. They merely were setting restrictions on who they were going to provide *their* server connections to. -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 pgpannWboVpPO.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
