Re: [Flightgear-devel] outerra news

[David Megginson]

On Sun, Jun 6, 2010 at 7:35 AM, Martin Spott  wrote:

>> Maybe we should consider moving to a different OpenSource scenery
>> package.
>
> I'd be happy to read a more elaborate statement of what you're having
> in mind. What is the term "scenery package" supposed to mean ?

An Open-Source package including scenery-generation tools and a
scenery-rendering library.  Our biggest challenge, I think, would be
finding one that supported atmospheric rendering (weather, etc.) as
well as terrain.


All the best,


David

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] outerra news

[David Megginson]

Maybe we should consider moving to a different OpenSource scenery
package.  Nothing met our needs in the late 1990s, but I'm sure
they've progressed since then.


David

On Fri, Jun 4, 2010 at 8:59 PM, Peter Morgan  wrote:
> Is there a begginers guide ?
> I've been down this path before got stuck with terra and some
> sgrequirement.. never worked..
> pete
>
> On Fri, Jun 4, 2010 at 10:20 PM, Martin Spott 
> wrote:
>>
>> Gene Buckle wrote:
>>
>> > That is just amazing.  TerraGear should do that. :)
>>
>> Everyone's invited to contribute  ;-)
>>
>>   http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs
>>
>> Cheers,
>>        Martin.
>> --
>>  Unix _IS_ user friendly - it's just selective about who its friends are !
>> --
>>
>>
>> --
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Is something amiss with altimeter settings?

[David Megginson]

It's been a long time, but in addition to any issues with your
altimeter setting I *think* I might have added code ~8 years ago to
simulate the effect of temperature on altimeter readings.  In real
life, even if you have exactly the correct altimeter setting for the
ground below you, and the altimeter is perfectly calibrated, your
altitude can be off by hundreds or thousands of feet from what you see
on the altimeter.

Generally speaking, you'll be lower than you think if the temperature
is below ISA, and higher than you think if the temperature is above
ISA, because temperature affects how much the air pressure changes
with altitude.  The altimeter is calibrated to assume 15 degC at sea
level and a perfect consistent temperature gradient above that.


All the best,


David


In Canada, we're required to increase minimum altitudes for
approaches, etc., when temperatures are cold.  We also have designated
mountainous regions where you have to fly higher in the winter.

On Sat, May 29, 2010 at 1:02 PM, Rob Shearman, Jr.  wrote:
> Hi there --
>
> Recently while flying with the MD-81 at cruise levels of FL330 or so, I
> noticed there were some significant discrepancies between the displayed
> altitude and the altitude found in the property tree at
> /position/altitude-ft.  I was able to observe the same problem in the
> 777-200ER -- I flew a flight at 33000 and the Flight Tracker reported my
> altitude at close to 35000.  So the discrepancy at cruise is as much as
> 1000-2000 feet sometimes, even when using the altimeter setting reported in
> the METAR (which, of course, you're not supposed to do above 18,000 in the
> U.S., but for testing purposes I did so to see if it accounted for the
> error).
>
> However, today loading up my custom ATC scope I observed a discrepancy in
> altimeter readings which may account for the problem.
>
> http://i289.photobucket.com/albums/ll209/rmsjr1974/altimeter-discrep.jpg
>
> Notice in the shot that the METAR is reporting 29.94, but the property tree
> and the scope panel are arriving at 29.90.  I presume at high altitude this
> discrepancy would account for differences in the gauge reading.
>
> This is with the 25 April CVS build, so if altimeter code has changed since
> the migration to git, I apologize in advance.
>
> Thanks,
> -R. (MD-Terp)
>
> Robert M. Shearman, Jr.
> Transit Operations Supervisor,
> University of Maryland Department of Transportation
> also known as rm...@umd.edu
>
>
> --
>
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>

--

___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear's Best Features

[David Megginson]

On Fri, Apr 23, 2010 at 3:11 AM, syd adams  wrote:

> This is news to me. Which instrument models the drift ? I thought none did ,
> so I created a nasal gyro
> that drifts at 3 degrees/15 minutes for my own use. Apparently I haven't
> looked close enough at the instrument code .

After I got my PPL and bought my plane in 2002, I put a huge amount of
work into making all of the instruments realistically inaccurate to
reflect my actual flying experience -- they have lags, drift, etc.
just like the real steam gauges.  Other coders have contributed and
improved since then.  Try flying north of 45 deg latitude, for
example, and watch how the magnetic compass behaves in turns, climbs,
etc., and also watch how the VSI lags by as much as a couple of
seconds in a climb or descent.


David

--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear's Best Features

[David Megginson]

I think FSX uses a round earth model and non-flat runways as well.

David

On Apr 22, 2010 9:29 PM, "Curtis Olson"  wrote:

Here are a couple things off the top of my head ...

- FlightGear is currently powering several FAA certified pilot training
devices (www.atcflightsim.com)

- Flightgear uses a wgs-84 round earth model so you can fly from your real
aviation charts and hit all the intersections and radials and headings right
where they should be.

- FlightGear has all the stars in the correct place in the sky for the
current time and location as well as the sun and the moon and the planets,
and the moon with proper phase ... you probably didn't know that Durk. :-)

- FlightGear's runways are not exactly flat ... just like in the real world
they follow the lay of the land and there can be substantial differences in
altitude from one end of the runway to the other.

- FlightGear's autopilot code has been used to fly real UAV's autonomously
in the real world ...

- FlightGear has some of the most realistic and complete helicopter flight
dynamics available in PC sims.

- FlightGear has an awsome V22 Osprey model that is a total blast to fly
once you get the hang of it.

- FlightGear supports multiple monitors on a single PC.  We've demonstrated
a system with 8 displays all connected to a single (quad-core) PC.  One box
driving 8 displays (4 pci-express video cards) ... limited not by
FlightGear, but how many displays you can plug into your machine.

- FlightGear has been around for 14 years of active development!

Regards,

Curt.


On Thu, Apr 22, 2010 at 7:39 PM, James Sleeman  wrote:


>
> On 23/04/10 08:44, David Megginson wrote:
> > Easy to set up for the command line, so you can l...



-- 
Curtis Olson: http://baron.flightgear.org/~curt/

--

___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear's Best Features

[David Megginson]

We actually try to emulate the aircraft's systems (vacuum, pitot,
static, electrical, etc.), so failure modes are much more realistic.

Instruments update more realistically, with suitable lags and other errors.

MSFS X has improved its flight models, but in general, I still find
that both JSBSim and YASim models often feel more realistic (JSBSim is
better in regular flight, but YASim sometimes does a better job around
stall, spin, etc.).

Easy to set up for the command line, so you can launch straight into a
practice approach without clicking through a bunch of screens (and can
randomize things like wind).


All the best,


David


On Thu, Apr 22, 2010 at 3:30 PM, Durk Talsma  wrote:
> Hi All,
>
> Today at work I ran into somebody who writes a column on flight simulation for
> the Dutch aviation magazine "Piloot & Vliegtuig" (Pilot and Aircraft), a
> magazine for real life pilots. Although he knew about FlightGear, he wasn't
> very aware of the details of the program.  He seemed to be interested in the
> possibility of writing a column about FlightGear though, so I promised to send
> him a brief list of unique features of FlightGear that are predominantly of
> interest of real-life GA pilots, and which can't be found in Microsoft's FSX.
> In addition, I'll probably give him a tour of our lab's setup, once that one's
> fully up and running again.
>
> Although I have a fair idea what those unique features might be, this might be
> an excellent opportunity to incorporate some input from real-life pilots. Any
> suggestions are welcome though.
>
> Cheers,
> Durk
>
>
>
> --
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Normal map shader example - c172p

[David Megginson]

All the Cessna 172's I've seen have had protruding rivets, but the
heads don't stick out much, and the paint smooths out the edges to the
point that they're just gentle bumps -- a 172's wing doesn't look like
a steam boiler.

IIRC, the Mooney has countersunk rivets, which is why it can go so fast.


All the best,


David

On Tue, Apr 13, 2010 at 5:18 PM, Bertrand Coconnier  wrote:
> 2010/4/13 Stuart Buchanan :
>> Bertrand wrote:
>>> This is some nice artistic/graphical work indeed, however, I am afraid
>>> this is not very realistic. If you want Cessna aerodynamicists to die
>>> from an heart attack, just show them this picture ^_^
>>
>> :)
>>
>> I was basing the work on some photos I found on the Cessna website.
>> This one in particular seemed to show raised rivets on the wing:
>>
>> http://www.cessna.com/MungoBlobs/832/502/sin_haw_flt18_hires.jpg
>>
>> Perhaps what I'm seeing there isn't actually protruding rivets at all.
>>
>> Is there any height change there at all, or are the surfaces completely 
>> smooth?
>>
>> I could obviously tone down the effect significantly to make them
>> protrude less if
>> that is more realistic.
>>
>> BTW - we're modeling a P model, if that makes any difference.
>>
>> -Stuart
>>
>
> Well spotted Stuart. They look very much like protruding rivets.
>
> May be what I reported above is limited to some specific class of
> aircrafts ? A Cessna C172 is a relatively cheap aircraft flying at low
> speeds, may be this is why Cessna are using protruding rivets (which
> are cheaper than countersunk rivets). May be it only makes a
> difference at higher speeds ? It seems I have extrapolated my
> experience to an area where it does not apply ^_^ As you may have
> guessed I am not an aerodynamicist myself, moreover my own experience
> is limited to airliners where, I think, the criteria are more
> stringent than for small aircrafts... Or may be in Cessna the design
> office have won the battle against aerodynamics ? ^_^
>
> Anyway my contribution was not much worth it... Next time I will check
> closer ^_^
>
> Cheers,
>
> Bertrand.
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Excellent new J3 Cub model

[David Megginson]

On Tue, Apr 13, 2010 at 2:45 AM, Erik Hofman  wrote:

> It is already removed from CVS. It's just a matter of running cvs up -Pd
> to also remove it from your local repository.

I always do cvs -z3 update -d -P, but when I replied, I hadn't checked
to see if it was still on my machine (it's not).

Should we also set up j3cub as an alias, to provide a smooth
transition for anyone who had the old Cub as his/her default aircraft,
or is that just being overly solicitous? :)


Thanks,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Excellent new J3 Cub model

[David Megginson]

On Mon, Apr 12, 2010 at 3:20 PM, Heiko Schulz  wrote:

> What I wonder- if David Megginson gave permission- why we have now the same 
> aircraft with two different models in CVS? One named "j3cub" and one named 
> "Cub".

No, pull the old one.  It was a lot of fun to build, and was (I think)
our second taildragger, when we were still figuring out how to model
gear, but there's no reason to keep it around now.

I'd love to make this new model our default aircraft, as the real J3
has been for so many tens of thousands of new student pilots
historically, but the taildragger thing might scare away users.

A couple of queries about the (most excellent) new model:

1. Shouldn't there be some kind of an inclinometer (slip-skid ball) on
the panel?  I think I've seen one in most J3 panel photos, and it's
pretty useful.

2. Where's the black lightning bolt on the side? (That's just a joke
-- I actually think it's cool that we're not following the cliché
here).


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Yoke mounted PDA

[David Megginson]

Cool, but wouldn't it make sense to support common portable aviation
GPS's first?  As far as smartphone-type-things go, it's hard to get
any wireless coverage in the air (they started blocking upward
transmission about 3-4 years ago), and the iPad is so big it would
block most of the primary instruments anyway, but you'll find one of
the units from this page attached to the yoke of most privately-owned
planes:

https://buy.garmin.com/shop/shop.do?cID=156

(I use an old GPSMap 196 myself, and it serves me very well).


David

On Mon, Apr 12, 2010 at 4:59 AM, Victhor  wrote:
> I made an iPad that looks pretty OK, but it used images from the Apple
> website as textures, so not completely GPL :)
>> Has anyone made a 3D model of a PDA that attaches nicely to the
>> existing yoke XML files?  I'm thinking of portrait orientation with
>> the form factor of an iPhone, android phone, etc, etc.
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug: landmass effects cause system crash in today's CVS FlightGear

[David Megginson]

On Wed, Apr 7, 2010 at 9:10 AM, Frederic Bouvier  wrote:

>> Your card or driver advertise support of geometry shader but doesn't
>> behave correctly with them. If the extension wasn't supported, the
>> effect would have fallbacked to technique number 9 that doesn't use
>> them.
>>
>> I think there is an OSG environment variable (OSG_GL_EXTENSION_DISABLE
>> iirc) to disable buggy extension, and fgrun allows to set environment
>> variable before starting fgfs.
>
> set OSG_GL_EXTENSION_DISABLE=GL_EXT_geometry_shader4
> should work

That did the trick -- thanks, Fred.  We should probably add this to a
FAQ somewhere, if it's not already there.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] mpmap ILS data

[David Megginson]

On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown  wrote:

> I see.  So that brings us back to magnetic vs true, as I was originally 
> referring to.  But, that's somewhat irrevelant as it _appears_ the mpmap is 
> sourcing the data from the actual runway placement.  My opinion is there 
> should be an data file with the correct info to be displayed, and it seems 
> logical for it to be the navaid file, but we'd need to add a line if they 
> want to keep the true heading.

Again, I haven't used mpmap, but are you certain it is trying to
display an ILS localizer, and not just an extended runway centreline?
You're right, of course, that it might have messed up true vs.
magnetic (especially if the developer was working somewhere with very
little  magvar, and wouldn't have noticed during testing).  Our files
list actual runway headings in degrees true as well, so the only thing
I can think is that the developer just took the runway *number* and
converted it to a heading.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] mpmap ILS data

[David Megginson]

On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown
 wrote:

> David, yes, as I have as well.  The localizer for 33 as you listed above is 
> on a 326 heading per the approach plate, but the mpmap shows ILS data as the 
> runway heading in degrees - as if for users to use as the ILS data.  I'm not 
> sure what the 342 in the navaid file is referring to unless it's 
> elevation?... elev. is 335, course is 326.  (ref: 
> http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf)

The plates give the heading in degrees magnetic; the data file gives
it in degrees true.  That's still a degree off (BTV is 15W, IIRC), but
it's pretty close, and nav.data.gz may be based on old data.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] mpmap ILS data

[David Megginson]

On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown
 wrote:

> Perhaps this has been brought up before, but I see that the ILS "beam" data 
> for each airport on the mpmap is derived from the runway alignment (as 
> verified in taxidraw).  This doesn't allow for magnetic deviation, and 
> therefore all the course headings are incorrect.  Makes it tough to line up 
> with the ILS, unless you pull info from an outside source (airnav, 
> flightaware, etc) for each arrival airport.

> Example at KBTV, runway 15 -
> mpmap ILS course 130.92 degrees
> Flightaware ILS approach plate, 146 degrees.

I'm not familiar with mpmap, but that's not a problem for FlightGear
itself - the localizer directions are all specified in
Navaids/nav.dat.gz in degrees true, independently of any runways they
might be associated with (not all localizers are attached to a runway,
and even when they are, the direction might be 10 degrees off from the
runway).  Here's the example for BTV (where I've flown the localizer
in real life as well as in FlightGear):

12  44.4652 -073.14009400342 11030  18   0.000 IVOE KBTV 33  DME-ILS

But then, the vast majority of runways don't have localizers.  Perhaps
the map is just trying to show an extended runway centreline, and the
person who designed the app mixed up magentic and true heading.  The
Airports/apt.dat.gz file does give runway headings in degrees true,
not degrees magentic, so there's no need to mess around with magnetic
deviation.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] AI-Balloons

[David Megginson]

On Wed, Apr 7, 2010 at 10:39 AM, Torsten Dreyer  wrote:

> I have just commited the add-on from the forum user gooneybird to the CVS-
> data. If you enable the balloon_demo scenario in your preferences.xml, you
> should see some balloons  ahead of you aircraft after starting FlightGear.
> They get takeoff clearance before you will within the next minute and they
> will leave the ground soon. The will climb to approx. 2000ft above ground and
> drift away with the wind.

Sounds great!  And a quick reminder: balloons have right of way over
powered aircraft and gliders, just like sail over steam on the water.
:)


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug: landmass effects cause system crash in today's CVS FlightGear

[David Megginson]

On Tue, Apr 6, 2010 at 4:19 AM, Frederic Bouvier  wrote:

> I presume it's the geometry shader support that is causing this. Try to 
> disable technique number 8 in landmass.eff
> regards,

That was it -- no crash after commenting it out.  Is it likely a
problem with my graphics card driver, or the FlightGear code?


Thanks,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Issue with default starting scenario

[David Megginson]

On Tue, Apr 6, 2010 at 7:34 PM, Peter Brown  wrote:

> In terms of simplicity, I would like to offer a suggestion of using one (or 
> more) of the parking positions at airports with (current) parking positions.  
> If the user spawns at an airport without any preset parking positions, a 
> position of  :: 90 degrees to the runway and nose at runway edge ::  should 
> work for _most_ airports, until that airport is improved and gets a parking 
> position.
>
> James suggestion of a multiplier can work, but I would suggest no more then 
> (width*1) from the runway.  Too many small airports would drop you in the 
> woods at a greater multiplier.

I realize I'm flogging a dead horse (and won't be offended if people
tune out), but I just want to mention planes will very rarely be
parked close to the runway, to avoid accidents if someone gets blown
off the runway, ground-loops, etc.  A plane parked near the runway
with fuel in its tanks could make a deadly fireball out of what would
otherwise be a bit of gear damage, a few broken runway lights, or (at
worse) a bent wing.

I have seen exceptions, mainly at private and uncertified airports
(e.g. farm strips), but normally planes are parked with their noses
against a taxiway, not the runway (or otherwise, a safe distance away
on a field or apron).


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Issue with default starting scenario

[David Megginson]

On Tue, Apr 6, 2010 at 7:06 PM, James Turner  wrote:

> My concern is touching the dreaded position init code, which is already 
> baroque and complex. There's also the question of guessing a parking position 
> when we don't have parking stand data - eg picking a point some distance away 
> from the runway centerline (runway width * 5, maybe?), level with the 
> threshold - but like all heuristics, this one has problems.

OK, here's my suggestion: *all* aircraft start with the runway
threshold with the engine idling, unless the user has overridden that.
 Engine on/off is a decision that it doesn't make sense leaving to
individual aircraft designers, since it's a cross-cutting user
experience question.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Bug: landmass effects cause system crash in today's CVS FlightGear

[David Megginson]

When I enable landmass effects in a FlightGear binary built from
today's CVS (and using today's base package), my entire computer
freezes and I can reboot only by cutting power. Urban effects still
work, however.

With a binary built from the March 13 CVS, I can enable landmass
effects -- still using today's base package -- with no bad effects.

I'm using Ubuntu Lucid, with this card info from the X log:

(--) PCI:*(0:1:5:0) 1002:9612:103c:3045 ATI Technologies Inc
RS780M/RS780MN [Radeon HD 3200 Graphics] rev 0, Mem @
0xc000/268435456, 0xd230/65536, 0xd220/1048576, I/O @
0x5000/256

and

(II) Module glx: vendor="FireGL - ATI Technologies Inc."
compiled for 7.5.0, module version = 1.0.0


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Issue with default starting scenario

[David Megginson]

I temporarily moved my .fgfsrc file and .fgfs/ directory to see what a
new user sees on first startup, and I think what's there is not the
best idea (unless there's still some local configuration that I'm
missing):

1. it's normal to have a plane sitting on the runway threshold with
the engine idling
2. it's normal to have a plane sitting in a parking spot on the apron
with the engine off
3. it's *not* normal to have a plane sitting on the runway threshold
with the engine off

Except in the case of an accident or mechanical failure, you would
*never* be sitting on the threshold with your engine off, especially
at a big airport like KSFO (unless you wanted to give your plane and
yourself a 747-sized colon exam).  I think that  option #1 is ideal
for new users, but option #2 would be OK if we want to distinguish
ourselves from MSFS by making things more difficult.

So, in brief, we have to make a choice: either move the default
starting position off the runway, or (preferably) start on the runway
threshold with the C-172 engine already idling.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Kids Training Manual

[David Megginson]

On Mon, Apr 5, 2010 at 6:05 AM, Pete Morgan  wrote:

> I've packed it up in a slide show. Here's the results.
> http://flightgear.daffodil.uk.com/slide_shows/

Excellent!  Thanks.


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Cherokee flap steps

[David Megginson]

I noticed this TODO issue on the Piper Warrior wiki page
(http://wiki.flightgear.org/index.php/Piper_Cherokee_Warrior_II):

"flaps are moving in steps, they are not fluxional animated"

This is true, but might also be a bit confusing.  Flap movements do
appear almost instantaneous on a PA-28 compared to, say, a C172,
because the flaps are mechanically connected to a long metal bar which
the pilot yanks from one step to another.  It's hard to estimate, but
on my own Warrior, I'd say that the flaps spend something like 0.2
seconds in transit between steps, and it would be even less if I chose
to move my arm faster.  To the normal observer, they *will* almost
appear to jump instantly from step to step.

On a C172, on the other hand, the flaps are electric, and have slow,
gradual movement from one stop to another.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Kids Training Manual

[David Megginson]

On Wed, Mar 31, 2010 at 1:23 AM, Pete Morgan  wrote:

> Fanstastic.. had a wuick look and its cool.
>
> Can I please lift the page and format it as a slideshow ?

All yours -- consider it public domain.  It might be worth capturing
screenshots with newer 3D models and scenery, though.

I wrote that tutorial just after finishing my initial flight training
in 2002, and it's based on the standard pitch+power=performance model
of teaching.  It works nicely for FlightGear and for real-life flying
lessons, but can run into trouble in less controlled environments:
http://www.megginson.com/blogs/lahso/2005/04/04/power-pitch-stall/


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Kids Training Manual

[David Megginson]

Here's one that I wrote back in 2002:

http://www.flightgear.org/Docs/Tutorials/circuit/index.html


All the best,


David

On Tue, Mar 30, 2010 at 8:02 PM, Pete Morgan  wrote:
> Problem I got with newbies..
>
> Is there a simple set of instruction we can create (and laminate) of ::
>
> how to take off,
> make and ewe drop
> and come back and miss the first landing
> then go around another way
> and come back to land?
>
> no wind etc..
> just for kids?
>
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Reflection Shader

[David Megginson]

Wow -- looks amazing!  I wonder what that would do to my framerate
with my laptop's poor little ATI HD 3200 card?


All the best,


David

On Mon, Mar 29, 2010 at 5:50 AM, Vivian Meazza
 wrote:
> Hi,
>
> Lauri Peltonen and I have been working on a reflection effect:
>
> ftp://ftp.abbeytheatre2.org.uk/fgfs/Shader/LightningF1-1.png
>
> ftp://ftp.abbeytheatre2.org.uk/fgfs/Shader/LightningF1.png
>
> This uses a generic fair-weather environment map, currently 6 images. We are
> working on using a "cube-cross", which should be simpler for the user to
> apply. Other maps are possible in due course. The amount of reflection,
> fringing colour, and Fresnel effect are all adjustable, and you can tweek
> the ambient light to get the effect you want.
>
> We await the inclusion of the required patch in SimGear, meanwhile for
> anyone feeling brave:
>
> ftp://ftp.abbeytheatre2.org.uk/fgfs/Shader/Reflect/cube-map.patch
>
> We expected that it will be included soon.
>
> Vivian
>
>
>
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] High Priority: fixing the Great Lakes...

[David Megginson]

Very nice work!  I remember when all land cover in FlightGear (other
than runways) was desert -- not sure why Curt picked a desert texture
(I think it had something to do with Prescott, AZ).  Next, we were
able to separate land (always forest) from water.  It's come a long
way since then.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] High Priority: fixing the Great Lakes...

[David Megginson]

Quite a few years ago we had a debate, because we had to choose
between two sets of shoreline data:

1. GSHSS was very nicely detailed (every little cove and point), but
about 1 mile off for the Great Lakes, leaving shoreline airports
either far inland or floating in the middle of a lake.

2. Vmap0 was much lower resolution (only big bays and points), but
actually had the Great Lakes shorelines in roughly the right place.

Since I was doing most of the TerraGear coding that year, I forced
through vmap0, but a lot of people objected -- I thought it was OK for
the Toronto harbourfront, but I don't remember for certain, and I
don't know what FlightGear is using now.


All the best,


David

On Sun, Mar 28, 2010 at 5:18 PM, David Slocombe  wrote:
> On Sunday 2010-03-28 David Megginson wrote:
>> Now, quite a few years later, the Great Lakes are still
>> broken in our default scenery, and as a result, FlightGear
>> looks ridiculous to any new user who comes and tries flying
>> in near cities such as Toronto, Rochester, Buffalo, Cleveland,
>> Detroit, Chicago, or Milwaukee.
>
> Sometimes pictures really *are* worth a thousand words. I think
> this is one of those times.
>
> I've put up on the Web (temporarily: they won't be there forever)
> three screen snaps:
>
> Please go to http://www.vex.net/~slocombe/fgfs-pics-of-CYTZ/ for
> pictures illustrating the problems of CYTZ (Toronto/City Centre),
> which is on an island in Lake Ontario just offshore from Toronto's
> downtown area.
>
> 1. cytz-from-08-apprch.png : CYTZ from the approach viewpoint
> of Runway 08 (08/26 is the principal runway of this extremely
> busy airport: Bombardier Dash8-Q400's take off or land about
> every 20 minutes, and in between that traffic Cessna 150's and
> 172's practise circuits or transit to/from Toronto's
> "practice area" to the East. I'm one of the student pilots these days.
>
> The fact that, in fgfs, the water is 240 feet below its real-world level
> is only a small part of the problem (in fact if that were the
> only problem one could just pretend one is practising landings
> on aircraft carriers). The terrain data, intersected by the
> water at its current level, makes the shoreline wildly wrong...
>
> 2. cytz-overhead-at-40Kft.png : This is taken with the UFO
> tool at 40,000 ft., looking straight down.
>
> 3. google-image-cytz.png : a snap of what Google has for
> a satellite shot, to compare with the previous shot.
>
> I'm not convinced that the terrain data that fgfs uses is
> sufficiently detailed to capture even the approximate
> shape of the Toronto Islands (what CYTZ is on the Western
> end of), let alone the Leslie Spit and docklands to the East.
> So I'm not sure how different this is going to look if the
> water-level were correct. But surely it would make a difference,
> and there are > 700 miles of shoreline for Lake Ontario,
> and another > 800 miles for Lake Erie: all of this would
> be affected by a "fix". I presume the shoreline in the
> St. Lawrence River near Montreal must be seriously wrong too.
>
> BTW, Just For Kicks, I can fly *under* CYTZ. It doesn't
> seem to do me damage, and fgfs doesn't even crash! :-)
>
> Thanks everyone for the great achievement that fgfs is.
> It was fgfs that got me sufficiently enthused about flying
> to decide to get my PPL.
>
> David Slocombe
> Toronto Canada.
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] High priority: fixing the Great Lakes in

[David Megginson]

On Sun, Mar 28, 2010 at 1:58 PM, Martin Spott  wrote:

> In the meantime we've made a polygon set to seamlessly fill The Great
> Lakes Void - which is likely going to address the issue you've
> mentioned. But there are still a few other places which are presumably
> affected by the same cause (Caspian Sea, I guess, and probably the Dead
> sea as well   mmmh, maybe we've already fixed these as well).

That's great news -- thanks, Martin!  I'll look forward to the new
scenery.  Right now, I can't bring myself to practice approaches at
waterfront airports, with the giant cliffs all around them.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] High priority: fixing the Great Lakes in FlightGear default scenery

[David Megginson]

When I originally added ground-use support to TerraGear many years
ago, the Canada/US Great Lakes worked fine: we simply treated the
water as a special ground use, used the DEM to get the elevation,
clipped it against the VMAP0 coastlines, and for good measure, Curt
had written code to average out the elevation of water areas to remove
bumps, etc.  The surface of Lake Superior or Lake Ontario might be a
few feet high or low, but it was pretty hard to notice.

Then, just before I left the project, something got badly broken in
TerraGear and/or its input datasets: it changed so that any water
connected to the ocean was forced down to sea level, although the
real-life surfaces are as high as 600 ft MSL.  Now, Chicago sits
perched atop cliffs hundreds of feet high overlooking Lake Michigan,
and rivers run through (non-existant) fjords.  I think someone
originally had a grandiose plan to build a water network, and wanted
eventually to model locks, rapids, waterfalls, etc. to account for
changes in water surface elevation, but that never happened, and to be
honest, we should never have let the code into production until it
worked.

Now, quite a few years later, the Great Lakes are still broken in our
default scenery, and as a result, FlightGear looks ridiculous to any
new user who comes and tries flying in near cities such as Toronto,
Rochester, Buffalo, Cleveland, Detroit, Chicago, or Milwaukee.  Is
there any reason that we can't restore the old code, and treat inland
water like a (specially flattened) land use, at least until someone
fixes the newer water-network code?  Is there anything else we can do
to address this problem?  Were we forced into this because of
different GIS datasets?


Thanks, and all the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)

[David Megginson]

Looks fantastic!


David

On Tue, Mar 23, 2010 at 4:22 AM, Erik Hofman  wrote:
> Frederic Bouvier wrote:
>> visible. Now I think I managed to get it right with 3d objects. See :
>> http://frbouvi.free.fr/flightsim/fgfs-city-relief-4.jpg
>
> Even more impressive!
>
> Erik
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug: nav[12] selected radial

[David Megginson]

On Sat, Mar 20, 2010 at 9:41 PM, John Denker  wrote:

> There was a bug reported under the Subject:
>  [Flightgear-devel] Setting OBS on command line/.fgfsrc
> a couple of weeks ago ... but it only affected nav1 IIRC.
> And it had nothing to do with magnetic variation IIRC.

Perhaps not, but try this:

fgfs --ndb=YRR --altitude=3000 --vc=100 --nav1=340:114.6

When it starts, the radial on the nav1 indicator will be set not to
340 but to the true equivalent (around 326).  When you start at an
airport, the radial will be aligned with the runway no matter what you
put on the command line -- that's probably the GPS bug.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug: nav[12] selected radial

[David Megginson]

On Sat, Mar 20, 2010 at 7:22 PM, James Turner  wrote:

> There's another bug (in 2.0.0) to do with the GPS interaction with the nav[0] 
> selected radial - I must say I've assumed all problems with --nav1 options 
> misbehaving are ultimately caused by this bug, but it sounds as if you think 
> there's worse things going on.

Actually, I think that might be it.  It's hard to experiment right
now, because I'm in Lucid with the slow open source driver until the
ATI proprietary drivers come out, so start-up time takes forever.

> (I tend to test around my home airport, EGPH, where the magnetic variation is 
> not very noticeable compared to many other parts of the world)

We're around 14W here -- just enough to notice.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug: nav[12] selected radial

[David Megginson]

On Sat, Mar 20, 2010 at 6:19 PM, Curtis Olson  wrote:

> Hmmm, the nav database had the actual radial alignment of the station
> relative to true north and I remember sorting that out so that when you fly
> off a chart, everything would be in chart-agreement when you flew to radial
> intersection points.  Bummer if that got broke along the way ... I haven't
> checked it recently.

It would take hours to sort out the code to see what's actually
happening.  The new init functions make things even more confusing, by
including strange side effects (for example, setting the heading now
sets the azimuth to a VOR or airport, and may also set the selected
radial on a VOR).  I used to help a lot with this stuff, but I don't
think I have the energy now.


All the best,


David

> Curt.
>
> On Sat, Mar 20, 2010 at 5:09 PM, David Megginson  wrote:
>>
>> There's a bug in the /instrumentation/nav/radials/selected-deg
>> property: the code mistakenly assumes that the selected radial is in
>> true degrees, but isn't a bearing -- it's just a number.  You could
>> design a VOR where radial 180 was north of the VOR, if you wanted to
>> (though usually it's close to a bearing in *magnetic* degrees).  The
>> bug affects the --nav1 and --nav2 option in particular, since
>>
>> --nav1=340:114.6
>>
>> will no longer start FlightGear with the Nav1 indicator dialed to the
>> 340 radial, unless the local magnetic variation happens to be 0.  At
>> CYRO, for example, the actual radial ends up being closer to 326,
>> which is counterintuitive.  Nav radios and indicators know nothing
>> about magnetic variation.
>>
>> We used to have this right in FlightGear, but it's gotten messed up
>> over the last 3-4 years.  I'd like to fix it, but I'm worried about
>> how many places we've hardcoded this assumption.  How hard will it be
>> to correct this?  How many of you have designed radios, autopilots,
>> etc. counting on this bug?
>>
>>
>> Thanks,
>>
>>
>> David
>>
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
>
> --
> Curtis Olson: http://baron.flightgear.org/~curt/
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug: nav[12] selected radial

[David Megginson]

It's actually even more confusing than that: the initial value seems
to depend on whether the --vor option is selected, what the heading
is, etc.


All the best,


David

On Sat, Mar 20, 2010 at 6:09 PM, David Megginson
 wrote:
> There's a bug in the /instrumentation/nav/radials/selected-deg
> property: the code mistakenly assumes that the selected radial is in
> true degrees, but isn't a bearing -- it's just a number.  You could
> design a VOR where radial 180 was north of the VOR, if you wanted to
> (though usually it's close to a bearing in *magnetic* degrees).  The
> bug affects the --nav1 and --nav2 option in particular, since
>
> --nav1=340:114.6
>
> will no longer start FlightGear with the Nav1 indicator dialed to the
> 340 radial, unless the local magnetic variation happens to be 0.  At
> CYRO, for example, the actual radial ends up being closer to 326,
> which is counterintuitive.  Nav radios and indicators know nothing
> about magnetic variation.
>
> We used to have this right in FlightGear, but it's gotten messed up
> over the last 3-4 years.  I'd like to fix it, but I'm worried about
> how many places we've hardcoded this assumption.  How hard will it be
> to correct this?  How many of you have designed radios, autopilots,
> etc. counting on this bug?
>
>
> Thanks,
>
>
> David
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Bug: nav[12] selected radial

[David Megginson]

There's a bug in the /instrumentation/nav/radials/selected-deg
property: the code mistakenly assumes that the selected radial is in
true degrees, but isn't a bearing -- it's just a number.  You could
design a VOR where radial 180 was north of the VOR, if you wanted to
(though usually it's close to a bearing in *magnetic* degrees).  The
bug affects the --nav1 and --nav2 option in particular, since

--nav1=340:114.6

will no longer start FlightGear with the Nav1 indicator dialed to the
340 radial, unless the local magnetic variation happens to be 0.  At
CYRO, for example, the actual radial ends up being closer to 326,
which is counterintuitive.  Nav radios and indicators know nothing
about magnetic variation.

We used to have this right in FlightGear, but it's gotten messed up
over the last 3-4 years.  I'd like to fix it, but I'm worried about
how many places we've hardcoded this assumption.  How hard will it be
to correct this?  How many of you have designed radios, autopilots,
etc. counting on this bug?


Thanks,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Messy properties for nav radios

[David Megginson]

I'd like to encourage everyone to put properties where they would
belong in real life -- I took a look at the properties for the nav
radio, and they gave me a bit of a headache.

Think of what a nav radio and indicator do and don't know in real life:

Does know:

- what frequency is tuned in on the radio (and the alternate)
- what radial the pilot has selected on the indicator
- whether it's receiving a VOR/localizer
- whether it's receiving a GS
- whether the TO or FROM flag is showing
- whether the ident volume is turned up
- the GS and CDI deviation

etc.

Doesn't know:

- the true heading/bearing of the VOR radial
- the time to intercept the VOR or radial
- the VOR's error
- distance to the VOR

etc.

I understand that these properties are convenient for other systems,
but they should go somewhere they would be in real life, like a DME,
GPS database or FMS, not in the (relatively dumb) nav radio itself
under /instrumentation/nav/.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)

[David Megginson]

On Thu, Mar 18, 2010 at 5:56 PM, Frederic Bouvier  wrote:

>> I noticed the same problem with roads and 3d buildings -- they're
>> floating above the city.  Is it possible to make the bump maps go up
>> instead of down?
>
> In Shaders/urban.frag, change line 57 :
>
>        vec2 dp = gl_TexCoord[0].st;
>
> into :
>
>        vec2 dp = gl_TexCoord[0].st - ds;
>
> Tell me what do you think. Try to land in the city.

I didn't seem to make any difference -- 3D buildings, trees, etc. were
still floating above the roofs of the bump-map buildings.  I also
tried

vec2 dp = gl_TexCoord[0].st + ds;

and

vec2 dp = gl_TexCoord[0].st - 2 * ds;


Thanks,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)

[David Megginson]

On Thu, Mar 18, 2010 at 8:43 AM, Torsten Dreyer  wrote:

> First of all: That's a really cool eye candy, good work!

Seconded.  This is the coolest addition I've seen to FlightGear in a long time.

> What I noticed from a close up is, that it seems that the floor of the
> "buildings" is below elevation zero and the roof is at elevation zero. It
> looks somewhat as if the cities were carved out of the landscape instead of
> been built uppon it. This is especially irritating when a waterway is crossing
> an urban area and the water surface is several meters above the ground.

I noticed the same problem with roads and 3d buildings -- they're
floating above the city.  Is it possible to make the bump maps go up
instead of down?


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] News from FlightProSim!

[David Megginson]

This kind of thing happens sometimes -- not much we can do unless we
want to spend tens of thousands of $$ going to court, so there's no
point getting stressed.  I did go to Google Sidewiki and leave a
comment on the page, so that anyone using the Google toolbar or a
sidewiki add-on in their browser will see this as the first (and so
far, only) comment:

  Just a repackaged free flight sim

  Although this site doesn't admit it, Flight Pro Sim appears to be
just a repackaging of the open source
  FlightGear flight simulator, available at http://www.flightgear.org/

Maybe other people would like to add similar comments.  I like
SideWiki because it prevents sites from censoring open commenting on
any web page (though I'd be happier if a single company didn't control
it).


All the best,


David

On Mon, Mar 15, 2010 at 3:27 PM, kyle keevill  wrote:
> Has anyone tried putting their own watermarks on their models and liveries? I 
> usually put my watermark on the engine, then again, we could put a flightgear 
> watermark on the inside of a model (image mapping the inside of a model so he 
> can't see it)
> Also, has anyone checked to see if he's a part of this mailing list? (and for 
> forum wise, block his IP so he can't post anymore). I'm actually thinking 
> about posting a screen shot of his webpage where is shows that FPS is based 
> on FG.
>
> In other news, there's no wiki on FPS, but there is one on FG, should we post 
> a warning on the FG one or make an FPS page and leave a note that redirects 
> to the FREE version of fps?
>
> sorry if i start an argument, just trying to help.
> On Mar 15, 2010, at 2:15 PM, Jon Stockill wrote:
>
>> Curtis Olson wrote:
>>> On Mon, Mar 15, 2010 at 12:56 PM, Frederic Bouvier >> > wrote:
>>>
>>>
>>>    What will happen if this guy creates a flightgear.flightprosim.com
>>>     page ?
>>>
>>>
>>> We could only hope ... !!!
>>>
>>> Can we get in trouble ourselves for using his name?
>>
>> Possibly - he claims it's a trademark.
>>
>> One from the screenshots page that contains yet more non-gpl content. If
>> he's including that scenery then that could be a problem.
>>
>> Jon
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
> 
> Kyle Keevill
> kyle...@gmail.com
>
>
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] scenery appearance depends on camera tilt angle

[David Megginson]

On Thu, Mar 11, 2010 at 4:47 PM, Heiko Schulz  wrote:

> Wel,, I would see this as a bug, if the frontside with the letter can't be 
> read then anymore. But your pics shows it can bes till, it is just the 
> backside which changes the color.
>
> Not a serious bug or showstopper for

FWIW, when I'm flying, I see the shading on the scenery change
drastically during the flight as the plane turns and pitches.  I think
what's happened is instead of just changing the shading on the panel,
we're changing the shading on the scenery too.  FGFS didn't used to do
that, so it's a relatively recent introduction.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aircraft modeling idea/request: Piper Super Cub

[David Megginson]

On Wed, Mar 3, 2010 at 3:22 PM, syd adams  wrote:

> I could probably get a decent yasim FDM built , but someone  else would have
> to do a JSB fdm , I still dont know what Im doing when it comes to jsbsim .

JSBSim works best when you already have aircraft data (derivatives,
etc.) and want to stick the numbers into a flight model, though you
can also start with an existing one and try to tweak it for a slightly
different aircraft.  YASim works best when you have only the
(easily-obtainable) performance numbers and want to work backwards
from them.  So unless you have PA-18 testing data, YASim is probably
the way to go anyway.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aircraft modeling idea/request: Piper Super Cub

[David Megginson]

On Tue, Mar 2, 2010 at 11:18 AM, Curtis Olson  wrote:

> From time to time people mention that our j3cub model in FlightGear is
> rather simplistic and dated by today's standards.  It was a nice model for
> the time when it was built, and it still flies great, but visually it hasn't
> been updated to match the level of detail and quality we have with many of
> the current FlightGear aircraft being developed.

Thanks for the kind words, Curt.  I put a lot of love into that model
in the early 2000s, but with the speed of average (not high-end) video
cards at the time, I had to keep the poly count very low.  It would be
great to see a more detailed J3 and Super Cub model.

BTW, is really is fun to fly a little tail dragger like the J3, and it
still does great wheel landings -- just make sure you're fast on the
rudder.


All the best,


David

> I recently discovered that I know someone who is pretty good friends with
> the owner of Cub Crafters in Yakima, WA.  Cub Crafters makes a modern kit
> and a production version of the classic Super Cub design.  They have a
> "Carbon Cub" which is much lighter and stronger than the original steel tube
> design.  They even have an over powered super cub variant than can top out
> at 180 mph +++ !  They are a cool company doing some really cool work.
>  Because of this personal connection with the owner of Cub Crafters, I think
> I could get some more detailed specs and dimensions if someone in our
> community was interested in building a modern "super cub" version of this
> classic design.
> Here is the Cub Crafter web site.  Find your way to their calendar pages
> too, they have some really great pictures on their web site.
>     http://cubcrafters.com/
>
> The Piper Cub is one of the best known and best loved aircraft ever built so
> it would be great to have a really nicely detailed version in FlightGear.
>  Aside from that, I have a personal selfish motivation.  Recently my friend
> and the ower of Cub Crafters got together, and because they both have
> engineering brains, they started brain storming several cool projects that
> they could combine forces on.  A couple of these ideas are actually pretty
> exciting and they are interested in seeing if they could pursue funding to
> develop one or more of them.  A nice 3d model of a Super Cub could be used
> to prototype and visualize these ideas and demonstrate them to potential
> funding organizations.
> So if anyone out there is interested in tackling a super cub project for
> FlightGear, let me know what kind of information you would need and I will
> do my best to secure it for you.  The super cub design has been around for a
> long time so there is probably a ton of information on the web as well.  It
> might even be possible to do some simple instrumentation of a real carbon
> cub to collect some actual flight test data (that would be a longer term
> project ... but the owner of Cub Crafters is friendly towards that sort of
> thing and I am currently developing some hardware and software that could be
> used for that purpose.)
> Best regards,
> Curt.
> --
> Curtis Olson: http://baron.flightgear.org/~curt/
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Citation Bravo ADF

[David Megginson]

On Mon, Mar 1, 2010 at 3:27 PM, syd adams  wrote:

> Ive switched back to the generic adf for the time being , I hadn't noticed
> the kr-87 problem before . I also tried settiing the adf-btn to true in the
> set file , but apparently that gets overridden .
> I guess a quick fix would be to set the button to true in the code  but
> I'd need to dig through my manuals again to remember what ANT mode does
> agian ... I think it focused  more on the signal , (but that's from memory ,
> could be wrong)...

ANT = antenna -- it disconnects the directional antenna and gives you
a plain AM radio signal.  It's officially used for hearing NDB station
idents more clearly, and unofficially used for listening to AM-radio
sports games during long flights.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Citation Bravo ADF

[David Megginson]

On Sun, Feb 28, 2010 at 5:15 PM, syd adams  wrote:

> Actually I think it might be a problem with kr-87.cxx , but I havent quite
> sorted that out yet ... as far as the ADF needle goes .
>
> Even with power , it doesnt appear to come alive until you toggle the ADF
> button on the radio .

If you put this in your .fgfsrc, the ADF is alive at the start:

--prop:/instrumentation/adf/adf-btn=true

The property seems a bit broken, though, because it's really a toggle
among ADF and ANT modes (and others?), so something like

--prop:/instrumentation/adf/mode=adf

would make much more sense.  I also notice that /radios or /avionics
(I don't remember which) got moved to /instrumentation.  Most pilots
would never refer to avionics as "instruments" or "instrumentation",
but I do understand how the lines are blurring with glass panels, etc.


All the best,


Davids

>
> I dont see the nasal errors your reporting .
> I'll keep digging .
>
>
>
> On Sat, Feb 27, 2010 at 2:22 PM, bitwPolly  wrote:
>>
>> This, as far as I can tell, is the cause of the problems with Bravo's ADF
>> needle:
>>   In Aircraft/Instruments-3d/primus-1000/P100.nas line 323: maghdg
>> -=getprop("environment/magnetic-variation-deg"); maghdg can return 'nil'
>> at startup so
>> the following addition fixes a thrown error: if (maghdg == nil ) maghdg=0;
>>  Also, a nasal error is reported at startup from the following line 363:
>> me.NavTime.setValue(ttg); where ttg has apparently been formatted some
>> lines earlier.
>> I'm not sure what problem nasal has with the resulting format but
>> commenting out line 363 stops that error being flagged.
>>  The result of either of the two errors is to stop the ADF/NAV needles
>> being updated, _only_ after the 'NAV' panel button has been clicked. ( On
>> startup the needles
>> work fine but freeze once that panel button is clicked).
>>   The nasal error messages would be a lot easier to spot if the console
>> messages relating to multiplayer status and more particularly so many AI
>> models being missing could be suppressed.  Thanks, (blucher)
>>
>>
>> --
>>
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Shaders experiments

[David Megginson]

Wow!


David

On Sun, Feb 28, 2010 at 5:41 PM, Frederic Bouvier  wrote:
> What do you think of this effect :
>
> http://www.youtube.com/watch?v=kUyH-4c0-qM
> http://www.youtube.com/watch?v=wYb1Vy-uTS0
>
> and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg
>
> Regards,
> -Fred
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Duplicate files in base package

[David Megginson]

On Sat, Feb 27, 2010 at 2:10 PM, syd adams  wrote:

> Its already pretty easy to point the  section to a different
> instrument , and the one Im currently working on , Im creating several panel
> files with different layouts that can be selected in the set file , but I'd
> hate to see instruments being changeable while in flight 

Making changes in an XML file is certainly simpler than writing C++
code -- that's why I wrote the XML property system -- but eventually,
we'll want to let less technical people make configuration changes as
well.  It's not a short-term goal, but something interesting to keep
in mind, all the same.


All the best,


David

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Duplicate files in base package

[David Megginson]

Something I'd love to see, in the long term, is a GUI that allows
users to customize their panels, just like real aircraft owners do. I
could decide to install a different brand of TC (the default late
1970s Cessna 172P now has a vintage 1950s needle and ball instead of a
TC -- cool, but what's up with that?), upgrade or downgrade the GPS,
swap out radios, etc.  That would be especially attractive for flight
schools and students, since they could match the panels of their
actual aircraft pretty closely.


All the best,


David

On Sat, Feb 27, 2010 at 8:53 AM, Torsten Dreyer  wrote:
>> A Sigma-Tek attitude gyro, for example, looks and works pretty-much
>> the same as a primary instrument for a Cessna 150 or as a backup
>> instrument on a 747 -- the differences (such as different voltage for
>> the backlighting) are pretty trivial.  I'd hate to see 100 copies of
>> the same Sigma-Tek attitude gyro in the base package.
> What we probably need for shared instruments is a well defined set of
> properties for each instrument. Currently most of our instruments animations
> are tied directly to the output properties of the signal source. In vor.xml
> the TO-flag is animated from /instrumentation/nav[0]/to-flag. It's only usable
> for nav1 and a second set of animation xml is needed for nav2.  What we need
> are unique properties for each instrument that are responsible for the
> animation of the instrument on on side and unique properties that reflect some
> state (like a TO-flag signal) on the other side. What's left for the A/C
> designer is the linkage between these two side.
> When you buy the Sigma-Tek attitude gyro at you local avionics dealer (the
> base package), you get your device with a well known interface connector and
> your avionics technician (A/C designer) needs to do the wiring.
> Almost everything needed for that "three-tier-design" is already in fg.
> Probably we need some kind of "relative mount point", so a single vor.xml can
> be loaded (mounted) into /instrumentation/vor-indicator[0] and
> /instrumentation/vor-indicator[1].
>
> Torsten
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Duplicate files in base package

[David Megginson]

On Fri, Feb 26, 2010 at 10:21 PM, Ron Jensen  wrote:

>> I still support the idea common  shared directories idea for such things as
>> instruments

> This is a nice, happy thought.  But in the real world it hasn't worked
> out so well.  Since we model such a huge variety of aircraft, and
> different FDMs and systems provide different outputs, our common
> instrument folders would need to be huge to cover all the different
> kinds of instruments, plus variations and modifications to fit each
> individual aircraft's structure.  It makes more sense to me to house
> each instrument with its aircraft.

In real life, very, very few instruments are customized for each plane
(the airspeed indicator, with its speed markings, is the obvious
example).  Most are manufactured by independent companies and are
TSO'd, so that they can be used in hundreds of different aircraft
models.  Ditto for most avionics, aside from some glass panels, etc.

A Sigma-Tek attitude gyro, for example, looks and works pretty-much
the same as a primary instrument for a Cessna 150 or as a backup
instrument on a 747 -- the differences (such as different voltage for
the backlighting) are pretty trivial.  I'd hate to see 100 copies of
the same Sigma-Tek attitude gyro in the base package.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] 3-Dimensional forests.

[David Megginson]

On 19/12/2007, gerard robin <[EMAIL PROTECTED]> wrote:

> On mer 19 décembre 2007, Pavel T wrote:
> > Hello Flightgear Developer(s),
> > I was thinking of this idea and I thought you might like it.
> > You might have guessed already by the subject of the e-mail. I was thinking
> > of maybe someone could make different versions of trees and make someking
> > of a tool that puts a number a number of trees in a a space automatically.
> >
> > Looking forward to your reply!
> > Pavel.
>
> Isn't it the case  with FG now ?

The last I checked, it worked with the plib version, but not with the
OSG version.


All the best,


David
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: Control surface position damping

[David Megginson]

On 02/12/2007, Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote:

> I mentioned the "5" key only as an example. I am not proposing to put a filter
> on that command.

In general, then, as others have mentioned, this belongs in the flight
models rather than the input layer.  The input layer *requests* a
position -- it's up to the flight model to decide if or how fast to
provide it.  Putting the joystick to full right ailerons is just
asking "full right ailerons, please".  I do like the idea of a filter
on '5', though.


All the best,


David

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: Control surface position damping

[David Megginson]

On 02/12/2007, John Denker <[EMAIL PROTECTED]> wrote:

> In real life, in a small airplane, if I decide to stomp on the
> rudder pedal, the rudder is going to move real fast.  The
> realistic time scale is not long compared to 1/30th of a
> second i.e. the inverse frame rate.  That is to say, any
> filter with a realistic timescale wouldn't solve the
> problem.

That's true for control surface movement in general, but I had
(mis)understood that Roy was proposing this specifically for the '5'
key -- that's a simulator-specific key that has no real-life
equivalent, so binding it to a new command that has a low-pass filter
would probably be a good idea.  We don't have to worry about realism
for this key, just controllability.


All the best,


David

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: Control surface position damping

[David Megginson]

On 02/12/2007, Roy Vegard Ovesen <[EMAIL PROTECTED]> wrote:

> I think moving a control surface, like for example the rudder, from full left
> deflection to rull right deflection in an instant is unrealistic. To make
> this more realistic I think we should put in a low pass filter somewhere in
> the chain from crontrol device to FDM. My first thought would be to do the
> filtering just befir handing the value over to the FDM.
>
> Does anyone on the list have comments on this?

Besides "d'oh, I wish I'd thought of it five years ago!"?


All the best,


David

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Microsoft ESP

[David Megginson]

On 28/11/2007, Stuart Buchanan <[EMAIL PROTECTED]> wrote:

> Given this, we don't need to worry any more about MS patents than we did
> before the announcement, i.e. hardly at all. All the I/O stuff they've 
> announced
> is already present in FG.

Software patents have no force in Canada in any case, and I think the
same applies to most of the rest of the world -- they're a
U.S.-specific mistake that a couple of other countries have been
strong-armed into following.


All the best,


David

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] English as a low common demoninator

[David Megginson]

The Economist once had an article suggesting (I'm not sure how
seriously) that languages like German or Japanese could be a
competitive advantage precisely because they're not widely spoken.  In
an international business meeting, English speakers have no language
to switch to for a private discussion that the other side can't
understand. (Of course, nowadays, you could just discretely record the
conversation on your cell and have it translated when you get home, if
it's not too late.)

Bis später and さよなら。


David

On 21/11/2007, Mike Schuh <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Nov 2007, Jon Stockill wrote:
>
> >Melchior FRANZ wrote:
> >
> >> We all hate English, but it's the lowest common
> >> denominator.  ;-)
> >
> >Oi! The's now't wrong wi english, even if nob'dy ahtside yorkshire can
> >talk reet.
>
> As the saying goes:  If you can speak three languages, you are trilingual,
> if you can speak two languages, you are bilingual, if you can speak just
> one language, you are an American...  (I'm not sure what I am then, as I
> speak understandable Norwegian and can usually convey what I want to say in
> German)
>
> On a more relevant point, I am willing to assist in writing documentation
> or (more likely to actually happen) proof read what others have written.
>
> I hope to engage myself in code development "soon"...
>
> --
> Mike Schuh - Seattle, Washington USA
> http://www.farmdale.com
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Keyboard reorg

[David Megginson]

On 14/11/2007, Melchior FRANZ <[EMAIL PROTECTED]> wrote:

> * David Megginson -- Wednesday 14 November 2007:
> > I think you've just made FlightGear into Emacs.
>
> I detest emacs. The script is inspired by vi!  :-P

Now you're making me nervous.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Keyboard reorg

[David Megginson]

On 14/11/2007, Melchior FRANZ <[EMAIL PROTECTED]> wrote:

> Here's a more sophisticated and useful toy:
>
>   http://members.aon.at/mfranz/keyboard.nas  [5.0 kB]
>
> It is started with the '/'-key and then waits for the input of a
> property path, optionally followed by "=" or "?":

Gott im Himmel!  I think you've just made FlightGear into Emacs.

(Actually, that might not be so bad ...)


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Minor keyboard reassignment

[David Megginson]

On 09/11/2007, David Megginson <[EMAIL PROTECTED]> wrote:

> ... f there are general objections (from DC-3 users?) I can
> swap the two around so that tailwheel lock goes back to 'l'.
>
> Let me know what you think.

There doesn't seem to be a consensus around the change, so I've
reverted keyboard.xml to its previous version, at least until we
finish our discussion about the keyboard reorg.  The function to
toggle aircraft lighting is not currently bound, and the 'l' key
reverts to its previous function to lock the tailwheel (unless
overridden by an aircraft config file).


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)

[David Megginson]

On 12/11/2007, gerard robin <[EMAIL PROTECTED]> wrote:

> probably i misunderstood the rule, didn't you modify cvs before getting
> decision  about *what* functions need keybindings.

I promised to put it back if there were objections -- there were, and
I plan to put it back, but I can't connect to the CVS right now (time
out).  My suggestion about discussing keybindings was also a response
to those objections (we used to just check in changes and revert them
if people didn't like them, but I can see that the project culture has
changed a bit).

Given the (apparent) anger and sarcasm, I'm guessing you've had a very
bad experience on some other open source project.  I'm sorry that's
happened (I've worked on projects like that too), but please try to
approach FlightGear with an open mind and not start by assuming the
worst of everyone -- unless it's changed a lot in the couple of years
that I was away, it's a group of very nice and talented people, and I
hope they've made you feel welcome.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)

[David Megginson]

On 12/11/2007, gerard robin <[EMAIL PROTECTED]> wrote:

> Do you mean wait and see  ?

No, just that it makes sense to decide *what* functions need
keybindings before we decide *where* to bind them.  Have you had a
chance to edit the wiki page yet?


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)

[David Megginson]

On 12/11/2007, gerard robin <[EMAIL PROTECTED]> wrote:

> Wouldn't it be better to say first which mains features will not have an
> official KEY dedicated ?

I think it's shorter to decide which ones *will* have an official key
dedicated -- that's what the list is for.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)

[David Megginson]

Thanks to everyone for the suggestions so far.  Just to get back on
track, we have to start by seeing if we can come up with a short,
priority list of stuff that's (a) applicable to most aircraft, and (b)
important enough to have a key assignment.  We can decide exactly what
those key assignments will be (and what language[s] we'll use) after

I've started my own list here:

http://wiki.flightgear.org/flightgear_wiki/index.php?title=Keyboard_function_priority_list

Please go to the page and edit it with your own suggestions.
Collectively, I think we can come up with a priority list that's at
least 80% good enough, though obviously we'll never hit 100%.


All the best,


David
.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Keyboard reorg

[David Megginson]

This is a good discussion that we've started.  Way back when, we
didn't have menus (or scripting), so every function had to be
accessible from the keyboard (and all the assignments were hard-coded
in C++ to boot).

I think that we need to take a few steps:

1. Come up with a prioritized list of functions that should have
global keyboard assignments (e.g. switch view, lower flaps, raise
gear, etc.).

2. Decide on a block of keys to be set aside for per-aircraft key assignment.

3. Agree on a useful set of core bindings for the remainder, which no
model should touch.  This will be not be easy, but it will be very
beneficial.  There should be some logic to it, e.g. function keys used
for one kind of thing, alphabetic for another, etc.  As people have
noted, a lot of stuff currently assigned to keys should move to menus
and dialogs.

4. Provide a GUI for a user to change keyboard assignments while the
sim is running and to save the changes.  The user's local changes
should override everything else, including per-model assignments. (If
we're really sophisticated, we could let the user make his/her own
per-model assignments.)

Anyone game to start?  Does someone already have a first draft of a
prioritized function list?


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Minor keyboard reassignment

[David Megginson]

On 10/11/2007, dave perry <[EMAIL PROTECTED]> wrote:

> I just looked at the changes in cvs.  There is a significant problem
> with at least this implementation of one "key" to turn on all the lights
> for all AC.  There is no standard followed for how to implement nasal
> electrical systems.  The patches you made to cvs will accomplish your
> stated goal for the pa24 and pa28, but not for the SenecaII or the
> dhc2.  This is because when I wrote electrical.nas for the pa28, I
> started from the eleictrical.nas for the pa24.  Some of the nasal
> electrical systems bypass switches all together and toggle properties
> such as /electrical/landinglights.  Others include functional circuit
> breakers that would need to be verified.

This sounds like a pretty big problem beyond just my patch.  Nasal has
been great for letting people add functionality to FlightGear, but it
causes a lot of problems for the property system, especially when
people use different property names, override stuff, etc.  It might be
time for a refactoring pass through some of the models.

> A second observation is that I virtually never turn on the white cabin
> light or the map light because I don't want to ruin my night vision.  So
> even for the pa24, I would not want to have all the light on for most
> flights.

I know -- I don't turn them on either -- but I put them in just for
completeness for now.  I have no problem pulling them out, once we
agree on a common subset (and fix some of the property
inconsistencies).


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml, 1.99, 1.100

[David Megginson]

On 10/11/2007, gerard robin <[EMAIL PROTECTED]> wrote:

> I can notice the update has been done , before we could give any opinion on
> the topic.
> Does it mean , that there is not any other alternative, and the CHOICE is that
> way nothing else  :) :) :)

>From my original message:


I just moved tailwheel-lock from lowercase 'l' to uppercase 'L', and
reassigned lowercase 'l' to toggle lighting (for easy night starts
without searching for switches).  I assigned lighting to the lowercase
'l' because I think it would be much more commonly used than tailwheel
lock, but if there are general objections (from DC-3 users?) I can
swap the two around so that tailwheel lock goes back to 'l'.

Let me know what you think.


I or anyone else with access can change it again once there's a
consensus -- remember that CVS is the experimentation branch, not the
release branch.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Minor keyboard reassignment

[David Megginson]

On 10/11/2007, gerard robin <[EMAIL PROTECTED]> wrote:

> A stupid question:
>
> Why is it necessary to have a key for lights, isn't it a cockpit feature with
> hotspot, and switch ?

Switches are hard to find, especially (a) if you're not a real pilot,
or (b) if you're not familiar with the aircraft.  A single key to turn
on all the lights can be very useful for a new user, or even for an
experienced user who just wants to fly at night and doesn't know the
aircraft or doesn't want to pan around the panel.

As you all know, I'm a big fan of realism, but it's important to
understand that people want to simulate different things in
FlightGear.  Some people like to practice playing with the panel and
throwing switches, but lots of other people want to practice just
flying -- by the same token, not everyone would want to have to
simulate ski-waxing in a cross-country ski sim, or rifle cleaning in a
hunting sim, before they could actually ski or shoot.

If I were learning a new aircraft, I would be very grateful for the
level of fidelity in some of the aircraft panels, since it would let
me practice at home.  However, most of the time, I just want to fly --
I spend enough time in real life covering, uncovering, inspecting,
cleaning, fueling, oiling, starting up, and shutting down my plane,
and most of the time I don't really want to have to go through all
that hassle again in FlightGear.

So, in summary, I think a single switch to turn on all required
interior and exterior lights for night flying can be a big win for
FlightGear.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Minor keyboard reassignment

[David Megginson]

I just moved tailwheel-lock from lowercase 'l' to uppercase 'L', and
reassigned lowercase 'l' to toggle lighting (for easy night starts
without searching for switches).  I assigned lighting to the lowercase
'l' because I think it would be much more commonly used than tailwheel
lock, but if there are general objections (from DC-3 users?) I can
swap the two around so that tailwheel lock goes back to 'l'.

Let me know what you think.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fresh build problem

[David Megginson]

On 15/04/2006, Ron Jensen <[EMAIL PROTECTED]> wrote:

> You do have libopenal-dev installed as well as  libopenal?  It should
> work.  I got it to compile under sarge two weeks ago...

libalut-dev has just been spun off into a separate package, at least
in Ubuntu, so you have to install it as well.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[David Megginson]

On 03/11/2007, Vivian Meazza <[EMAIL PROTECTED]> wrote:

> As I said before, but perhaps you didn't notice, we already have a force
> based system working on the input of pilot g. It moves the pilot's eye
> position according to this input. And as Melchior pointed out, we probably
> need to stabilise the point at which the pilot looks to make this totally
> realistic.

Is there a way to enable it in general, without tying to a specific
aircraft model?


Thanks,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[David Megginson]

On 03/11/2007, Melchior FRANZ <[EMAIL PROTECTED]> wrote:

> I should do something similar for planes. Of course, this is
> still configurable per aircraft, too. Just not via properties,
> but by defining a Nasal handler. I'll review that.
>
> And again: I appreciate suggestions for improvements or patches.
> Just not commits to that nasal file. You don't know how picky
> I am!  ;-)

Now that I understand what it's for (and the fact that it's not
enabled by default), I don't plan to touch it -- and as I mentioned,
it is a cool idea.  I would like to get some kind of force-based head
lag working, through.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[David Megginson]

On 03/11/2007, Melchior FRANZ <[EMAIL PROTECTED]> wrote:

> * David Megginson -- Saturday 03 November 2007:
> > I wasn't looking at any NASAL code.  Is the NASAL code enabled
> > by default?
>
> While you were away, we got support for automatically saving GUI
> settings to an ~/.fgfs/autosave.xml file, and you might have
> enabled dynamic view at some fgfs run, and now you get it until
> you turn it off again. You wouldn't be the first to interpret
> that as an unwelcome default setting.  :-)

That was it.  I was also mislead by seeing

  true

In $FG_ROOT/preferences.xml, without noticing


  false


just below it.  I have no problem with having it as a feature -- it's
a neat and original idea -- but it might be worth reconsidering the
up/down movement.  While pulling back on the yoke/stick may make a jet
fighter shoot upwards, with a regular plane it's just as likely
intended to slow the plane down.  One of the first points made in the
classic book "Stick and Rudder" (worth reading for any real or sim
pilot) is that the yoke/stick is *not* an up/down control.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[David Megginson]

On 03/11/2007, Vivian Meazza <[EMAIL PROTECTED]> wrote:
> As Melchior said, the head-shake mechanism does indeed regard the head as a
> mass and a (damped) spring, but it's a bit more sophisticated than that -
> the resistance of the neck muscles are modelled as well.

Which is enabled by default -- head-shake or dynamic views -- and how
do we change the default?


Thanks,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[David Megginson]

On 03/11/2007, Syd&Sandy <[EMAIL PROTECTED]> wrote:

> Looking at videos taken by passengers , you can certainly see these forces 
> ... and as a passenger , I have definately sunk in my seat  ( no head 
> springs involved ), so I still use it myself ...

Yes, that's much more realistic, and in fact, it's something we study
during flight training -- in a coordinated 60-degree steep, level
turn, you pull 2Gs and will feel yourself press very heavily down into
your seat (though it's unlikely that you sink more than 1-2 cm).
Note, however, that there's *no* sideways force at all if the turn is
coordinated -- it's all straight down (plane referenced).  If you put
a spirit level on the top of the panel in a coordinated turn, the
bubble would stay exactly centred.

When I descend quickly, say, approaching a runway for landing when I
had to clear some trees, I'll feel the opposite effect -- my head will
move up maybe .5 cm, and my shoulder will press hard against the
shoulder strap for a sec, then I return to normal Gs.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[David Megginson]

On 03/11/2007, Melchior FRANZ <[EMAIL PROTECTED]> wrote:

> Not sure if you are talking about "dynamic view", but this *isn't*
> supposed to change the view based on physical forces. The first
> three lines in $FG_ROOT/Nasal/dynamic_view.nas are:
>
>   # Dynamic Cockpit View manager. Tries to simulate the pilot's most likely
>   # deliberate view direction. Doesn't consider forced view changes due to
>   # acceleration.

I had been looking at dampEyeData in src/Main/viewer.cxx, assuming
that was causing the problem.  I wasn't looking at any NASAL code.  Is
the NASAL code enabled by default?

> And that's how I wanted it to be. I'm not a RL pilot, but I
> consider it quite unlikely that a pilot flies a left turn and
> doesn't look left, or strongly pitches up and doesn't look
> up. Usually we want to know in which objects we are about to
> crash.  :-)

I can't speak for every pilot, but that doesn't jibe at all with my
real-life experience.  I hadn't noticed the problem so much in VFR
flights, but flying FlightGear for an IFR approach, I actually lost
control of the Warrior twice before I figured out what was going on.

When you're flying IFR in actual IMC, you try to keep your head as
still as possible no matter which way you move the controls.  Even
flying VFR in good day VMC, it's common (for me, at least) to look
*before* I start a maneuver then return my head to the
straight-forward position while I actually fly it, so that I can use
outside references properly.

Finally, the position you move the controls isn't necessarily the
direction the plane will move.  For example, on approach you'll be
pitching the nose up but the plane's moving down.

Forces give a more realistic head movement, I think, because the head
moves only if something unusual is happening, like an uncoordinated
turn or high/low G forces.  It's OK to disrupt the pilot in that case.

> There are some implementations of forced head changes used in
> various aircraft ("head shaking"), but those are IMHO too
> unrealistic, as they treat the head only as a mass on a spring,
> and completely disregard the physiology of the
> eye/equilibrium organ/brain system. If we could agree on one
> that *feels* realistic, then I would be willing to integrate
> it in dynamic view. But so far we didn't.

A spring's not quite right.  I think any movement should be very
slight (max 2 cm), and could track the forces on the pilot (maybe
using a squared function so that minor forces have virtually no effect
and major forces are obvious).  The head should be perfectly centred
when the pilot feels 1G in the (plane-referenced) vertical axis and 0G
in the forward and side axes.  No matter what, though, the head should
not swivel unless the user decides to swivel it.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Fixing head lag

[David Megginson]

I think it's great that FlightGear added head lag to the sim -- it's a
good alternative when the pilot can't feel forces -- but I think we'd
do better to model it based on perceived forces, not on roll/yaw/pitch
damping. For example, simply entering a coordinated bank gently
shouldn't cause any head movement at all, but flying straight in a
forward slip should, because there's a yaw force pulling the head
slightly sideways.  Likewise, while the pilot is perceiving < 1G the
head should move up a bit, and while the pilot is perceiving > 1G, the
head should move down a bit.

Would anyone object to my checking in some changes over the next week
or two to change this?  We can always roll them back if they don't
work.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Demeter (was Re: FlightGear terrain engine)

[David Megginson]

On 01/11/2007, Sergey <[EMAIL PROTECTED]> wrote:

> as FlightGear moves to osg there is a nice virtual terrain project which is
> integrates with osg.
> The site for the project is http://www.vterrain.org/ and some papers are
> here http://www.vterrain.org/LOD/Papers/.

Excellent.  It looks like a good start, but there is a strange culture
around the site -- for example, you have to request a download instead
of simply downloading the source, even though it seems to have a
BSD-style license.  I wonder if most of the developers are coming from
the Windows world, and don't quite get the norms of open source yet.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Demeter (was Re: FlightGear terrain engine)

[David Megginson]

On 01/11/2007, Tim Moore <[EMAIL PROTECTED]> wrote:

> > ...  we should concentrate on aircraft models
> > and flight dynamics, and try to interface with an existing engine.

> That depends on where your interests lie, I suppose.

By "we", I meant the Flightgear project, not the individuals in it.  I
would also be very interested in contributing to a terrain engine, but
I think it probably would need its own maintainer and team of core
developers who were focusing primarily on it, rather than building it
as a sideshow to FlightGear, especially since it would have to come
with a suite of editing tools to help people manipulate GIS data and
manually tweak scenery.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Demeter (was Re: FlightGear terrain engine)

[David Megginson]

On 31/10/2007, Christian Buchner <[EMAIL PROTECTED]> wrote:

> I would like to get a few pointers where to look for information about the
> terrain engine that is currently used by
> Flight Gear. In particular about the irregular terrain mesh - how is it
> created (at runtime or offline) and how does
> photo texture currently get mapped onto terrain - how are roads and other
> terrain features added? (is it all
> vector or is it texture maps)

Our current terrain engine was great in the late 1990s (when MSFS
still had a flat world), but it's pretty stale now, mainly from a lack
of interest and the difficulty of understanding the code.  It's
actually deteriorated in some ways -- note that all the Great Lakes
have been forced to sea level now, so that Lakes Huron, Michigan, and
Superior are in deep gorges, and all the cities beside them are
perched on cliff faces (that wasn't happening a couple of years ago).
I'm not sure that we should really be maintaining our own terrain
engine any more, though -- we should concentrate on aircraft models
and flight dynamics, and try to interface with an existing engine.

One promising prospect is Demeter, which works with OpenSceneGraph
(already supported by FGFS):

http://www.tbgsoftware.com/index.html

Unfortunately, Demeter itself seems to have gone a bit stale -- some
of the links from the site don't work any more, and it won't compile
with the latest version of OSG.  It does, however, support LOD and
lots of other nice stuff (check out the screen shots!).  Maybe someone
should take it over if the maintainer has abandoned it, or fork it if
the maintainer hasn't but is stalling on new releases.

The best thing we could do in FGFS, in the meantime, would be to
isolate scenery-engine dependencies so that it's easy to switch to a
new engine when it's ready.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] J3 Cub rerigged (was Re: J3 Cub Back Seat Driver)

[David Megginson]

On 25/10/2007, Hans Fugal <[EMAIL PROTECTED]> wrote:

> > You can adjust it in flight if you bind some keys to the trim
> > properties, but it would be pretty unrealistic -- I doubt that any J3
> > Cub has ever had rudder or aileron trim.
>
> Or have a joystick.

Actually, the J3 does use a stick instead of a yoke -- you can see it
in the 3D model (it's mounted on the floor, between where your feet
would be).


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] J3 Cub rerigged (was Re: J3 Cub Back Seat Driver)

[David Megginson]

On 25/10/2007, Hans Fugal <[EMAIL PROTECTED]> wrote:

> Thanks! You mention the nonadjustable rudder and aileron trim - is
> that nonadjustable in theory only or does flightgear also enforce
> this? If not, can it be made to? It wasn't clear from the j3cub.xml
> file.

You can adjust it in flight if you bind some keys to the trim
properties, but it would be pretty unrealistic -- I doubt that any J3
Cub has ever had rudder or aileron trim.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] J3 Cub rerigged (was Re: J3 Cub Back Seat Driver)

[David Megginson]

Since I came back to FlightGear a few weeks ago, I've flown the J3 Cub
mainly with the mouse (for short breaks from work), so I hadn't
noticed how badly out of trim the plane has been flying.  I've just
checked in changes to fix the (non-adjustable) rudder and aileron trim
to get rid of the strong roll+skid tendency in level cruise.  Note
that the plane will still pull to the left at a high angle of attack
(e.g. takeoff or steep climb), as it should.

For those of you who like this model, it should be a bit less annoying
to fly with a joystick or yoke now.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] J3 Cub Back Seat Driver

[David Megginson]

On 25/10/2007, Hans Fugal <[EMAIL PROTECTED]> wrote:

> I wonder if it is really that hard to see the compass in the real
> plane. Maybe so, but combined with the small size and the various
> reasons why it's hard to make out the magnetic compass in FG even at
> regular size I have to think maybe it's extra-difficult.

I can make it out at 1280x800, but I agree that it is hard to read.

Then again, in real life, I can barely read the mag compass in my
Warrior sitting in the front seat -- it's a tiny, dim sort of thing.
Generally, I lean over and stick my face right in front of it when I
need to calibrate my heading indicator.

For flying a Cub, you shouldn't look at the compass very often -- it's
a look-out-the-window plane, not a look-at-the-panel plane.  Use 'x'
to zoom in on the compass to check your heading once in a while
(ctrl-X will snap back to regular zoom), then pick a point outside the
window as your heading reference and look at it instead of the
compass.  That's probably the best equivalent of the Cub pilot leaning
forward to take a glance.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] J3 Cub Back Seat Driver

[David Megginson]

On 25/10/2007, Hans Fugal <[EMAIL PROTECTED]> wrote:

> Would it be possible to change the default position for the j3cub to
> sitting in the front seat instead of the back seat? That would make
> the instruments (especially the compass) actually readable. Maybe have
> a second -set file for back seat drivers?

The thing is, you do fly the J3 cub solo from the back seat for
weight-and-balance reasons, so it definitely should be the default.
Apparently, it really is that hard to see the instruments in a Cub,
but fortunately, you don't use them much in a plane like that.  You
can move the pilot view position forward if you want using the mouse
(that applies to any plane) -- go into mouse view mode, and hold down
the middle mouse button and CTRL on the keyboard, then slide the mouse
forward.

Note that Microsoft Flight Simulator X, which now also comes with a J3
Cub (I think we were first), starts you in the back seat as well.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Hangar start

[David Megginson]

On 12/10/2007, AnMaster <[EMAIL PROTECTED]> wrote:

> Maybe add tow truck to flightgear? I wouldn't want to pull an English 
> Electric Lightning for example
> (would it even be possible?)

It's fun to see the variety of tow vehicles at airports.  For
airliners, of course, there are the white tugs that we all recognize,
but for smaller planes, I've seen old pickup trucks, converted riding
mowers, and even a little dune buggy -- the only thing they have in
common is that they're usually even noisier and harder to start than
the airplanes.  Some pilots also use powered towbars for smaller
aircraft.

Basically, anything up to the size of a Navajo or Cessna Caravan can
(and will) get pushed around by hand, and it's a sort-of unwritten
rule that you run over to help whenever you see someone starting to
move a plane around; in fact, I do know a commercial Navajo pilot who
can push her plane back into a spot with no assistance, though I
sometimes have trouble even with my Warrior when the tires are soft
and there's snow on the ground.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Consistent aircraft states

[David Megginson]

On 12/10/2007, gerard robin <[EMAIL PROTECTED]> wrote:

> Only one generic property switch is necessary.
> We must only,   all together decide which name and where  (/sim/ ??)

[snip]

> For instance looking at one of my model
>
> to have the right flying conditions, i need:
>
> Canopy => Down
> Wing-folds => Off
> Wing-incidence =>  Down
> Electric-power => On
> Cut-off => Off
> Engine=> running
> Throttle => 0.6
> Landing-gear   =>  Up
>
>
> All these  could be switched according to that Cold/Hot 

The sim can also decide where/how to place the aircraft (if not
otherwise specified) based on the value.  For example, by default, we
could place the aircraft 1,000 ft above the airport at cruise speed if
the value were "in-air", on the runway threshold (as now) if the value
were "idling", and on the apron (assuming we have coordinates) if the
value were "parked".


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Consistent aircraft states

[David Megginson]

On 12/10/2007, drew <[EMAIL PROTECTED]> wrote:

> I have my .fgfsrc file set up so I start on the run-up area just off the main
> runway at KSFO:
>
> --lat=37.612451
> --lon=-122.357858
> --heading=026
>
> so I have the time to do pre-flight checks (and explore the cockpit and
> README's of new and unfamiliar a/c) without clogging up the threshold.

If you want to be even more realistic, you can start on the GA apron
off taxiway C north of firehall #2.  From the following diagram, it
looks like longitude 122 23.0 W (-122.38) and latitude 37 37.7 N
(37.638333) should do the trick, with a heading of around 150 deg T so
that you're parked sideways to the FBO:

http://flightaware.com/resources/airport/SFO/APD/AIRPORT+DIAGRAM/pdf

You can read about the actual Signature FBO here:

http://www.airnav.com/airport/KSFO/SIGNATURE


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Consistent aircraft states

[David Megginson]

On 12/10/2007, Vivian Meazza <[EMAIL PROTECTED]> wrote:

> You can have your aircraft any way you want, but don't force it on other
> designers without some real thought. Start the Spitfire and forget to zero
> the throttle, you will start on your nose. That doesn't give a good
> impression to newcomers.

I'm actually suggesting the opposite -- instead of having each
designer decide, let the users start the aircraft any way *they* want.
 I think the default should be with the engine on and idling, but
that's a separate discussion.  The first step is to agree on a global
property and start modifying aircraft configs to honour it; then we
can debate what the default value of that property should be.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Consistent aircraft states

[David Megginson]

On 12/10/2007, dave perry <[EMAIL PROTECTED]> wrote:

> Welcome back.  I am the one that made all the changes to the Warrior.
> Starting directions and keyboard switch equivalents are under the help
> menu-Aircraft help, just like with the pa24-250.  It was after you had
> commented on how you liked what I had done on the pa24 that you sent me
> your pictures and asked if I wanted to continue developing the Warrior,
> so I used the pa24 nasal work as a starting point for implementing the
> Warrior electrical system and switches.

You did a great job on it -- I'm very impressed.

> I still consider the Warrior your aircraft and had communicated to you
> off list in mid August that I had made updates and changes.  I asked for
> feedback in that note.  I assume that you did not disable or bypass the
> nasal implemented switches with the above change.

No, but I did migrate some of the property settings out of the Nasal
script and into the XML settings file.

> I am clearly one that prefers to  start with the brakes set and all
> switches off as that is the way every real flight  starts.

(An aside: In my experience, it's rare that the parking brake is on
when a real light plane is parked, because line staff wouldn't be able
to move it around without gaining inside access -- in fact, when I get
out of the plane at a remote airport, the first question from line
staff is usually not "do you need fuel?" but "is the brake off?".
Normally, a plane on an apron is chocked, while a plane in longer-term
parking is tied down.)

> But I also
> see the advantage of having an easy  option to start in the air with
> switches and fuel valve set for an approach.  Perhaps with a little more
> effort, there is a way to accomplish both.

Here are a few usability guidelines that might help:

1. Consistency - all aircraft should start in same default state as
far as possible (obviously, a glider doesn't have an engine), so that
a user isn't surprised when switching aircraft types.

2. Configurability - it should be not only possible but very easy for
a user to override the default state without editing XML or Nasal
files.

3. Simplicity - the default state should be the easiest one for new
users.  Experienced users  will have an easier time changing the
default.

I suggest that we introduce a new global property, such as
/sim/start-state, which can be set to (say) "parked", "in-air", or
"idling".  The configuration files for every aircraft could respect
that property, so that if you set it to "parked", *every* aircraft
(even the default 172) would start parked, etc. (we could even put it
on the apron instead of the runway if we add parking coordinates to
the airports file).

I think "idling" should be the default the first time someone runs
FlightGear, since it's standard with all flight sims and by far the
easiest for new users, but one menu selection should be able to switch
to "parked" for people (like you) who prefer to go through the startup
and taxiing routine every time.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Hangar start

[David Megginson]

On 12/10/2007, AnMaster <[EMAIL PROTECTED]> wrote:

> I prefer starting with engine off (and not at threshold) so why not add 
> support for starting
> somewhere else than end of runway? Starting at the gate for example (makes 
> sense for 787 but not for
> the warrior) or in a hangar (if such exist at that airport).

You probably wouldn't want to start in a hangar unless you wanted to
animate a little pilot with a sore back pulling the plane out onto the
apron -- it's extremely rare to start the prop when the plane is
indoors.  In front of a hangar might make sense, but with the nose
angled away so that the prop blast doesn't blow back into the hangar.

Seriously, I think we should make it easy to start the way you want,
but there's a lot of work involved.  The original aircraft config
system was designed to make it easy for users to override default
settings at runtime, but I notice now that lots of people use Nasal
scripts (etc.) to forcibly override default properties, so you're
pretty-much stuck with whatever the designer decided until we have
time to clean up all the config files.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Warrior changes

[David Megginson]

On 11/10/2007, Hans Fugal <[EMAIL PROTECTED]> wrote:

> This isn't the only plane that starts in cold configuration. I think
> it would be best to be consistent - either leave it up to the plane
> designer in every case (I believe in this case at least it was a
> conscious decision on the part of the designer), or decide on a policy
> that every aircraft should start hot and try to make that consistent
> throughout.

I was the aircraft designer, though others have done a lot of
excellent work on the Warrior since.

One problem with starting in cold configuration by default is that
in-air starts won't work.  For example, if you use FlightGear to
practice IFR approaches (like I do), you want to start in the air
about 10 miles from the runway, not in the tie-down area. There was no
way to do that using command-line options with the previous version of
the config files.

I recommend that we start all aircraft running and ready to roll, but
provide an easy way for advanced users to start cold if they want to.
I know that aircraft designers work hard on the switches and systems
and want to show them off, but forcing people to use them every time
might not be the best choice, especially for new users (and when the
default start is on a runway threshold, where the engine should be
running).


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Warrior changes

[David Megginson]

As I mentioned earlier, the Warrior model is looking great.  However,
because it was starting with the engine and fuel off and the brakes
on, it took a while to get started (and wasn't realistic sitting on
the threshold with the engine off), and I don't think it was possible
to do an in-air start, e.g.

  fgfs --aircraft=pa28-161 --altitude=5000 --vc=100

There were some places that the Nasal scripts were overriding startup
preferences.  I started cleaning those up and made a few more changes,
so that the Warrior now starts up just like the Cessna 172 or J3 Cub,
ready to take off.  Please let me know if you find any problems.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] autopilots, adverse aileron yaw and jsbsim questions

[David Megginson]

On 08/10/2007, Jon S. Berndt <[EMAIL PROTECTED]> wrote:

> There are two gains that come into play. One is from FlightGear (0.0 to 1.0,
> as Dave M. pointed out), and the one eventually sent to JSBSim, which is in
> ft/sec. It looks like the one set in JSBSim can vary from 0.0 to 100.0
> ft/sec. That is the maximum value expected. That seems high to me.

The maximum value should be high enough to destroy an airframe.  It
would be worth investigating research into cumulonimbus clouds,
downbursts, etc., but I don't think 100 ft/sec is out of line.  Unless
you want to make the 0-1 turbulence value non-linear, anything about
about .1 should be very unpleasant to fly in.

I did stumble into a small, developing storm cloud once in my Warrior.
 Fortunately, the up- and downdrafts had smooth enough transitions not
to cause damage, but they pegged my VSI in both directions, threw me
back and forth into uncommanded 60-degree banks, and we gained and
lost a couple of thousand feet in  seconds.  It's almost impossible to
believe the power stored in even a small storm cloud until you've seen
it.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] autopilots, adverse aileron yaw and jsbsim questions

[David Megginson]

On 08/10/2007, Jon S. Berndt <[EMAIL PROTECTED]> wrote:

> Does anyone know what typical values are for these two properties:
>
> /environment/turbulence/magnitude-norm
> /environment/turbulence/rate-hz
>
> The fact that the first property is named magnitude-norm (emphasis on the
> *norm*) makes me suspect that the turbulence goes from _1 to +1. But, that
> wouldn't do much for turbulence. And, is that 1 ft/sec? Or is it the value
> of the turbulence in ft/sec?

I helped implement this with Tony a few years ago.  As I recall, the
value was from 0 to 1, where 0 represents no turbulence, and 1
represents the most severe turbulence that we model.  You couldn't
represent turbulence simply in feet/second, because it consists of
both movements and rotations.

Note also that the current system has problems for multiplayer mode.
For example, if the turbulence were set to .5 (which should be pretty
bad), a J3-cub and a Boeing 747 flying into the same airport will
experience the same turbulence, while in reality turbulence that would
tear a wing off a J3 cub might not do much more than jiggle the drinks
in the 747.  As soon as you consider a world with more than one plane
flying at once, we have to think about modelling the turbulence not by
its effects on the plane, but by its source air motion.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] autopilots, adverse aileron yaw and jsbsim questions

[David Megginson]

On 07/10/2007, Jon S. Berndt <[EMAIL PROTECTED]> wrote:

> I looked at the configuration file for the Seneca II in flightgear cvs. It
> appears to me (at least given the quick glance I took) that adverse aileron
> yaw (Cnda) is turned off - the data is all zeros.

I'm not sure about the exact derivatives, but the real PA-28 and the
172 experience negligible adverse yaw in level cruise at bank angles
under 20-30 degrees -- you can fly them with your feet flat on the
floor and the slip-skid ball barely moves.  In both, I think, it's the
use of differential aileron deflections that does the trick.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Modeling VOR/DME stations

[David Megginson]

On 05/10/2007, Bohnert Paul <[EMAIL PROTECTED]> wrote:

> Doe any body have a picture of the VOR at KSFO?  I have not been able to
> find one.

Here it is from the top:

http://maps.google.com/?q=37.619,-122.375&ie=UTF8&ll=37.619494,-122.373772&spn=0.000935,0.002103&t=k&z=19&om=1


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] piston aircraft pre-flight engine runup

[David Megginson]

On 05/10/2007, drew <[EMAIL PROTECTED]> wrote:

> Yes. I've actually had the "pleasure" of pushing a crate with a shonky donk
> back to the hanger.

There is an alternative, sometimes.  If the plug isn't completely dead
but just misfiring a lot, you can often clear the lead by doing a
high-power, lean ground run for about 5 minutes.  Rental planes are
especially prone to lead fouling, because a lot of people taxi them
around with the mixture set to full rich.


All the best,


David

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] piston aircraft pre-flight engine runup

[David Megginson]

On 05/10/2007, drew <[EMAIL PROTECTED]> wrote:

> In "real life" flying of the Cessna 172/152/150, you run the engine up to 1700
> rpm then check the health of each ignition system by switching off the left
> then right magnetos in turn and watch for a corresponding drop in rpm
> (typically 50-75 rpm). This drop in revs does not seem to be simulated in FG
> in any piston engined aircraft that I have tried.
> This is not a complaint, just an observation. Can this be simulated in FG (or
> am I just a silly old pedant).

To make things more interesting, the drop is much more dramatic when
you do the check with the mixture heavily leaned, so you don't just
want to hardcode a 50rpm drop when there's just one magneto selected.

For the non air-heads, each cylinder has two spark plugs, one
connected to each magneto (e.g. two independent ignition systems);
when you select only a single magneto, one of the spark plugs in each
cylinder doesn't fire, and the overall power output drops very
slightly.  If there's a problem, however -- say, one of the plugs is
lead-fouled -- the engine will start running *very* rough, since it's
dragging a dead cylinder.


All the best,


DAvid

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] OSG vs. trees and buildings

[David Megginson]

What are the issues with OSG around dynamic scenery (trees, non-static
randomly-placed buildings, 3D clouds, etc.)?  Is it just a matter of
spending a few hours coding, or is there something in the OSG APIs
that makes dynamically-generated scenery difficult?


All the best,


David

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG vs. trees and buildings

[David Megginson]

On 19/09/2007, Heiko Schulz <[EMAIL PROTECTED]> wrote:

> Sebastian Bechthold is working on that- he is working
> about a implemention of an "object placer" which
> automatic places buildings to right textures/
> materials. If there is a town, so there are buildings
> depending of it is industrial or normal life or
> anything else

Excellent. Is he modifying the existing plib-based code for doing
that, or implementing entirely new code?


Thanks,


David

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Looks great

[David Megginson]

On 19/09/2007, Durk Talsma <[EMAIL PROTECTED]> wrote:

> Welcome back and thanks for the compliments! As for versions: No, there isn't
> a 1.0 in sight yet, but I'm currently trying to help Curt in getting ready
> for a new release soon. This will be a plib based release, called 0.9.1[1].

I didn't realize that the plib version was still being developed in
parallel with the OSG one.  Would I be just as up-to-date if I checked
out a plib branch, or is the focus for the future still OSG?


All the best,


David

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Looks great

[David Megginson]

I have a new notebook (an HP TX1220, which is a stunningly beautiful
machine), and decided to try compiling the latest CVS osg FlightGear
instead of using the old precompiled plib version from the Ubuntu
distro.  Here are some comments:

1. Wow!  The program is looking great.  It was a very nice surprise to
start up the Warrior and see so much detail from my own plane
(including the ugly 1979 upholstery).

2. I see that there are still some issues with OSG, particularly with
random objects and visibility.  Right now, fgfs isn't usuable for IFR
practice -- my main use -- because of the strange artifacts flying
through low ceilings and vis, so I have to keep the old plib version
on my HD as well.

3. Still no version 1.0, Curt?

I don't have a lot of time to contribute, but I might try to help with
#2, if anyone can point me to archived messages or other resources
discussing the problem.


All the best,


David

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel