Re: [Flightgear-devel] link to my homepage

2005-01-22 Thread David Megginson
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

2005-01-22 Thread David Megginson
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

2005-01-21 Thread David Megginson
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

2005-01-20 Thread David Megginson
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

2005-01-20 Thread David Megginson
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

2005-01-20 Thread David Megginson
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

2005-01-20 Thread David Megginson
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

2005-01-19 Thread David Megginson
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

2005-01-19 Thread David Megginson
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)

2005-01-19 Thread David Megginson
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)

2005-01-19 Thread David Megginson
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)

2005-01-19 Thread David Megginson
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)

2005-01-19 Thread David Megginson
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)

2005-01-19 Thread David Megginson
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)

2005-01-19 Thread David Megginson
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

2005-01-19 Thread David Megginson
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

2005-01-18 Thread David Megginson
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

2005-01-16 Thread David Megginson
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)

2005-01-15 Thread David Megginson
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

2005-01-15 Thread David Megginson
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?

2005-01-14 Thread David Megginson
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

2005-01-12 Thread David Megginson
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

2005-01-12 Thread David Megginson
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

2005-01-12 Thread David Megginson
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

2005-01-11 Thread David Megginson
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

2005-01-11 Thread David Megginson
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

2005-01-11 Thread David Megginson
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

2005-01-10 Thread David Megginson
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

2005-01-10 Thread David Megginson
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

2005-01-10 Thread David Megginson
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.

2005-01-10 Thread David Megginson
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.

2005-01-10 Thread David Megginson
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...

2005-01-06 Thread David Megginson
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...

2005-01-06 Thread David Megginson
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

2005-01-06 Thread David Megginson
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

2005-01-05 Thread David Megginson
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

2005-01-05 Thread David Megginson
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

2005-01-05 Thread David Megginson
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

2005-01-05 Thread David Megginson
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

2005-01-04 Thread David Megginson
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

2005-01-03 Thread David Megginson
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

2005-01-02 Thread David Megginson
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

2005-01-02 Thread David Megginson
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

2005-01-01 Thread David Megginson
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

2005-01-01 Thread David Megginson
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

2005-01-01 Thread David Megginson
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.

2004-12-30 Thread David Megginson
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?

2004-12-29 Thread David Megginson
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

2004-12-29 Thread David Megginson
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?

2004-12-28 Thread David Megginson
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?

2004-12-28 Thread David Megginson
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

2004-12-28 Thread David Megginson
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?

2004-12-28 Thread David Megginson
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?

2004-12-27 Thread David Megginson
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?

2004-12-27 Thread David Megginson
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?

2004-12-27 Thread David Megginson
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?

2004-12-26 Thread David Megginson
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?

2004-12-26 Thread David Megginson
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

2004-12-20 Thread David Megginson
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?

2004-12-18 Thread David Megginson
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?

2004-12-18 Thread David Megginson
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?

2004-12-18 Thread David Megginson
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?

2004-12-18 Thread David Megginson
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?

2004-12-17 Thread David Megginson
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

2004-12-15 Thread David Megginson
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

2004-12-13 Thread David Megginson
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.

2004-12-13 Thread David Megginson
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

2004-12-12 Thread David Megginson
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

2004-12-11 Thread David Megginson
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

2004-12-10 Thread David Megginson
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

2004-12-09 Thread David Megginson
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

2004-11-30 Thread David Megginson
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

2004-11-30 Thread David Megginson
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

2004-11-22 Thread David Megginson
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

2004-11-17 Thread David Megginson
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

2004-11-10 Thread David Megginson
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

2004-11-10 Thread David Megginson
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

2004-11-09 Thread David Megginson
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

2004-11-08 Thread David Megginson
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)

2004-11-08 Thread David Megginson
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

2004-11-07 Thread David Megginson
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

2004-11-07 Thread David Megginson
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

2004-11-06 Thread David Megginson
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

2004-11-06 Thread David Megginson
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

2004-11-04 Thread David Megginson
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

2004-11-03 Thread David Megginson
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

2004-11-03 Thread David Megginson
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

2004-11-03 Thread David Megginson
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

2004-11-03 Thread David Megginson
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

2004-11-03 Thread David Megginson
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

2004-11-03 Thread David Megginson
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

2004-11-03 Thread David Megginson
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

2004-11-03 Thread David Megginson
On Wed, 3 Nov 2004 17:57:54 -0500, Chris Metzler [EMAIL PROTECTED] wrote:

 Checked; I can't find a mistake.  As a third check, I ran it through
 Maple and got the same result.  It appears to have the correct
 limiting behavior for both pitch -- 0 and roll -- 0 independently.
 And the problem seems straightforward to me.

Yes, you are right.  I ran some tests with both the original equation
and yours, and they both showed the same (initially) surprising
behaviour -- at my home airport (W75.5 N45.5), on a 270 magnetic
heading and a left bank, the compass needle will suddenly snap around
180 deg.  Here are the results with your equation in Perl for
different values of phi, using theta=0, heading=270, and dip=71:

20: 270
15: 270
10: 270
5: 270
0: 270
-5: 270
-10: 90
-15: 90
-20: 90

With the original equation, which I had put in a short C program, the
discontinuity occurs later:

20: 270
15: 270
10: 270
5: 270
0: 270
-5: 270
-10: 270
-15: 270
-20: 90

The difference is probably to do with internal precision in Perl and C
libraries rather than the equations themselves.

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.


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

2004-11-03 Thread David Megginson
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] RE: [OFFLINE] Plea for help: geometry/trigonometry problem

2004-11-03 Thread David Megginson
On Wed, 3 Nov 2004 19:40:57 -0600, Jon Berndt [EMAIL PROTECTED] wrote:

 Well, I don't know if my calculations helped any, but it sure was a fun diversion 
 for a
 little while ...

Since Jon accidentally went online with this, I'd like to thank him
for the work.  It turned out that I didn't need to add the extra steps
(that I had asked for before seeing Chris's equation).


Thanks,


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

2004-10-30 Thread David Megginson
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

2004-10-26 Thread David Megginson
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

2004-10-21 Thread David Megginson
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

2004-10-20 Thread David Megginson
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

2004-10-12 Thread David Megginson
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


  1   2   3   4   5   6   7   8   9   10   >