Re: [Flightgear-devel] link to my homepage
On Sat, 22 Jan 2005 16:43:13 +0200, Paul Surgeon [EMAIL PROTECTED] wrote: I say pull the package in question. If the author wants to distribute it on his own site then that is fine with me but as it stands it looks like we endorse what is in that package. I'd rather upset one contributor than piss off the whole FG community. Let's take this whole discussion offline, guys -- it has become a bit silly. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Taking a break
I'm going to be taking a short break from the FlightGear, SimGear, and TerraGear mailing lists to help me focus on finding new customers to build up my XML consulting business back up (and to do lots of real flying, of course). I'll still be using FlightGear for practice and I will keep up to date on the CVS and read the announce lists. I expect that I won't be gone long -- likely weeks, and maybe a few months at worse -- and if people have any problems with or questions about my code chunks, I'll be happy to discuss them by private mail. I'll try to devote some time to my 3-D models while I'm away, especially the Warrior and the J3 Cub. Thanks, and all the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Rain and snow videos or photos
On Fri, 21 Jan 2005 14:33:37 +, Dave Martin [EMAIL PROTECTED] wrote: But I think the main problem will be simulate drops on wind screen and windscreen wipers. My question here: When does pilots use them(whipers)? only on take-off and landing or on route too? Thanx in advance Most light-aircraft are not fitted with wipers and instead rely on direct airflow from the prop (SEP) or often on multi-engine they have a ducted air-blower but this is mainly for keeping the screen clear of ice regardless of the aircrafts known-icing clearance. Just as Dave said. I'd also like to add that there's no such thing as drops on the windscreen in flight -- you're going way to fast for that, even in a slow plane like the 172 or Warrior (even my Warrior cruises over 230 km/h. Extremely heavy rain can sheet over the windscreen, but normally, the drops just follow the boundary layer around the outside of the cabin and appear to fly past horizontally at high speed (snow can be very dramatic that way, with the sun reflecting off each flake as it flies by). On the ground, water drops on the window of a single engine plane often run upwards, from towards the top of the windshield, because of the prop blast. All the best, David -- http://www.megginson.com/ ___ 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 21:38:49 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: I would tend to agree with you with one exception. The default C-172 is very functional, but it is not our best model. A nice thing about including multiple aircraft is you can see some different nice things that can be done with FG aircraft. I think before we go with only 1 aircraft in the base package, we should really spiff up the C-172 externals and internals. Suspention animation, shadows, lights, and a much better 3d cockpit. If we go with only one aircraft, it should be really nice all around, and show off what we can do in FG. That sounds reasonable. For my own part, I'll see if I have time to do more work on the Cherokee/Warrior, which would be a reasonable alternative starter plane (as would any other trainer, such as the Cessna 150/152, Beech Musketeer, or even Diamond Katana, if anyone is interested in building one of those). The J3 Cub is probably the most famous trainer in history, but the tailwheel ground handling is too hard for most new users to manage. All the best, David -- http://www.megginson.com/ ___ 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 Thu, 20 Jan 2005 14:42:40 -, Jim Wilson [EMAIL PROTECTED] wrote: Probably I've got this wrong, but isn't the c-172 our most refined/realistic flightmodel? My impression of yasim, from using it for the p51d, but not as an aero engineer, is that getting an aircraft working is about 2 parts theory and 1 part voodoo (the part that the basic formulas don't cover). Actually, I'd say that the two are roughly equal in realism: JSBSim can use real, measured flight coefficients when they exist (most of the time we have to make them up right now), but it is stuck at a high level of abstraction because it can apply its calculations only to the aircraft as a whole; YASim cannot use real coefficients, but since it handles each lifting surface separately, it works at a lower level of abstraction can handle various asymmetric situations much more believably (for example, JSBSim can model a stalled plane, but YASim can model a stalled *wing* with the other wing not stalled). After working a lot on and flown a lot with both models, I find the handling of the YASim pa28-161 more realistic than the handling of the c172p, though they're both good. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear 0.9.8, Mac OS X build
On Thu, 20 Jan 2005 18:35:53 +0100, Melchior FRANZ [EMAIL PROTECTED] wrote: 1. The responsible person should be asked to *immediately* remove the offending religious content. 2. If he refuses (which the GPL lets him), he should not be given any further support. He should be banned from the mailing lists. 3. The project should note on the homepage that it is in no way affiliated with and distances itself from any religious or other propaganda that is distributed together with FlightGear. Or alternatively, why not encourage free speech and send him several pamphlets with alternative viewpoints to include in the same distribution? That may be enough to convince him to pull his own without any threats. I have a vague recollection of a Simpsons episode where Springfield Elementary School decides or is forced to teach creationism as well as evolution, and (evangelical Protestant Christian) Rev. Lovejoy is furious when he finds out that his is only one of many religions invited in to speak (I might be remembering it wrong, though). All the best, David -- http://www.megginson.com/ ___ 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 Thu, 20 Jan 2005 20:06:13 +, Dave Martin [EMAIL PROTECTED] wrote: Is there any way to get a compensated 'TAS' output to drive the ASI because I *think* the B1900D's ASI is compensated (but I must check) I'd be pretty incredibly surprised to see an ASI doing that. Some ASIs do have a circular sliderule (or similar) around the edge to calculate true airspeed, but all ASIs necessarily show indicated airspeed because that's what has the most aerodynamic significance for the plane (i.e. it's going to rotate, climb, approach, stall, etc. at the same indicated airspeeds at 10,000 ft density altitude and at sea level, even though the true airspeeds are significantly different). What is the density altitude is the TAS for the Beech 1900 specified at? 25,000 ft? If so, then divide by about 1.5 to find out what number you should see on the ASI. All the best, David -- http://www.megginson.com/ ___ 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 10:02:20 +0100, Erik Hofman [EMAIL PROTECTED] wrote: Now that we have an aircraft download page I think that should be all that gets included. I just realized that the list didn't include any helicopter. All the best, David -- http://www.megginson.com/ ___ 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 14:07:22 -, Jim Wilson [EMAIL PROTECTED] wrote: Also I think I would have considered cutting the c310, even though it is the only light twin. The u3a cockpit was my very first 3D project and it really isn't too spiffy. It would be very nice to have a civilian c310 (maybe we should just repaint the u3a and call it a c310b?). Gotta keep in mind that we are still releasing the aircraft and it really doesn't pay to have a very large base package. In any case, I'll work on untangling the cross dependencies in the c310* folders. The C310 is of great historical importance for FlightGear -- when I started work on developing its flight model in JSBSim, we had no support at all for multi-engine aircraft, and it prompted a lot of significant architectural changes to both JSBSim and FlightGear. I think I might agree with Jim, though, that even though we should have a light twin modelled, neither of our C-310 models has seen enough TLC to justify throwing it at end-users. Perhaps leaving it out of the base package will spur one of us to put more work into it or to develop alternative light piston twin, like the Beech Baron, Piper Seneca, Piper Aztec, Cessna 340, etc. If we do include it, I also agree with Jim that it should be in civilian livery, not US military. I have no trouble with warbirds appearing in military livery, but there's no point going out of our way to show dual-use civilian/military planes that way, at least not in the default base package. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wed, 19 Jan 2005 19:26:57 +, Lee Elliott [EMAIL PROTECTED] wrote: I've got to disagree with you regarding linking to non-GPL'd aircraft. The best a/c I've seen for M$FS have been done by people who want to ensure that their work remains free (as in free beer) but also want to make sure that their work isn't exploited by commercial organisations. Some people also like to include non-violence conditions. I think the user community will stomp out that kind of thing pretty fast, whatever we do about linking. It looks very newbie and shareware-ish. All the best, David -- http://www.megginson.com/ ___ 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 20:05:18 +, Lee Elliott [EMAIL PROTECTED] wrote: I think the user community will stomp out that kind of thing pretty fast, whatever we do about linking. It looks very newbie and shareware-ish. Heh! - Sorry, but I'm not sure exactly which bits will get stomped out and/or are newbie and shareware-ish. Vanity licensing clauses. Outside of little shareware communities, the world pretty much wants some kind of standard open source license or public domain, or it shrugs and moves on -- it gets way too hard to keep track when n packages end up with n different kinds of licenses (OK, lets see: package #1023 is for non-violent use only, package #56 is for use only by Wiccans and those who agree not to persecute them, package #337 is banned for use in Israel, package #5529 is banned for use in the Occupied Territories, and package #18 is for use only by Ralph Nader supporters). All the best, David -- http://www.megginson.com/ ___ 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 22:36:42 +0200, Paul Surgeon [EMAIL PROTECTED] wrote: Then some scumbag comes along and collects a whole lot of these free contributions, removes the credits, labels them as his own work, puts them onto a CDs and sells them for $30 - 50 profit. This has happened several times (2 that I know of) in the MSFS community and the authors get irrate that someone is charging money and taking credit for what they freely gave to the community. Fortunately most of these works are copyrighted and not GPL and they managed to get lawyers involved and stop these pricks from carrying on their underhanded business. If the authors released their work as GPL those low lifes wouldn't even have to change the credits and what sort of recourse would the authors have then? I think you might be a bit confused: GPL works *are* copyrighted, and the copyright holder can still sue someone for removing credit or for violating the license in any other way. In the cases you mentioned, the people could just as easily have gone to court if the sounds had been GPL'd or LGPL'd. Personally, I'm a lawyer's son, so I know how unprofitable suing usually is (except for the lawyers); as a result, I sometimes prefer to abandon copyright claims altogether and simply make my work Public Domain, as I did with SAX. The GPL does not allow you to stop someone else for charging to redistribute your work, but it does require that person to let everyone else know where the work originally came from (i.e. where they can get the same thing for free). Many companies actually make a business out of the GPL by dual-licensing their own work -- release for free under GPL (which imposes certain restrictions on commercial use), then sell a commercially-licensed version of the same stuff without the GPL requirements. All the best, David -- http://www.megginson.com/ ___ 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 [EMAIL PROTECTED] wrote: If the authors released their work as GPL those low lifes wouldn't even have to change the credits and what sort of recourse would the authors have then? The authors would have no recourse then. Note that he said that the changed the credit to hide the origin of the sounds: that violates the GPL.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, so unless they're adding some other kind of value, they're not going to make any money. All the best, David -- http://www.megginson.com/ ___ 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:08:38 +, Lee Elliott [EMAIL PROTECTED] wrote: While it can make things difficult, or even impossible, one can't force people to use a licence. One can't tell people what to do... I don't think anyone has suggested that, except to set it up as a strawman to argue against. The only suggestion I've seen is using the flightgear.org web site to promote only models that are GPL or freer. I think that makes sense -- think of the extra, free publicity as a carrot for the people who are willing to go open source or better. As I mentioned before, I also think that the user community will vote for the open source models with its feet (or, I guess, mice) and tend to stomp out others with social pressure or at least apathy. All the best, David -- http://www.megginson.com/ ___ 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 Thu, 20 Jan 2005 00:20:57 +0200, Paul Surgeon [EMAIL PROTECTED] wrote: Sure GPL can work in some scenarios but if your market is 1000 copies and you charge $50 for your product you can't possibly afford to license your work as GPL and expect to keep food on the table for your kids to eat. Sure -- that's no problem. We're just talking about not giving them free advertising on flightgear.org, not about trying to ban them. All the best, David -- http://www.megginson.com/ ___ 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 10:53:33 -0500, Josh Babcock [EMAIL PROTECTED] wrote: I'd like to see a golden age or WWII multi engine, but I guess the DC3 isn't ready for prime time yet. I'm also *cough* working on a B29, but I haven't touched it in months. I was in the middle of getting a Yasim config working, after which I intended to put it out as an dev release. You know, after reading some of the other comments, I'm starting to like the idea of having just the c172p in the base package. 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. All the best, David -- http://www.megginson.com/ ___ 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 [EMAIL PROTECTED] wrote: c172, c172-le, c172p, c172r, c172x - I don't have the energy to sort out the dependencies so throw it all in. We should try to sort them out and include just the C172p by default -- in any case, you should be able to remove the c172-le, c172r and c172x without any damage (I think that all the dependencies are downwards on c172). Since that's three removed, it might be worth including a Cherokee (pa28-161), since it is the other common entry-level trainer at flight schools, and that way we'd have most student pilots covered. Do we have a glider that's well enough along to include? That seems to be one big gap on the list (I'd remove one of the military jets to make room, if you have to). It might also be nice to include the Sopwith Camel so that we have WW I biplane. All the best, and thanks for putting together the list, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] more google adds
On Sat, 15 Jan 2005 21:18:50 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: 1. No adds at all on the main/front page of our site. Adds only on the subpages. Pro: good first impression on new users; con: kills nearly all of your potential traffic. 2. I've had mixed results filtering out MSFS stuff, but that's mostly because there is a lot of it. I think if I continue to add sites to the filter rules, I can get most of them. The challenge is all their third-party and warez sites. 3. I'd like to leave the adds running for a couple days on a trial basis. If the consensus is that they are just too annoying or inapropriate we can take them down. Sounds good. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport codes (was Re: plib-1.8.4_RC)
On Sat, 15 Jan 2005 10:44:23 +0200, Paul Surgeon [EMAIL PROTECTED] wrote: The 3 letter FAA airport codes have been prepended with a K but they never used to be. e.g. C83 now equals KC83 Canada has done that officially -- all Canadian airport codes are now four-letter ICAO codes starting with 'C', even the ones for tiny grass strips or floatplane bases. The last I checked, though, the US had not yet done the same (even though it owns the prefix 'K', so could easily do so with no conflicts); only the airports that had proper IATA codes now have ICAO codes, as far as I can tell. Robin's database should use ICAO codes where available, of course; sooner or later, the US will switch over all its airports officially, so KC83 will be a real identifier, but they're not quite there yet. http://en.wikipedia.org/wiki/IATA_airport_code http://en.wikipedia.org/wiki/ICAO_airport_code All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C++ question
On Sat, 15 Jan 2005 15:12:57 +0100, Christian Mayer [EMAIL PROTECTED] wrote: But I only want class A to be an interface that tells everybody what to expect from it's derivated classes. And one of these things is, that every child must have a member that is called foo and has one parameter of the type of the child itself. How do I achieve that? You'll have to start messing around with templates -- it won't be too clean, though. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Any info for Chalgrove UK?
On Fri, 14 Jan 2005 20:59:23 +, Dave Martin [EMAIL PROTECTED] wrote: I then spent 2 hours trying to work out what this huge 3 runway centre-intersecting airport with full runway lighting and PAPIs was. ;-P It looks like the runways are fairly large in real life as well: http://worldaerodata.com/wad.cgi?airport=EGLJ Martin Baker uses the airport for testing ejection seats, and flies a Meteor jet out of it (that would explain why one runway was extended to 6000 ft): http://groberson.members.beeb.net/Chalgrove_Airport.htm I haven't downloaded that scenery, but the fact that the runways intersect in the middle suggests that we have the centre LAT/LON for the airport rather than for the individual runways. I haven't been able to find any information about lighting, but I wouldn't be surprised to see a VASIS or PAPI with the jet there. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Real weather fetch
On Wed, 12 Jan 2005 12:18:18 +0100, Melchior FRANZ [EMAIL PROTECTED] wrote: For that you would need METAR sets for several stations and for several moments in time. It would have to support recorded weather for a flight from, let's say, KSFO to KJFK. I don't see a way to integrate something like this in fgfs. No biggie -- I used to do it in MSFS all the time. You can download all the world's METARs as one big file. Just specify the file you want, and you're good to go (and either change it every hour, or teach FlightGear when to look for the next one). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Real weather fetch
On Wed, 12 Jan 2005 15:01:28 +0100, Melchior FRANZ [EMAIL PROTECTED] wrote: * David Megginson -- Wednesday 12 January 2005 14:34: You can download all the world's METARs as one big file. Where? noaa.gov? ftp://weather.noaa.gov/data/observations/metar/cycles/ All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Real weather fetch
On Wed, 12 Jan 2005 15:53:31 +0100, Melchior FRANZ [EMAIL PROTECTED] wrote: Thanks! I'll let the metar proxy download the requested files from there to $FG_HOME/metar/day/[0-9][0-9]Z.TXT and serve the most appropriate metar data string to fgfs via the normal NOAA lookup mechanism (via HTTP). One has then only to start fgfs with a time for which the cache has METAR data available, and there we go. :-) There's one gotcha -- the file for the current cycle is usually incomplete (the file grows as reports are collected), so you always want the previous one as a backup. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Properties under /orientations seem to have taken on offsets after extreme attitude
On Mon, 10 Jan 2005 21:12:05 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: This is actually a real feature. Your extreme manuevers have discombobulated your attitude indicator and it takes several minutes for the gyro to realign itself with gravity. In aerobatic planes, it's possible to cage the gyros during maneuvers to avoid this problem -- that's something we'll want to support eventually. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Google rankings
I may not have a lot of readers, but my aviation blog is still the #1 search result for the phrase land and hold short on Google, pushing aside more worthy pages like ones from AOPA and the FAA that actually talk about land and hold short operations (oops!). I guess it's because other parts of my sites are heavily linked to, mainly due to SAX. http://www.megginson.com/blogs/lahso/ As long as we're on the topic of Google, FlightGear is either #3 or #4 for the phrase flight simulator, depending on whether you count the initial hits on Microsoft as one or two. Only MSFS (and Microsoft Combat Simulator) and the flightsim.com web site come ahead of us. X-Plane barely makes it onto the bottom of the first page, and Elite is not on the first page at all (thank god -- I had to suffer through that piece of garbage during my IFR training). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Properties under /orientations seem to have taken on offsets after extreme attitude
On Tue, 11 Jan 2005 17:34:05 -0500, Ampere K. Hardraade [EMAIL PROTECTED] wrote: Under /instrumentation/attitude-indicator, there is a property call caged. Would that be what you are referring to? Yeah -- we need to link that to something the user can get at (but again, only for aerobatic planes). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Proposed change: visibility inside a cloud layer
Currently, FlightGear (SimGear, actually) always sets visibility to near-nil when the plane is inside a cloud layer -- obviously, the right and proper solution is 3D clouds, but until we have that working, or at least until we can detect whether the plane is actually near the cloudy part of a texture, I suggest that we do not limit the visibility when the cloud coverage is under 50% (i.e. scattered, few, or clear). It's a bit of a hack, but it does make it possible to fly VFR under conditions that are legal VFR -- it's quite normal for VFR pilots to climb through a scattered cloud layer, for example (our scattered texture might be a little too busy for realism, though). You should have everything go white when there are only a few clouds in the sky. I'd like to commit this (very small) change. Are there any objections? It's especially useful with --enable-real-weather-fetch, where otherwise a low layer of few clouds gives you IMC right off the end of the runway. Here's the complete summay: clear: normal vis few: normal vis scattered: normal vis broken: low vis overcast: low vis cirrus: low vis Thanks, and all the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposed change: visibility inside a cloud layer
On Mon, 10 Jan 2005 20:56:41 +0100, Erik Hofman [EMAIL PROTECTED] wrote: This is due to a faulty SGSky::modify_vis() function. Actually it has been broken since early 0.7.x as I recall it. I've never remembered to look at it prior to a release, but I would recommend to fix that function rather than to apply any kind of hack. I'm not sure I understand. The modify_vis() function isn't buggy as far as I can see, but it does have logic that makes FlightGear less useful -- that's what I'm proposing changing. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposed change: visibility inside a cloud layer
On Mon, 10 Jan 2005 13:59:28 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: One issue to consider is that going to nil visibility (and not drawing the cloud plane) hides when you pass through the cloud plane. When the cloud plane intersects the near clip plane you get some ugly artifacts. I don't know how you get around this if you go to only partial visibility. I don't know if I'm willing to live with that artifact. I'm not even going to only partial vis -- I'm not touching vis at all with under 50% cloud coverage. On my system, it doesn't look too bad -- FlightGear doesn't draw the cloud texture at all when you're (supposedly) inside the cloud layer. It does reappear when you get below it, but that sudden pop is not nearly so big a problem as not being able to use FlightGear to fly VFR in what should be VFR conditions. For an inexperienced user, especially, having everything go white when trying to descend past a few clouds (far away) is a far worse visual glitch than having a texture suddenly pop into view, and will probably cause the user to loose control and get frustrated. Should I tentatively commit it so that people can try it out? We can always revert if people hate it (and then I'll have to run it just as a local patch). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange FG crash.
On Mon, 10 Jan 2005 14:20:45 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: I was just flying in the SFO area with the DHC2-F and flightgear crashed with the following message: Unknown exception in the main loop. Aborting... Possible cause: Success Anyone have any ideas? This is the first time I've seen anything like that. I did a find/grep through all of the FlightGear, SimGear, and plib source code as well as the base package, and I couldn't find anything that looked like a reasonable candidate for an exception returning the message Success. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange FG crash.
On Mon, 10 Jan 2005 21:25:55 -, Vivian Meazza [EMAIL PROTECTED] wrote: Unknown exception in the main loop. Aborting... Possible cause: Success WAG - OpenAl? I think it would have to be wrapped in a SimGear exception for that to happen, but I'd have to double-check the code. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yet another blender modelling question...
On Thu, 6 Jan 2005 09:26:58 +, Matthew Law [EMAIL PROTECTED] wrote: Hello again, although my free time has been in short supply recently, I've been plodding on with some Blender models. I've noticed a lot of the tutorials available for blender use sub-surf techniques to get smooth results on curvy forms like cars and aircraft. Can this be used for FGFS models which will be exported to AC3D or is the sub-surf lost? - as I understand it the sub-surface algorithms are just a type of mesh smoothing operation. Or am I way off the mark here? I don't know, to tell the truth, but all that goes out to AC3D format (and all that plib can use) is polygons, colours, and textures (one texture per object). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yet another blender modelling question...
On Thu, 6 Jan 2005 14:36:57 +, Matthew Law [EMAIL PROTECTED] wrote: I've just thought that I might be able to get a really nice smooth but higher poly model by using nurbs surfaces to model half of the fuselage, say. Then I'll convert it to a mesh and duplicate, mirror and join it to make the whole thing. Does this sound reasonable? I experimented with stuff like that early on, but in the end, I found the most success just building my meshes by hand. For the fuselage, I usually start with a mesh square in front view, then I split edges and move vertices until I have a cross-section of the widest part; next, I switch to side view and duplicate that square forward and backward, adjusting its height to fit the fuselage side profile; then I go back to front view and adjust the shapes of the cross-sections (also from top view, usually), then I connect them all up. A similar approach works for the wings and horizonatal stabilizer or stabilator. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Windsocks
On Thu, 06 Jan 2005 16:20:02 +, David Luff [EMAIL PROTECTED] wrote: Can anyone who flies in the US tell me how prolific windsocks at GA airports actually are. Currently we get one at each end of the runway by default in the airport data, but I'm wondering if that's generally overkill? If an airport has a segmented circle (nicely visible from aerial photos) is that where the windsock is usually located? Yes, you're right -- the default windsocks in our X-Plane database are overkill. Here's what appears in the AIP Canada on the subject (Canada generally follows ICAO recommendations closely): At aerodromes that do not have prepared runways [i.e. floatplane bases -- dpm], the wind direction indicator is usually mounted on or near some conspicuous building or in the vicinity of the general aircraft parking area. Runways greater than 4,000 feet in length will have a wind direction indicator for each end of the runway. It will be located 500 feet in from the runway end and 200 feet outward, usually on the left side. Runways 4,000 feet in length and shorter will have a wind direction indicator centrally located so as to be visible from all approaches and the aircraft parking area. Where only one runway exists, it will be located at the mid-point of the runway 200 feet from the edge. For night operations the wind direction indicator will be lighted. My home airport has an 8,000 ft runway, a 10,000 ft runway, and a 3,300 ft runway. The 8,000 ft runway and 10,000 ft runway have lighted windsocks at each end; the 3,300 ft runway has one in the middle of the runway and it's not lighted (since that runway isn't for night use). You will also see windsocks near helipads, of course, if the airport has any. Note that a defined grass or gravel strip still counts as a prepared runway. As Curt mentioned, there are also many non-regulation windsocks around most airports, mostly small things. The majority of them are useless because they're mounted too close to buildings (rather than high on top), so they show local wind currents around the buildings rather than the prevailing winds in the field. They're there mainly just for decoration. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Wed, 5 Jan 2005 12:57:54 + (UTC), Martin Spott [EMAIL PROTECTED] wrote: People doing business in North America usually share the impression that people 'over there' are commonly a lot more conservative when it comes to aircraft engines. And they have a strong lobby: One of the major reasons why Porsche stopped its aircraft engine project was that the US lobby (Lycoming, Continental and so) were predicting the possibility of difficulties with future (spare part) delivery to European customers I don't know if the lobby would make a big difference -- after all, if the Textron/Cessna lobby wasn't strong enough to keep out the new composite planes, how could the Textron/Lycoming lobby keep out engines? In fact, neither engine company has much of a reputation right now: many private aircraft owners refuse to use Lycoming or Continental cylinders when they overhaul their engines now because the two companies (especially Continental) have let quality control slip so far. Eventually, we'll have some new piston engines that work well and put Lycoming and Continental to shame. The problem so far, I think, is just that North Americans fly differently. From what I understand, most European private pilots with piston aircraft fly short distances, at low altitudes, in VMC, because of all kinds of airspace restrictions, fees, etc. As I mentioned in an earlier posting, North American private pilots fly enormous distances at a much bigger range of altitudes and temperatures, often in IMC. I often cruise at 10,000 ft, and people with turbonormalized engines routinely cruise in the mid-teens with oxygen or up in the flight levels with pressurization. I think that's why engines that do fine in Europe, like the Rotax, fail over here once they're widely used. I'm hoping that the Thielert will be different. The main impediment is the cost of installation in existing aircraft -- in many cases, it's more than the entire resale price of the plane, and you could never make it up with fuel savings (our fuel isn't that expensive). When they can manage an upgrade for USD 20-30K (including engine), and the engine has been proven effective, you'll see people lining up. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation kt_70.cxx, 1.1, 1.2
On Wed, 05 Jan 2005 08:01:49 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: So what's the solution? We can't initialize any number of arbitrary serviceable properties in the preferences.xml and I've always been nervous about doing htat anyway. If we also can't do it in code, then were are we supposed to initialize these properties so that the instruments will work? One option is to initialize only if the property is not set. There's no problem having a C++ fallback, as long as it does not override any user-specified value. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Wed, 5 Jan 2005 15:02:22 + (UTC), Martin Spott [EMAIL PROTECTED] wrote: Unfortunately the conversion produces horrible costs this might lower in the future because the way the engine is being assembled is going to be changed, Lowering the conversion costs will help. Another point might be marketing position: right now, I can install a 135 hp Thielert in my Warrior that will give me more-or-less the same performance as the 160 hp Lycoming currently in it, only burning about 35% less fuel. Most North American owners would be more interesting in performance -- selling a 180 hp engine that makes my Warrior fly like a Cherokee 236 (20 kt faster, much bigger useful load) with the same amount of fuel I'm currently burning would be much more interesting. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Wed, 5 Jan 2005 16:24:20 + (UTC), Martin Spott [EMAIL PROTECTED] wrote: The Warrior will never have a load like the 'bigger' ones because it lacks the reinfoced airframe, not matter which engine you mount, Is the Warrior's airframe weaker than the Archer's or Arrow's? All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] plib release
On Tue, 04 Jan 2005 15:57:17 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Who is the keeper of this patch. Can someone send it to me in as maintainer friendly a form as possible. If this can default to off, but be enabled with some API call then I think we have a shot at getting it into plib cvs. It looks like the original patch came from Themie Gouthas. Here's where Steve Baker makes it very (and rudely) clear that he's not interested (from the Google cache, since the original page is timing out): http://www.google.ca/search?q=cache:pFqrOPmXkbcJ:www.geocrawler.com/archives/3/1868/2002/9/0/9628743/+%2Bplib+%2Balpha+sort+patchhl=enclient=firefox All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] plib release
On Mon, 03 Jan 2005 16:12:27 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: I have heard rumors that the plib team is considering a new official release in the near future. Are there any patches that FlightGear needs that aren't commited to plib's cvs repository yet? Is the alpha-order sorting patch in there? Steve might not object if we make it runtime configurable, somehow. That would be a big deal for people building 3D aircraft models. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Sun, 2 Jan 2005 11:09:09 +0100, Gerhard Wesp [EMAIL PROTECTED] wrote: The FADEC is easy as long as everything works normally. Things get more complex if you want to model failures. Right, but that's true of our piston engine models in general -- we're not modelling stuck valves, fouled plugs, burned-out starter solenoids (like mine on Thursday), mistimed magnetos, uneven fuel/air distribution, clogged injectors, carb ice, leaky crankcases, oil starvation, contaminated fuel, broken fuel lines, and tons of other stuff. Lack of FADEC failure modes would be just one more item on that list. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Sun, 02 Jan 2005 17:03:02 +0100, Christian Mayer [EMAIL PROTECTED] wrote: I see no benefit in adding an dependancy to a library that effectively can do the same as OpenGL - but only in software. If OpenGL is too complicated for some cases, we can encapsulate the necessary functions in C/C++ code and offer that function. Agreed -- we're going to have to redraw the displays at least once per second, so we'll need any hardware acceleration we can get. A software-only 2D graphic library isn't going to cut it. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Diamond TwinStar Panel
Happy 2005 to everyone in the FlightGear community! Here's a high-resolution picture of the Garmin-1000-based panel on the new Diamond TwinStar, one of my dream aircraft (it rececently crossed the Atlantic non-stop from Canada to Spain burning less than USD 200.00 worth of fuel). Anyone aircraft model designers ready to take this one on? http://www.diamond-air.at/Pressebilder/DA42TwinStar/Panel/tn/DA42panel_high.jpg.html All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Sat, 1 Jan 2005 21:44:35 +, Dave Martin [EMAIL PROTECTED] wrote: http://www.diamond-air.at/Pressebilder/DA42TwinStar/Panel/tn/DA42panel_high .jpg.html The visual model is easy enough but the panel is a different matter. We can probably manage the left display. The right display (moving map with elevation shading) would be extremely difficult, but it's appearing in so many planes that we'll have to bite the bullet some day. That kind of complexity of systems is probably impossible for a 3d cockpit (lack of usable font system?). The 3D part is easy -- there are relatively few moving parts to animate. The challenge will be creating dynamic textures to show on the displays, and that's going to require rolling up our sleeves and doing a lot of C++ OpenGL coding. Also, it would need someone to model the gearbox and FADEC for the turbodiesel engines (includes autopitch etc). That, I think, would be a much easier problem. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Sat, 1 Jan 2005 23:39:49 + (UTC), Martin Spott [EMAIL PROTECTED] wrote: They also have a version with two Lycoming IO-360 for the North American market, Is that out yet? I'd heard that they were working on one because there's no repair network for the Thielert diesel engine in North America; I'd also heard that they were working on setting up such a network. The Thielert engine certainly accounts for a lot of the savings -- I'd expect two IO-360's to burn at least 20 gallons per hour, vs 10 gph for the Thielert engines, but they'd probably also increase the useful load by a couple of hundred pounds and make the plane fly faster, to offset that. The Rotax engine originally used in Diamond's Katanas was an unmitigated disaster (we had yet another Katana forced landing at the Ottawa airport a month or two ago), and left the North American market very nervous about any non-Lycoming/Continental engines -- Diamond finally started making the Katana available with a Continental engine (I think). The Thielert diesel engine has nothing to do with the Rotax, of course, but Diamand will have to do a lot of work to win back North American buyers' trust about non-standard engines. We fly planes hard and far in North America, often with multiple 3-5 hour legs through some pretty extreme climates (from about 45 degC in the American southwest to -40 degC in northern Alaska and the Canadian arctic), so engines that perform nicely for occasional recreational use for local flights in a moderate Europe climate don't always cut it over here after a few years of use. I'm hoping that the Thielert will make it, because the fuel savings sound fantastic. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Object Needle not found.
On Thu, 30 Dec 2004 08:08:12 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: I'm passing along second hand knowledge here so I could be way off, but I seem to recall there were problems with plib's handling of single polygon objects ... it would collapse them into the parent layer. You might try building your needle with one more triangle and see if that cures the problem. That is correct -- I don't know if there's any fix in plib CVS now, but in the past, Steve has violently disagreed with any suggestion that named objects should be preserved, so no one was allowed to commit a fix. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Wed, 29 Dec 2004 08:06:13 -0600, Jon Berndt [EMAIL PROTECTED] wrote: It appears that entire tables could be read in as one data chunk. I need to do processing in that case and manually separate the data rows. I think I've almost got this one figured out. Sounds good. The main problem is that you're doing this the hard way, working with low-level XML markup events instead of the high-level property interface -- I understand, though, that you want to control the markup at the element/attribute level, so I guess there's no choice. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Errors in Airports database
On Wed, 29 Dec 2004 13:22:54 -0500, William Earnest [EMAIL PROTECTED] wrote: A bit of digging found that the airport ID of 1N9 had been changed to K1N9. Further checks show that has happened to quite a few of the non-Kxxx IDs in the USA. Is this a FG problem, or are the errors coming from Robin's database? I can work around it for now, but it could prove a long-term annoyance to users in general. In official Canadian publications, all airport identifiers are now four characters long and prefixed with C, even the ones that are not official ICAO codes. So not only do we have CYOW for my home airport (where the old timers prefer the old-fashioned ATA YOW), but we also have CNP3 instead of the old NP3 for Arnprior, a small airport outside of town. I'm betting that it won't be long until you see all US airports with four-letter identifiers in the Jeppesen database, because it helps to distinguish them from navaids (i.e. KALB is the Albany airport, while ALB is the Albany VOR). For now, though, Jeppesen is still using 1N9 for Allentown, so we should probably use that as well. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Tue, 28 Dec 2004 12:43:27 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: So, I guess I've been lucky so far that the data I have gotten - except in this particular case - has been chunked together. I'm a little stumped as to how I can make sure that I get all the data for an element and store it as an STL string for later reading. Collect it in an STL string and then process it when you see the end tag. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Tue, 28 Dec 2004 16:07:19 -0600, Jon Berndt [EMAIL PROTECTED] wrote: I thought that sounded reasonable and tried that this morning. But, it still doesn't seem to work - in fact (at least the way I'm doing it) it seems worse that way. A quick glance seems to suggest (rightly or wrongly) that _everything is treated as data at one time or another. Maybe I need to take another look at this approach. I'll give a more thorough report later. Make sure you blank the string at the start tag. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tue, 28 Dec 2004 17:56:24 -0500, Ampere K. Hardraade [EMAIL PROTECTED] wrote: What you want to print on the aircraft is its registration number, not the callsign. Right -- for private aircraft and commercial aircraft not flying for a proper organization, the callsign and registration number are usually identical, but even a private plane can sometimes have a different callsign (like Angel Flight XXX in the US, I think). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Tue, 28 Dec 2004 19:41:55 -0600, Jon Berndt [EMAIL PROTECTED] wrote:
void FGTrafficManager::data (const char * s, int len)
{
string token = string(s,len);
if (( token.find( ) == string::npos
(token.find('\n')) == string::npos))
{
value += token;
} else {
value = string();
}
}
No, there is no guarantee that the string will be non-empty (that goes
down to the underlying XML library). Again, make sure that you set
value = at the start event, and then process value at the
corresponding end event.
All the best,
David
--
http://www.megginson.com/
___
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 Mon, 27 Dec 2004 19:27:03 -, Jim Wilson [EMAIL PROTECTED] wrote: I know that no one particularly loves VRML, but it is text based (like AC3D) and open. As long as we're just doing textured and tinted meshes, with the more complex stuff (like animations) in external XML files, is there any good reason *not* to go with VRML, especially since we can compress the files on disk with gzip? This sounds interesting, I'm just not familiar enough with it. What would be involved in making this change? The same thing that is involved in switching to any format -- writing a VRML 1.0 importer for plib (or directly for FlightGear). The advantages of VRML are a) *every* 3D modelling program can import and export it; and b) it's text-based, so it's easy to debug problems and to generate VRML models or components using scripts. VRML was meant to be as big as HTML, creating a new, 3-D web browsing experience. That was total BS, of course -- I mean, do you really want to use a 3-D interface to bid on eBay or check movie listings? -- and to try to recover from the 3-D-for-the-web failure, llater versions of VRML added actions and all kinds of extra stuff that few ever implemented properly; it was also eventually XML-ified. The original, text-based, non-XML VRML 1.0, which is fairly simple, should have all we need for textured meshes, however. There is currently a VRML 1.0 importer in plib, but it doesn't quite work (it messes up on textures, if I recall correctly). Having a VRML 1.0 importer that worked as well as the AC3D importer would make things very easy -- just tell people to save as VRML no matter what modeller they're using. Curt's idea of storing .ssg in a cache fashion also sounds interesting. Sort of along the same theme I'm wondering if we could gain some benifit by caching binary representations of other XML config files (like 3d cockpit animations, etc). The amount of xml processing during intialization is becoming quite large in some cases. The trick is coming up with something that loads faster than the XML, or the caching is pointless. Out in the wild, people have tried and mostly failed. Most of the overhead, I think, comes not from the XML parsing but from opening and closing so many tiny files, so 100 pre-compiled binary files will take just about as long to load as 100 text XML files -- perhaps if you could dump everything into a single file, load times would improve. When I turn on debugging output, most of the load time does not seem to be reading config files, though. If a given model was developed in blender, shouldn't we be providing blender sources in a _base package source_ distribution so that future changes are also handled by blender users? Yes -- give me a place to put my models, and I'll gladly make the Blender source available. Right now, it's in a temporary directory for anyone who wants it: http://www.megginson.com/Private/Models/ Of course the flip side to this argument is that if we commit to providing blender sources and requiring blender source modifications (which itself is fraught with blender version issues), then we effectively commit to the blender format for that model, regardless of which format FlightGear actually loads. You have to distinguish between the maintainer and contributors. As long as I'm maintaining, say, the J3 Cub model, any contributors should make their changes to the Blender source, since Blender is my chosen format. If a different maintainer takes over (or forks the model), then that maintainer may choose to keep the source in 3DS, AC3D, or some other format. I don't think that we should dictate to people what modelling program they have to use, though, obviously, they'll do better attracting contributors if they use an Open-Source one, or at least a cross-platform one. Would VRML give us true modeler portability? Can ac3d (or whatever closed source modeler) import a VRML model and have all features intact, and then export it back to VRML in a way that a blender user could import the same model and see the same changes? You will lose information that's useful to the modeller, like, say, object grouping. VRML is good enough for displaying a model in FlightGear, but just about every modeller keeps a lot of extra information around that's useful to the designer, and that will be lost. If a new maintainer is taking over and wants to switch to a different modelling program, VRML is a good way to get the basic mesh objects and textures in there, but then there will be some work regrouping, etc. Can blender even import it's own exported VRML and have all the features intact? No, because VRML just stores the basic mesh objects and textures, not all the other Blender information (which FlightGear doesn't use either, by the way). It's somewhat similar to saving as RTF and then reloading into Word or OpenOffice. All the best, David -- http://www.megginson.com/
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Mon, 27 Dec 2004 15:52:01 -0500, Ampere K. Hardraade [EMAIL PROTECTED] wrote: 3D Max Studio can't import VRML. I don't know about other modellers though. Are you certain? Even the dinky little shareware modellers usually support VRML 1.0 import and export -- it's like a spreadsheet not importing CSV. All the best, David -- http://www.megginson.com/ ___ 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 Mon, 27 Dec 2004 21:28:18 +, Dave Martin [EMAIL PROTECTED] wrote: As I've mentioned, the modifications to the c172p that I made were with ac3d (it's not a hugely powerful modeller but speed of development is good). I'm happy to hand over the 172p to Dave or someone else who is willing to take it over and give it a lot of TLC -- it's our default aircraft, so it should look better than it does (i.e. a proper interior with fabrics, door handles, placards, etc.). One thing that Blender loses on AC3D export is reused meshes; for example, I might have 10 objects that all use the same mesh (think knobs or antennas), and in Blender, any change I make to one will appear in all the others; on export, the link is lost, and they're 10 separate objects. As Dave mentioned, specular and emissive colours are also lost on AC3D export (at least the last time I checked), and I have to edit them into the *.ac file by hand after export. Sometimes I also have to rearrange the objects for alpha ordering. All the best, David -- http://www.megginson.com/ ___ 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 Sun, 26 Dec 2004 09:53:49 -0500, Norman Vine [EMAIL PROTECTED] wrote: SSG is certainly not propriatary in any reasonable man's vocabulary !! You need to distinguish open specs from open formats. For example, MSIE is closed source but uses open formats (HTML, CSS, etc.); Open Office is open source but uses proprietary formats (file formats that they developed themselves and no one else uses). I wouldn't bother with Esperanto, but at least I'd prefer a language like English that people other than me use. Anyway, my original point was that whether you agree or disagree, you were being a little loose with the accusation of FUD against Curt. He's making a legitimate point, not trying to mislead people into doubting plib. All the best, David -- http://www.megginson.com/ ___ 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 Sun, 26 Dec 2004 17:41:20 +0100, Wolfram Kuss [EMAIL PROTECTED] wrote: Do you completely hand edit the XML? I hand-edit the animations, but eventually, we could look at something more standardized. Do you plan to keep it that way? Since Blender has scripting support, it would be possible to generate the XML animation files from it, if anyone cared enough. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Ann: blender source for aircraft models
Since there are so many talented 3D modellers around the project now, I've put online the Blender source for the mostly crude 3D models I've developed. Note that this is not, yet, a permanent location; I'll think of a better URL later, or better yet, we'll set up a directory on the main FlightGear site for 3D model source files. http://www.megginson.com/Private/Models/ All of these models are hereby released into the Public Domain. Note that these are undocumented, raw directory dumps, not nicely packaged distributions. You'll almost certainly have to fix the texture paths, if nothing else. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On Sat, 18 Dec 2004 15:27:09 +, David Luff [EMAIL PROTECTED] wrote: I've always assumed that it's a fairly late model injected 172, in order to justify the current lack of carb heating in the engine model ;-) The 172P is carbureted, unfortunately. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On Sat, 18 Dec 2004 17:37:35 +, David Luff [EMAIL PROTECTED] wrote: Ah! Carb heating has just moved several places up my TODO list! I'm not sure that the engine model should even be dealing with carb heating -- it would be just as easy for something else to tell the engine the temperature of the air it's getting, since carb heating is separate from the engine proper (it's actually heated before it gets to the carburetor, usually by passing through an exhaust shroud or something similar). More relevant is the different starting procedures for carbureted and fuel injected. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On Sat, 18 Dec 2004 19:15:46 +, Dave Martin [EMAIL PROTECTED] wrote: While you're there, is there any chance of a magneto-related performance loss? ie: when you run left mags only you get a power loss. It would be nice to see that generalized a bit, so that we can eventually model fouled plugs and pre-detonation as well. Some day, the piston engine model will handle each cylinder in its own routine, but we're not quite ready for that yet. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On Sat, 18 Dec 2004 20:20:37 +, Dave Martin [EMAIL PROTECTED] wrote: Simulated carb icing might be exciting too (coupled to weather, of course :-) ) It would certainly make you remember to pull the lever ;) Some day, we might model then entire air induction system, the way that we model the electrical or vacuum system. For example, the early Cessna 172s, like the Cessna 150/152, used Continental engines with the air intake right under the propeller, a couple of inches from the carburetor -- you can imagine that it didn't take much to get carb icing, or even just to block the intake air filter with impact ice. In my Warrior, on the other hand, the air scoop inlet is a bit to the right of the prop (looking from the cockpit), then it goes through a duct about 15 inches long, heated by nearby exhaust pipes before turning 90 degrees to pass through the air filter (i.e. no direct impact ice) and then travel a bit further into the box that controls air input into the carb above it. Needless to say, carb icing in a Cherokee is extremely rare, and pulling carb heat is not a regular part of the landing procedure. I think that the later Lycoming 172s like the 172p have a similar induction system, but I haven't looked under the cowling of one. I've heard from several sources that pulling carb heat with every power reduction in the later 172s is just a holdover from the earlier 172 procedures. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On Fri, 17 Dec 2004 20:38:33 +, Dave Martin [EMAIL PROTECTED] wrote: Just wondering if the C172P is supposed to represent a specific model year? Totally up to you, but my 172P POH is for the 1981 model, for what that's worth. I cannot even remember the light positions on the planes I trained on; in any case, it's worth noting that many owners have moved the lights around over the years (some people like to install wingtip landing lights so that they look like a jet coming in). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Real Piper Data
A Piper owner trying to have is PA-28-201 (Arrow) repaired managed to get this concrete information from Piper: -- From: airframe [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 10:50 AM To: 'Stanley Zamkow' Subject: RE: Contact Us Request Form Dear Sir: There is not an off-set of the vertical fin or the stabilator on the PA28R-201. The fin is should be vertical to center line and the stablilator should be horizontal to the ground when the aircraft is straight and level. The only off-set would be the wing twist and the engine is off set by approximately 3 degrees to the right of center and approximately 4 degrees down. Regards, The New Piper Aircraft, Inc. -- This is useful information for anyone doing aerodynamic modelling -- the engine offsets are greater than I would have expected, especially since you have to add the wings' incidence angle to the down angle for level flight. All the best, David -- http://www.megginson.com/ ___ 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 Mon, 13 Dec 2004 08:27:00 +0100, Arnt Karlsen [EMAIL PROTECTED] wrote: ..one way is point .gov and .com people to if someone flies into an Aussiestani or Canuckistani tower, is it jihad, and who get's sued? That doesn't work so well outside of the U.S., because other countries don't have the same culture of litigation. In Canada, for example, the loser often pays the winner's court costs in a civil action, so if I try to sue the government or a big corporation and lose, I might have to cover hundreds of thousands of dollars in their legal fees. Even if I win, the award will be only reasonable, not spectacular (i.e. I might get awarded $1M to help pay my costs if I'm in a wheelchair, but I probably won't get an extra $59M in punitive damages). Still, COPA has made similar arguments, along the lines of look at how much an accident costs the government in SR, investigation, medical costs, etc. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DAFIF comment period: there will be one after all.
On Mon, 13 Dec 2004 16:15:45 -0500, Chris Metzler [EMAIL PROTECTED] wrote: I have no idea whether comments from folks outside the U.S. are taken into consideration; I'd bet not. I've sent one anyway; here it is: ==8== I am a Canadian citizen and resident, and would like to comment on the proposal to remove the DAFIF from public distribution. Unfortunately, nearly all of the countries in the world refuse to release aeronautical data for free public distribution, despite its obvious value in many areas, such as safety, training and simulation, geographical and demographic research, and municipal planning. While the US already has the free FAA database available, the DAFIF has been the main (and often, only) aeronautical resource freely available to the rest of the world. So, I would like to start by thanking the US government for making this valuable resource available, and then to beg you not to remove it from public distribution. Perhaps it would be possible to remove any sensitive military information from the DAFIF while still maintaining the civil information, such as airports, runways, and airways -- this information is already available to any hostile party with a few hundred dollars to send to Jeppesen, so removing the DAFIF from public distribution would not deter those parties; however, it could prevent poorly-funded organizations, such as academic researchers or municipal governments, from using the DAFIF data for their own research and planning. If the DAFIF does disappear, it will no doubt be replaced by a collaborative, open international project run by the aviation, geographical, and flight-simulation communities; however, such a new project would take time, and, more importantly, would be entirely outside of your control -- it could end up containing much more sensitive military data than the DAFIF. Of course, such a project could appear anyway, but as long as the DAFIF is freely available, there is less incentive for people to start it. Again, thank you for making such a good resource available: whatever you decide to do in the end, you have done a great service to many communities by making that information available for so long. Thank you, and all the best, David Megginson Ottawa, Canada ==8== All the best, David -- http://www.megginson.com/ ___ 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 10:36:19 +1100, Nick Coleman [EMAIL PROTECTED] wrote: I must have missed it, sorry about that. Oh yeah, 2 months ago was exam time, I stopped reading the list for a few weeks. No harm done. We're all unhappy, of course, but it's hard for non-Americans like me to complain too much -- the U.S. is removing information about our countries that our own governments never made freely available in the first place. The FAA database is still available for the U.S., but other governments (like mine) do not make their aero data available freely at all, and we've been lucky that the U.S. has made data for Canada, Europe, Asia, etc. available. It's so bad that the Garmin 296 GPS (which displays terrain and manmade obstructions) does not even display towers in Canada, because the Canadian government wanted royalties for every Garmin unit sold (!!!). The real solution to this problem is to come up with a worldwide, peer-reviewed open-source aero database, for use both by the simulation community and by the aviation community. That's an enormous undertaking, of course. 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. All the best, David -- http://www.megginson.com/ ___ 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 Sat, 11 Dec 2004 10:18:36 +0100, Erik Hofman [EMAIL PROTECTED] wrote: FlightGear has used the Peel database for quite some time (always?) and just recently (one or two years ago) Robin started to use DAFIF. Prior to that we only had data contributed by volunteers. Now we have a better base to start with and can start contributing the changes again. There's a lot more information in the DAFIF, like airways, radio frequencies, etc. We're not using most of that yet in FlightGear, with with AI aircraft and ATC, it will be getting increasingly important. All the best, David -- http://www.megginson.com/ ___ 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 Sat, 11 Dec 2004 01:06:56 +0200, Paul Surgeon [EMAIL PROTECTED] wrote: I'm surprised someone else hasn't commented on this yet. We had a discussion a couple of months ago, when the topic first came up. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and file moves
On Thu, 09 Dec 2004 09:32:46 +0100, Erik Hofman [EMAIL PROTECTED] wrote: Is there a clean way to move files in a CVS repository from one directory to another for a reorganization? No, that is one of the shortcomings of CVS. The only way is deleting it and adding it at the new location. In the case of SourceForge, that is probably true, unless Jon has shell access. If you have full filesystem access to the CVS repository, it is possible to move files around with a little work. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott [EMAIL PROTECTED] Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? It uses the AC3D crease directive, which stock plib doesn't support. More importantly, FlightGear still tries to load the Nimitz even when I'm starting at an airport thousands of miles from KSFO. Is there any way to bind those AI's to a specific area, the way we do with static scenery? All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza [EMAIL PROTECTED] wrote: Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. By the way, are you certain now that the crease patch is in the plib CVS? Since the loaders are not an integral part of the plib core, one alternative would be to maintain our own AC3D loader in FlightGear, based on the plib one. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Magnetic Compass
On Mon, 22 Nov 2004 17:09:10 + (UTC), Martin Spott [EMAIL PROTECTED] wrote: Mmmmh, depending on who your copilot is In a C150 things are much easier because the compass is very close - as is your copilot :-) In the Warrior, you can see the numbers fine, but because you're looking at a 45-degree angle, you won't be reading the correct heading -- that's why you have to move your head right in front of the compass. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Stall warning
On Thu, 18 Nov 2004 00:05:33 +, Matthew Law [EMAIL PROTECTED] wrote: Now drop the nose a little and let the air speed build to above Vs still with idle power. I repeatably get the stall warner to well over 70kt indicated. Are other people seeing this? Is it normal? (I've never just dunked the nose on a 150 or 152, but I'm sure the stall warning would go as soon as the flow re-attached to the wing... ... or at least when you go below the angle of attack that the stall horn is set to. That does seem strange -- you shouldn't hear it even if you have got yourself into an accelerated stall somehow, because stall horns don't tend to actually know about loss of laminar flow. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plea for help: geometry/trigonometry prob lem
On Thu, 11 Nov 2004 09:10:35 +1100, Curtin, Robert [EMAIL PROTECTED] wrote: I just stumbled across this thread and couldn't figure out whether it was resolved or not. Not being overly familiar with FlightGear, I'm not even sure what the inputs to this problem were. This is how I would approach it though... Thanks, Rob. I have something that seems to work well now in src/Instrumentation/mag_compass.cxx -- I'd be grateful if you could take a look and see if it's possible to improve or at least clean up the calculations. Thanks, and all the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Migration from cockpit to instrumentation
n Wed, 10 Nov 2004 23:45:29 +0100, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I'm migrating stuff from the cockpit directory to the instrumentation directory. Specifically I'm migration the stuff in the radio stack. My question is this: should I also move the properties from /radios/* to /instrumentation/*? I had forgotten that there still was anything in the cockpit directory -- that's some pretty rusty code. Thanks for looking into this. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D cockpit authoring
On Tue, 9 Nov 2004 12:57:43 -0500, Vance Souders [EMAIL PROTECTED] wrote: Is there an aircraft currently in flightgear that is a good example of proper 3D cockpit construction? I don't know about 'good', but the J3 Cub and the PA-28-161 both have pure 3D cockpits (no 2D panel code). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..modelling night vision loss to hypoxia rant ; -), was; The Rant
On Mon, 8 Nov 2004 06:05:57 +0100, Arnt Karlsen [EMAIL PROTECTED] wrote: ..this is with or without oxygen? Without -- oxygen is a very difficult thing to manage in the eastern half of the continent. I could purchase a portable oxygen system good enough for me (not enough for pax) for less than USD 1,000 but almost no FBOs could fill it for me -- out west, near the Rockies, oxygen is a standard service, but not around here. That means that I'd have to find a local oxygen supplier (a scuba shop? a welding supplier?) and take the tank there after every few hours of use to have it refilled -- you can see how that's a non-starter for long cross-country trips. Here's something I'm curious about: since airliners typically pressurize to about 7,000 ft but hypoxia can affect night vision even at 5,000 ft, do airline pilots ever worry about this issue? I'm guessing not, because they always use approaches to land, and when you're already lined up with the runway night vision isn't really an issue. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
If in doubt ... (was Re: [Flightgear-devel] Re: X-Plane on Linux)
On Mon, 8 Nov 2004 17:42:37 +0100, Melchior FRANZ [EMAIL PROTECTED] wrote: Ah, OK. Didn't relate this to the Mac port. At first this looked like the classical troll post: go to an application specific forum, tell how this app sucks and how others are better (which so far would be OK) but then do not describe what exactly are the reasons for this conclusion. Yes, fgfs' Mac incarnation may be less than optimal, but that's only because the Apple users don't care much for FlightGear. :-) The goal of a troll is to make people overreact, so staying reasonable, calm, and polite is always the right choice. If we assume that a person is not a troll and it turns out that a person is, then there's little or no real harm done -- we look good and the troll strikes out. There's nothing wrong with asking polite, probing questions, of course (i.e. what version are you using?, can you list the compiler output?, etc.). If we assume that a person *is* a troll and it turns out that a person is not, then we look defensive and immature. Let's always give new posters the benefit of a doubt unless they're way over the top (i.e. Die @[EMAIL PROTECTED]@% gay commie al quaida scum!!!), and in such a case, let's just ignore them. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..modelling night vision loss to hypoxia rant ; -), was; The Rant
On Sun, 7 Nov 2004 17:14:44 +0100, Arnt Karlsen [EMAIL PROTECTED] wrote: ..eh, in RL, you often _can't_ see the ground at night, just lights. I'll confirm that. The runway and taxiway lights are aimed up and do not illuminate the pavement at all (not even a tiny area around each light). That's why you need landing (and often taxi) lights. Even with a landing/taxi light, taxiing on a cloudy or moonless night is enormously difficult -- you can hardly see the yellow line or the turnoffs, and most of the time you're just rolling through a sea of blackness. If anything, the ground in FlightGear is too bright at night. It's appropriate for a well-lit urban area or a full moon on a clear night, but the runway is far too bright for a cloudy night. For example, do we properly model the impact on night vision from hypoxia? That's a surprisingly sneaky thing in real life. At night, descending from (say) 6,000 ft enroute altitude to the airport, I have a couple of times had a *lot* of trouble finding the airport at night. I don't feel like I'm having trouble seeing; it's just that the lights don't stand out. That's never a problem if I'm lined up with the runway on an approach, because those lights are so bright and directional, but even then judging the flare is a big challenge. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: source/src/Instrumentation mag_compass.cxx, 1.6, 1.7
On Sun, 7 Nov 2004 12:32:41 +0100, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: My motivation for setting the serviceable property to true in the source code was that now that the instruments are configureable they can have an arbitrary name in the property tree. The compass could for example be named /Instrumentation/magnetic-heading-indicator-thingy. As I understood it the serviceable property used to (actually still does) be set to true in preferences.xml, where it is set for all instrumentation. If the source code modules force the property to true, it will override any settings provided by the user at startup or in a configuration file. It needs to be possible to start FlightGear with the mag compass U/S for some scenarios, just as we can start with the vacuum pump or alternator U/S. So setting it to true in preferences is would not be a good solution when (not if) aircraft designers decide to change the name of the instrumentation, remove instrumentation that are not applicable to that aircraft, and add more instrumentation for for example redundancy. Making the compass serviceable should be part of that. If the setting is in preferences.xml (or a separate startup config file), it can be overridden on the command line; if it is hard-coded in the C++, it will be set after the options have been read, and cannot be overridden. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Magnetic Compass
I'm pretty happy with the magnetic compass now. I won't claim that it's a perfect simulation, but it's close enough for practice, and should be especially fun (??) for IFR students practicing partial-panel work. I was sorry to throw out Alex's much more elegant code for my crude hacks. Thanks to everyone who helped, especially with the trig problems. I'd be very grateful if everyone could check out the latest code from CVS and try out the magnetic compass with different aircraft. The effects will be most noticeable at higher latitudes, especially in North America. Now, if you enjoy that, try FlightGear with --failure=vacuum (which will disable the gyro compass in the 172 or Warrior) and try navigating using only the magnetic compass (hint: timed turns are your friend). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] DME groundspeed
The DME groundspeed display is working again -- there was a small typo in a property name in the C++ code. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Flight Test Results for Magnetic Dip
On Wed, 3 Nov 2004 20:21:15 -0500, David Megginson [EMAIL PROTECTED] wrote: Obviously, when the dip is over 70 degrees, it doesn't take a steep turn to cause this effect. The question is, does the compass hang up (i.e. bind and refuse to turn), or does it swing around? If it hangs up, that would explain why I haven't noticed the effect. Any comments from other pilots on the list, especially those who fly north of 40 in North America? I was one a short cross-country this afternoon just before the wet snow and ice pellets came in. On my way into the airport about 15 nm back, I realized that I was almost exactly on a 270 degM heading, so I tried some quick (too fast to show up on radar) left and right banks. In a left 20 degree bank, the magnetic compass does, in fact, reverse, but not all the way to 90 -- in my case, it swung south/east as far as 120 deg. It's kind-of cool, actually, to be able to observe magnetic dip directly that way -- flying west and banked 20 degrees left, the magnetic flow towards the pole was actually off my *left* elbow! All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Plea for help: geometry/trigonometry problem
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. Thanks, and all the best, David -- http://www.megginson.com/ ___ 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 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 ... Thanks, David -- http://www.megginson.com/ ___ 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: My first VERY simple *guess* would be that it might be because of an imbalance in inertia of a compasses moving parts as soon as the pitch changes accordingly. Other replies have pointed you to links explaining the turning error due to magnetic dip. It is quite dramatic in a real plane -- at my latitude (about 45 deg N), my compass can be more than 50 degrees off while the wings are banked, depending on the heading. You are correct, though, that there is also an overshoot error -- the compass will tend to overshoot and oscillate, rather than locking immediately onto a new heading. Alex already had code in place for that, and I plan to add it back in once I have the turning, pitch, and acceleration errors working. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Plea for help: geometry/trigonometry problem
I've thought of a simpler way to approach this problem. Let's say that I have a plane and the three Euler angles of rotation, phi, theta, and psi (roll, pitch, and yaw). Given those three angles, I'd like to determine which direction around the z axis is most directly uphill and how steep the hill is. Thanks, and all the best, David -- http://www.megginson.com/ ___ 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 14:04:05 -0500, Chris Metzler [EMAIL PROTECTED] wrote: 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) 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? Thanks, and all the best, David -- http://www.megginson.com/ ___ 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 16:02:19 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: After having scribbled for a LITTLE WHILE on the back of an envelope ;-) I am thinking that what you want is this: -atan2(-phi,theta) but I'll have to play a little bit more. I think this would give you the angle about the local vertical from the aircraft X axis to the most vertical ascent angle given the plane located by the aircraft X and Y axes. I put it in a Perl script and played with it for different values of phi and theta, and all of the results looked reasonable. Now, how can I calculate the most vertical ascent angle itself? Thanks, and all the best, David -- http://www.megginson.com/ ___ 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 16:17:24 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: Maybe I am missing what you are trying to do, but I just tried this in Excel: -atan2(theta,phi) which gives this: theta phi angle (from forward, positive clockwise) 45 0 0 45 -45 45 0 -45 90 -45 -45 135 -45 0 -180 -45 45 -135 0 45 -90 45 45 -45 0 0 BAD! 10 0 0 10 80 -82.87498365 80 10 -7.125016349 Those look pretty reasonable for offsets from the aircraft's current heading. For example, if you're at 0 pitch a 45 degree right bank, uphill will be 90 degrees to the left of your current heading (-90). If you're pitched down 45 degrees and banked 45 degrees to the right, uphill will be 135 degrees to the left of your current heading; and so on. All the best, David -- http://www.megginson.com/ ___ 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 20:16:08 -0500, David Megginson [EMAIL PROTECTED] wrote: I understand, logically, why this is happening: flying west with a magnetic dip of 71 and a bank of 20 to the south, I have an angle of over 90 degrees to the magnetic flow. I think I even remember the original article mentioning something like this, but I have no recollection of my airplane whiskey compass swinging around 180 degrees suddenly in real life -- if there's a window tomorrow before the low icing stuff moves in, I'll try to go up and take a look at what actually happens. To answer myself, here's the relevant part of the original web page: ==**== For steep turns, where the sum of the dip angle and bank angle exceeds 90 degrees, the compass will ``hang up''. The compass will refuse to turn through 360 degrees as the airplane makes a complete circle. It's easy to see why. Imagine being on a heading of East in the Northern hemisphere, and gradually increasing bank angle to the right. Initially, the north seeking end of the compass needle will point exactly North, towards the left wing tip. However, as the bank angle increases, a point is reached where the magnetic field becomes parallel to the airplane's vertical axis. Beyond this point, the compass needle will swing 180 degrees to point to the lower, right wingtip and the compass then indicates West instead of East! So it is not quite true to say there is no Northerly turning error on headings of East and West. Beyond the critical bank angle (equal to 90 minus the dip angle), the compass lags by 180 degrees when the airplane is banked toward the equator. ==**== Obviously, when the dip is over 70 degrees, it doesn't take a steep turn to cause this effect. The question is, does the compass hang up (i.e. bind and refuse to turn), or does it swing around? If it hangs up, that would explain why I haven't noticed the effect. Any comments from other pilots on the list, especially those who fly north of 40 in North America? Thanks, and all the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Blender question
On Sat, 30 Oct 2004 00:01:04 -0400, Ampere K. Hardraade [EMAIL PROTECTED] wrote: Now days, I am using a different method. Say I want to model a pentagon: I will load the drawing in Gimp or Paintbrush, and measure the coordinates of the five corners in pixel. After that, I will open 3D Studio, create fiver vertices at the aformention coordinates and connect them with lines... and voila, I have a pentagon. My approach is fairly similar, except that I often use paper instead. At first, I wanted to try tracing, but it never works out well -- instead, I print the three-view (blown up a bit if necessary) then take a known measurement, like the wingspan, and figure out how many millimeters on the 3-view represent one meter in real life. After that, I usually start with wireframe squares and actually set the coordinates based on measurements from the 3-view. It goes surprisingly fast (I start with a cross section of the fuselage, and then extrude it as necessary). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Quick report from AOPA
Great report, Curt -- I'm glad to hear that FlightGear held up its end so well. One of the most impressive things about FlightGear is its ability to model marginal visibility fairly realistically -- watching the runway come into view in FlightGear in 1 SM visibility really is like watching the runway in real life, except that we don't have ragged cloud bases and sheets of rain (yet). Compare that to the visuals in Elite, and you'll see what I mean. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Aviation weblog: Land and Hold Short
On Thu, 21 Oct 2004 02:15:07 +0200, Boris Koenig [EMAIL PROTECTED] wrote: ...how would you then call the following: http://www.megginson.com/blogs/lahso/medicals.html ? A brief lapse of judgement. BTW: talking of healthy presidents: Pres. Bush Senior did even do a parachute jump on his birthday this year, he talked about that on Larry King Live, whereas Larry King himself wasn't allowed to jump because of his health condition... Yes, I heard about that. It was a tandem jump, but still. I am sure you could attract some readers here by talking about the time when _you_ were a teenager ;-) All my friends listened to the early Queen albums, jammed jazz and blues, and (I'm ashamed to report) hoped that Ronald Reagan would be assassinated because we thought he was going to start WW III. Not much there to keep a blog going; certainly not much of a social life until university. I've noticed that you've provided this kind of tutorial on your webpage, too - how about also recommending one or two decent RSS feed- readers ? :-) I've tried Straw and Liferea in Linux, and prefer Liferea. There are some plugins for Mozilla/Firefox, but Firefox also has a simple RSS reader built into its bookmarks now. Under Windows, there are FeedDemon ($$, standalone), NewsGator ($$, Outlook), and FeedReader (open source, standalone), along with the Mozilla/Firefox options and dozens of other programs. Under MacOS X, people seem to prefer NetNewsWire, but I think there's also one called AmphetaDesk. After all that, though, a lot of people use an online aggregator rather than installing software on their computers. http://www.megginson.com/blogs/lahso/thumb60.html So, if you intend to maintain that type of contents you could certainly attract some interested readers, I think. Thanks. I'm going to try for some variety -- today, I posted about an NDB fansite, for people who log NDBs they manage to tune in the same way plane spotters log tail numbers: http://www.megginson.com/blogs/lahso/ndb-fans.html I'll probably do another more technical topic soon, maybe more of the rules of thumb. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [OT] Aviation weblog: Land and Hold Short
I have had little luck finding aviation weblogs (they're all about rants about politics, hype about technology, or complaints about teenagers' social lives), so a couple of weeks ago, I decided to start my own. So far, it's heavy on content on light on good looks, so it's probably a fair reflection of its author. If anyone here is interesting in taking a look, there are two ways to get at it. The best way to read it (or any weblog) is to add the RSS syndication URL to your desktop or online blog reader: http://www.megginson.com/blogs/lahso.xml That way, whenever there's a new posting, the headline and summary will appear automatically. If you don't have a blog reader or you prefer the old bookmark-and-click approach, you can find a listing of the weblog entries here: http://www.megginson.com/blogs/lahso/ The title, Land and Hold Short, refers to a common operation at busy airports where planes are using intersecting runways: a plane that's landing (usually a small one) has to agree to come to a complete stop before the intersection so that the other (often a big one) can land or takeoff at the same time. The title also represents the ideal of blog writing -- land a good idea, and keep it short. Unfortunately, I'm not really accomplishing that yet (especially the short part), but I'm practicing. I plan on posting an entry about FlightGear once I'm getting enough hits to make the publicity worthwhile. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Vamos
On Tue, 12 Oct 2004 15:00:08 + (UTC), Martin Spott [EMAIL PROTECTED] wrote: This racing simulation appears to be somehow related to FlightGear - at least it makes use of Simgear: http://vamos.sourceforge.net/requirements.html As far as I can see, the only part of SimGear it uses is the XML read/write support. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenGL/SSG error with latest build
On Sun, 03 Oct 2004 10:00:52 +0200, Erik Hofman [EMAIL PROTECTED] wrote: I'm not familiar with the new code arrangement (it does look like an improvement), and would appreciate some pointers before I start hunting. I think that glutinit() used to set up OpenGL before we switched to SDL. fgOSInit() should do that now. The reason I had this error previously was because the renderer expects at least a 24-bit frame buffer. But that was SDL specific. Could it be you have one GLUT and one SDL binary now? No, they're both SDL. I am running with a 16-bit display, but I haven't had trouble using SDL with that before the reorg. It could be that FlightGear was still calling glutInit back then. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL/SSG error with latest build
I last built FlightGear successfully on 15 August (I hadn't realized it had been so long). I had to make one small change to get to to build today, which I've put in CVS, but now I'm having a problem with OpenGL initialization. My old binary (also built with SDL) still runs fine; the new one fails with the message FATAL: ssgInit called without a valid OpenGL context. Where exactly does the context get initialized in main.cxx and or renderer.cxx? I'm not familiar with the new code arrangement (it does look like an improvement), and would appreciate some pointers before I start hunting. I think that glutinit() used to set up OpenGL before we switched to SDL. Thanks, and all the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
