Re: [Flightgear-devel] Runtime error 0.9.9 on Debian/Testing

2005-11-12 Thread Alex Perry
From: Curtis L. Olson [EMAIL PROTECTED]
 Alex Perry wrote:
 freeglut  ERROR:  Function glutSetCursor called \
  without first calling 'glutInit'.

 Hey Alex, this has been a 'common' issue that has bit a lot of people.  
 There appears to be a problem with freeglut 2.4.  The solution has been 
 to downgrade to freeglut 2.2 or run freeglut-cvs.  You could also build 
 with sdl (configure --enable-sdl) and that might side step the issue 

Debian is packaging 2.4.0 under the name freeglut3.
Is there a specific upstream release that contains the fix,
so that I can file a bug against the existing package ?
Otherwise, Debian will be unable to build a current FGFS release.

Flightgear-devel mailing list

Re: [Flightgear-devel] FlightGear Review

2005-11-12 Thread Alex Perry
From: Martin Spott
 Vassilii Khachaturov wrote:
  Maybe some German-speaking user could point the reporters to Atlas
  for the moving map solution they describe as absent [...]
 I probably would do, but I don't have any experience with Atlas at all,
 so I'm unable to give appropriate response to the questions that I
 suppose will follow 

Martin, you're welcome to respond and mention me for further questions.
I'd rather have someone whose German grammar is less rusty than mine
respond ... initially at least.

Flightgear-devel mailing list

[Flightgear-devel] Runtime error 0.9.9 on Debian/Testing

2005-11-11 Thread Alex Perry
I haven't tried to debug this yet, but thought I'd report it.

$ fgfs
opening file: /usr/local/share/FlightGear/Navaids/carrier_nav.dat
RenderTexture Error: glXCreateGLXPbufferPtr() failed.
Initialising callsign using 'Aircraft/c172p/Models/c172p.xml'
freeglut (fgfs): Failed to create cursor
freeglut  ERROR:  Function glutSetCursor called \
without first calling 'glutInit'.

Flightgear-devel mailing list

[Flightgear-devel] UFO - non-discussion

2005-11-10 Thread Alex Perry
   Melchior FRANZ writes
 It is beyond me why nobody seems to understand the purpose of the UFO.
 It was never meant to be a serious aircraft. It is the scenery
 exploration tool. It doesn't need to have a cockpit or a realistic
 FDM. It uses up 76 kB uncompressed, and 10.8 kB compressed! Even
 the NEWS file is 23 kB big -- compressed!

I agree with all of that ... and it should continue in that role.

 I agree with Melchior on this.I found it very usefull when I was playing
 around with the AI for Durk awhile back.

That too.  Maybe a change of name (from UFO) may reduce confusion?

Now, should someone try to create an interior looking like a classic
UFO (with a funky control panel, LGM passengers, a radio panel that
works but looks like it was built from alien lab equipment by alien
scientists in order to communicate with human ATC services, etc etc)
then I personally would love to see that included in the FGFS model.
But ... maybe as an external download ... because it'll be fairly big.

Flightgear-devel mailing list

[Flightgear-devel] Re: FlightGear as a real time synthetic view

2005-10-30 Thread Alex Perry
Curt wrote in web page
 We were disappointed with the data rate we were getting (maybe 5hz.)
 This prevented us from doing any serious flying under the hood.
 But I think we validated our approach and when we track down our
 data rate issues we will have a very powerful remote piloting tool. 

Curt, if the Rascal's rate factors are comparable to light aircraft,
you should be able to fly under the hood with a 5 Hz update rate.
Being under the hood implies restricting yourself to IMC maneuvers and
achieving VMC 15 seconds before the IMU tolerance touches the ground.

I'd suggest some practice; set the FGFS framerate for 3Hz (to allow for 
lags in the GPS/IMU and comms links) and fly an IFR departure/arrival.
Keep roll rates below 30 deg/sec, climbspeed faster than Vy, descent
speed below Va, turns at standard rate (definitely less than double).
That restrictive envelope is what keeps the feedback loop (via human)
slow enough to be safe with the limited update rates (in your case)
or with a pilot needing to retune navigation systems (in general).

Flightgear-devel mailing list

[Flightgear-devel] SCALE 4

2005-10-23 Thread Alex Perry
Ilan wrote:
 At the moment both the speakers committee and community relations
 committee are seeking contributions:

 Call For Papers:
 Call For .Orgs:

Flightgear-devel mailing list

[Flightgear-devel] Re: fgfs on AMD64 status?

2005-10-19 Thread Alex Perry
 I'm secure enough now that I'm shopping to build a new machine.  I'm looking
 at AMD64 motherboards and one of the newer nvidia cards.  And what I'm
 wondering is whether any fgfs developers can speak to building and running
 fgfs, on linux, on an AMD64 box, and/or with the nv 6600's/6800's etc.
 I've seen some threads that people are running it on AMD64 OK; but I'm
 wondering if there are any suggestions, recommendations, or warnings that
 are worth hearing before I start shelling out the big $ (e.g. mobos you're
 happy with or had nothing but trouble with).  I wanna get back to this stuff.

FGFS runs fine under AMD64 in both 32 bit and 64 bit architectures
and has done so for 18 months.  Debian i386 Testing and AMD64 Unstable,
as they were called at the time (AMD64 Testing didn't exist initially).
USB joysticks are unaffected by transitioning between 32 bit and 64 bit.

You seem to be going for desktop chassis; in which case the motherboard
chipset is a minor issue (compared to the nightmare that laptops can be)
and not one I can help with.  All my non-server AMD64 systems are laptops.

Your only real remaining issue is whether your video chipset will run
accelerated with the 32 bit and/or the 64 bit kernel.  If you use a
card that's old enough to have open source drivers, this is trivial.

Both NV and ATI provide 32 and 64 bit versions of their binary drivers,
supporting both and xfree86, so there is no availability problem.
People have had various levels of luck with installation gremlins though.
Therefore, I suggest checking the mailing list for your specific chipset.
Once that is taken care of, I'd just install and start flying around.

Hope that helps.

PS.  If you're going to be dual boot for both 32 and 64 bit architectures,
don't forget to have the disk space containing FGFS's data (and scenery)
be shared.  You don't want to install (eg) Alaska on one filesystem,
then later reboot, then realize you have to do that installation again.

Flightgear-devel mailing list

Re: [Flightgear-devel] Does anybody try compile FG with gcc 4.0?

2005-10-07 Thread Alex Perry
 Does anybody tried to compile FG with gcc 4.0? Did you encounter any
 problems, serious warning like uninitialized variable is used?

GCC 4.0.1 is the default in Debian Testing and therefore gets picked
up when you run the ordinary build scripting associated with CVS.
It seems to work fine; there have been a few patches submitted
by various people (over many months) for the 3-4 migration.

I will say that it's a good idea to do a make clean after you
transition your toolchain from gcc3 to gcc4.  Otherwise some
odd things happen.  I haven't noticed any other differences.

Flightgear-devel mailing list

[Flightgear-devel] Odd beige lines

2005-10-02 Thread Alex Perry
In the southern california deserts, there are beige lines wandering
around the countryside that randomly cross the brown road lines.
The road layout makes sense, but I can't figure out what the beige
lines are supposed to be; their paths don't match obvious landscape
features.  If they're supposed to be streambeds, they're extremely
conspicuous compared to real life and sometimes go up hillsides.

Flightgear-devel mailing list

[Flightgear-devel] OT: Simgear and SGFile usage in FGFS

2005-09-23 Thread Alex Perry
Unless I'm missing something, someone has committed bad code to CVS.
The ch variable on line 377 is of class SGIOChannel, which doesn't
support the eof() method, and not of class SGFILE, which does.

~/fs/source/utils/GPSsmooth$ make
if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../../src  
-I/usr/X11R6/include -I/usr/local//include  -g -O2 -D_REENTRANT -MT MIDG-II.o 
-MD -MP -MF .deps/MIDG-II.Tpo -c -o MIDG-II.o MIDG-II.cxx; \
then mv -f .deps/MIDG-II.Tpo .deps/MIDG-II.Po; else rm -f 
.deps/MIDG-II.Tpo; exit 1; fi
MIDG-II.cxx: In member function `int MIDGTrack::next_message(SGIOChannel*, 
   MIDGpos*, MIDGatt*)':
MIDG-II.cxx:377: error: `eof' undeclared (first use this function)
MIDG-II.cxx:377: error: (Each undeclared identifier is reported only once for 
   each function it appears in.)
make: *** [MIDG-II.o] Error 1

Flightgear-devel mailing list

[Flightgear-devel] Re: type conversion problem for amd64

2005-09-23 Thread Alex Perry
From: Erik Hofman
 George Patterson wrote:
  Tonight I cvs checkout the simgear sources tonight from cvs to
  recompile FlightGear. I was getting the following error. (Also got the
  same error in swap_test.* but worked around that problem by remove the
  file and references to it.
 Could you test the latest version in CVS, there was some restructuring 
 of this code and I think this is solved now.

Erik, it works fine for me under Debian/Sarge AMD64.
George, what toolchain are you using ?

$ gcc --version
gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
$ uname -a
Linux host 2.6.13 #1 Sun Aug 28 19:57:26 PDT 2005 x86_64 GNU/Linux

Flightgear-devel mailing list

[Flightgear-devel] Re: Question: Online forums?

2005-09-14 Thread Alex Perry
From: Curtis L. Olson
 What would people think of abandoning our mailing lists and converting 
 over to online/web-based forums?

I wouldn't subscribe to the forum; but if there was a daily digest
(like the list currently has) then I might consider receiving that.

 - I'm getting really sick of spam.  I think we do a pretty good job of 
 protecting the list members themselves, but the list admins get 
 continually pummeled with spam rates measured in messages per hour and 
 sometimes messages per minute ...

Fix the real problem.  Make the admin messages go through a procmail.
An autoresponse tells people to use the web page subscribe/unsubscribe
if they're having trouble, mentions the message size limit, points out
the web archive of old traffic, and explains that anybody really wanting
to contact the list admins should be able to figure it out using Google.

 If we would like to move towards using forums instead of mailing lists:
 - Should we manage the forums ourselves on our own FG servers?

Sure.  Bear in mind that it takes _more_ admin effort for a forum.
There are a lot of bots now, that know how to create user accounts.

Flightgear-devel mailing list

[Flightgear-devel] Re: Automated builds on Linux

2005-09-13 Thread Alex Perry
From: Richard Bytheway [EMAIL PROTECTED]
 needs root privs for the make install sections.

Look at the command sudo.

Also, you may want to over-ride the default install command to
add the -p option, so that incremental rebuilds work properly.

Flightgear-devel mailing list

[Flightgear-devel] Re: Custom Scenery for Lake Constance

2005-08-21 Thread Alex Perry
 However, those data did not make it to the current scenery release as 
 TerraGear choked, obviously due to the massive density of data. I'm 
 going to further investigate this - maybe with a little help from the 
 experts on this list - and I hope that we can at some point release at 
 least some compromise version between nearly no linedata and 1 FPS 
 ;-) The current selection of the data subset kept is arbitrary and not 
 necessarily sensible.

Try watching your virtual memory usage and see whether you're hitting
the 2GB (or 3GB) limit within that process.  If you are, it is worth
patching TerraGear until it runs cleanly on all 64 bit architectures.
If it isn't a memory problem, we can stick with the 32 bit for now.

If memory _is_ the limiting factor, it is easy enough to take all the
RAM of other computers on the network and make it available as swap
space on the 64 bit machine that is actually building big scenery.
Swapping over network to memory is a lot faster than to hard drive.

Flightgear-devel mailing list

[Flightgear-devel] Re: another compass question

2005-07-29 Thread Alex Perry
From: Josh Babcock [EMAIL PROTECTED]
 I know that the fg magnetic compass code models errors due to tilt
 pretty well, but it occurs to me that a lot of these compasses are
 gimbaled and remain flat for a few degrees as the plane tilts. Is this
 aspect modeled?

I believe you misunderstand the purpose of gimballing.  It eliminates
any dependency of the compass indication on aircraft speed (since the
pitch and angle of attack do not affect it) and also avoids any
dependency on yaw management (such as slips or uncoordinated turns).

In most civil aviation flight operations, the readout of a gimballed
and an ungimballed compass is similar.  This is unlike (eg) a boat.

Dave's code is based on mine so, unless an error has crept in, it
already uses the local acceleration vector and not vehicle attitude.
Consequently, the calculation of the indicated value is inherently
for a gimballed compass.  I did that because most aero compasses are
gimballed.  It is possible to turn the sim gimbal off, if desired;
I'm not aware of any aircraft design that uses such an instrument.

My code had the gimballing explicit; I don't recall whether David kept
that aspect.  If you exceeded the gimbal's range of motion, the card
would block and cease to move until your attitude became coordinated.
Carefully flying an uncoordinated 180 degree turn, for example, could
get the compass to keep showing the original heading until you roll
out level ... at which point the thing would oscillate madly down.

As an aside, if the compass is regularly oscillating like that for
you ... you need to practice smooth flight.  The blockage only 
happens for situations that would routinely have your passengers
abandoning their lunch all over your instrument panel.  FYI.

There _is_ a weakness in the current FGFS systems, namely that the
rendering of the wet compass (on the 2D or 3D instrument panel)
does not show the gimballing happening.  This is wrong, of course.
In practice, the mechanics and optics of the instruments are
designed so that the translational motion of the compass interior
is not distracting to the user ... so this omission is not obvious.

If one of the instrument modellers would like to add the additional
rotation axis (2D, around the center top of the card area) or
axes (3D, tilt laterally and longitudinally about the center top)...
I'll be happy to write up what calculation has to go behind it.

From: Erik Hofman [EMAIL PROTECTED]
 I wouldn't know, It is modeled by David Megginson. You might want to 
 test it yourself.

Seconded.  When David converted my special case code into his neater
and generic instrument layer, most of the math was necessarily 
rewritten.  A bug could easily have crept in that neither of us
noticed at the time.  And my original code could've had a bug too.

Flightgear-devel mailing list

[Flightgear-devel] New aircraft ideas ?

2005-06-23 Thread Alex Perry
Got an idea for a new aircraft (not airplane) you'd like to try ?
Topic: A05-208

Flightgear-devel mailing list

[Flightgear-devel] Systems modelling

2005-06-09 Thread Alex Perry
From: Ampere K. Hardraade [EMAIL PROTECTED]
 Why should the electrical system be made generic?

It shouldn't.  There is a whole class of physical systems that
act as a network with two valued paths.  Voltage/Current,
Pressure/Velocity, Density/Massflow, some aerodynamics, etc etc.

All of these systems need to be solved as a network in order
to capture interactions, without hard coding solution paths.

 All these system are basically different forms of moving something 
 from point A, through medium B, to point C.

The problem with that approach is that you have to allow for
(a) the amount of thing being used at B varying when C turns off,
(b) sometimes, stuff can be flowing from C to A and to B, etc.

 implementation can be as simple as *b = a; (in C's terms).

I don't think so ...
one of the reasons I gave up on FGFS as a failure modelling
simulation for training purposes is that the various buses
do not manage combinatorial failures and side effects right.
You can hard code the stuff, but it may not cover all cases.

From: Curtis L. Olson [EMAIL PROTECTED]
 3a. The system is very complex with a lot of subtle interactions and 
 side effects.  It's unclear for someone new coming into the project 
 exactly how it works and what you have to do to build a successful 
 electrical system model.

I think the most important thing is to capture the network that drives
the interactions for the general case, so we have confidence that the
model will be correct for any situation, and then leave it to a 
dedicated solver to infer what the decision tree is at any time.

 4a. What we really need is someone who actually understands all this 
 stuff to build a better data driven electrical system model using a 
 better, more flexible approach.  I am told that SPICE is a good example 
 of doing this right, but I'm a computer scientist with very little EE 
 knowledge or ability.  Circuits strike fear into my heart.

If the developers want to do it using a circuit solver, which I think
is probably the right way to go, I'd be happy to provide an object
oriented definition of what we need to have in the property tree.

Separately to that, I can write up what the circuit solver has to do.
It isn't particularly complicated, providing you're not trying to 
cover all the things that can happen to semiconductors/transistors
when designing logic chips that run reliably at gigahertz speeds.
It's that high end stuff that makes a SPICE codebase complicated.

 4b. An alternate approach would be to write a procedural electrical 
 system model for each specific aircraft using nasal.  But is there a way 
 to have  a default nasal function that can be overwritten by an 
 aircraft specific function?  I am almost favoring the nasal approach 
 here for many of these aircraft specific subsystems.

I don't have an opinion about this, having not used nasal seriously.
Can it be used to write a modular solver that propagates both ways?

 I realize this expands the discussion rather than focussing it, but I'm 
 getting really frustrated with the inabilities of the current electrical 
 system to do things like model battery charging (without trying to 
 charge itself and other goofy things), model ammeter gauges (i.e. 
 measure current flow between two different points in the network), do 
 load balancing between multiple alternators and a host of more complex 
 things.  I like the idea of a v2.0 electrical system that is similar to 
 the current system, but designed by someone who knows what the 
 H-E-double toothpicks they are doing (obviously not me.)  But in the 
 mean time, nasal would be a quick and dirty approach to getting a fairly 
 functional electrical system up and running pretty quickly.

A final thought that might help y'all decide what to do ...

As I see it, the _most_ important thing is to ensure that the method
used to describe how the model works will be understandable to aircraft
mechanics who have no programming experience.  Those are the people who
really know what the electrical system wiring looks like and what has
to be added into a model.  If they cannot read the computer parsable
description in the aircraft file, they will be unable to find mistakes.

Now: _if_ you decide that this should be the driving consideration 
and there are no technical obstacles that inherently for the decision
for us, please build two versions of the same electrical system and
I'll collaborate with the FAA to get the local avionics shops to let
us know which they can understand better.  They should be interested
in supporting us because it's in their interests to have a good
training tool.  Both their techs (who can look through our files) and
for their pilot customers (who persist in operating stuff wrongly).

I suggest the C172 electrical system, with _all_ switches, breakers,
interior lights, and all avionics loading their respective bus.
C172s have a really simple system; fits on a single sheet of paper.
It's a handy test case before trying 

[Flightgear-devel] BoF Meeting about FGFS next week, in Anaheim California

2005-04-05 Thread Alex Perry

Title: Adapting the FlightGear Flight Simulator - Customizing your Cockpit

Name:  John Wojnaroski
Affil: FlightGear project, Developer

Room:  Salon 3, Tuesday April 12, 7pm to 8pm
Site:  Marriott Anaheim, 700 West Convention Way, Anaheim, CA 92802-3483.
   Within walking distance of Disneyland and California Adventure Parks.

The 747 Simulator was a big hit at the recent SCALE3x expo held in
Februrary.  Integrating the best from the open source community with
hardware has proved to be a daunting task. The author walks you through the
steps and thinking behind the design decisions and details the integration
of the hardware and software.

Curt:  Could you add this to the events page please ?

Flightgear-devel mailing list

[Flightgear-devel] Re: Total Energy instrument

2005-02-24 Thread Alex Perry
From: Paul Surgeon [EMAIL PROTECTED]
  I'm an ASEL pilot (without glider training) but I was of the impression
  that the variometer was a slightly modified pitot tube connected to a VSI.
 That sounds about right.
 As far as I know one can hook up most variometers to any TE probe.

The easy non-software thing to do is to hook up a second VSI simulation
to the pitot simulation instead of the static simulation.  Then, take
the VSI instrument and change the artwork to look like a vario and add
a second rotation layer.  The first rotation layer watches the normal
VSI simulation, the second rotation layer watches the new pitot VSI
except that it is cumulative to the first and in the other direction.

 What also differs between some designs which use a TE probe is the inclusion 
 or exclusion of a flask that is used to average the reading out.

In the C++, I'd simply copy the altimeter code (which has both data sources)
and the VSI code (which has the low pass filter and the like) and merge them
into a new function.  Other than that, there isn't much coding needed.

  Are you trying to simulate the aircraft instrument or are you trying to
  provide the same value as an expensive air data computer would yield ?
 I'm trying to simulate an aircraft instrument.

Do you have all the information you need, or should I ask for help ?

 From what I've seen from googling this stuff it looks like the TE vario is 
 midway between a standard vario and a netto vario in capability.
 In flight the pressure at the TE Probe is the sum of the static pressure
 and the suction produced due to airspeed. At constant airspeed the TE
 probe acts like a static source and the variometer indicates the
 rate of change of static pressure converted to equivalent rate of
 climb or sink.

Flightgear-devel mailing list

[Flightgear-devel] Total Energy instrument - Was Instrument headaches

2005-02-23 Thread Alex Perry
  1. Create a new Variometer instrument module i C++.
 If I was able to create a Total Energy Tube module it still leaves me 
 without a way to perform calculations and logic that are vario specific.

I'm an ASEL pilot (without glider training) but I was of the impression
that the variometer was a slightly modified pitot tube connected to a VSI.
Are you trying to simulate the aircraft instrument or are you trying to
provide the same value as an expensive air data computer would yield ?

If you want the air data computer output, you'll need the C++ stuff.
If you want realism, I suggest you assemble what real aircraft use.

I don't know whether there are any avionics techs with glider background
on the list.  If not, I'd be happy to ask the local FAA office, or
some of the staff at the several gliderports around here, for help

Flightgear-devel mailing list

[Flightgear-devel] Re: FlightGear booth at Scale 3X

2005-02-19 Thread Alex Perry
From: Ampere K. Hardraade [EMAIL PROTECTED]
 On February 18, 2005 04:11 am, Erik Hofman wrote:
  It also looks to me like a pleasant isle of joy in an
  otherwise boring event (am I right about that?).
 lol... I have a similar thought about the event.

The FGFS booth was busy pretty much the whole time the floor was open;
that's why Trisha and I ended up helping out when we could spare the time.
John, Curt and Jim each managed to get away for short periods for a quick
sprint around the expo area, but they didn't get much time to chat at the
other booths ... or to attend the four tracks of conference sessions.
Except that several exhibitors were moved between the map and the day.
FGFS was actually lower left in the spot labelled for ObjectWeb,
the FSF took the vacated FGFS spot near FreeBSD, KDE was a no-show.

From: John Wojnaroski [EMAIL PROTECTED]
 Actually, there were other interesting booths, the astronomy one was pretty
 nice and there was some good network stuff. but none as interactive as the
 FlightGear booth. I didn't have much time to explore as we were quite busy
 right up to the end. It was a fairly small show, nothing on the scale of a
 Linux World.

Several booths had hardware for show-and-tell purposes, often neat stuff,
but none of them had something truly interactive like John's simulator.
In that sense, the expo was about average compared to other trade shows.
After all, it's hard to do a hands-on interactive booth if you're the FSF.

One thing that was nice was all the booths were staffed by people who knew
what they were doing and why they wanted to be at SCALE.  I didn't end up
talking to people who didn't know the (a) product (b) show or (c) market;
I always end up wondering why those companies bother to turn up at all.
A non-trivial technical discussion was feasible at any of the booths.

I was able to have long chats with the KnopMyth, Novell, PyX, Petta,
Debian, SOCALWUG, Usenix, Mambo booths ... and specific people too.
In that sense, it was better than being at the larger LWCE show floor.
Assuming they run a SCALE4X, I'll be trying to get to it.

Flightgear-devel mailing list

[Flightgear-devel] My photos of the FGFS booth at SCALER

2005-02-15 Thread Alex Perry
As I mentioned earlier, last weekend I attended
Southern California Linux Expo (SCALE) in Los Angeles:

The FlightGear project had booth space in the expo hall:

John Wojnarowski's amazing 747 cockpit was being demonstrated:

I've put my five pictures of the FlightGear booth at SCALE here:


Flightgear-devel mailing list

[Flightgear-devel] SCALE - official pictures

2005-02-14 Thread Alex Perry
The SCALE website has some pictures up from the event:

In particular, this one may be of interest ...

I took some pictures of the booth too, but haven't looked at them yet.

Flightgear-devel mailing list

[Flightgear-devel] splash

2005-01-16 Thread Alex Perry
Why can't we have a tiny little app that is just intelligent enough
to find the XML file, check whether we should be splashing ourselves,
knows to abort quietly if not, and otherwise brings up a splash window?

Given something like that, with very very few library dependencies,
we should be able to fork that off as the very first thing we do.
While the main program is still trying to get the DLLs linked up,
the forked utility would long since have put up the splash screen.

When we have the main loop running and the simulator has run one second,
we simply send a signal to the splash and it gracefully suicides.

Flightgear-devel mailing list

[Flightgear-devel] UI (was no subject)

2004-12-20 Thread Alex Perry
I think the existing external telnet access is an excellent feature.
It would be nice to put some effort into making the underlying code
more efficient so that the simulator doesn't mind it being used a lot.

On a separate note, I propose the following feature (if not present):
1.  A command on the telnet interface for adding menu items to the PUI.
2.  When the associated telnet session closes, the menu items disappear.
3.  A telnet command to put up a PUI dialog and return the results.

We could create a python class that uses the existing telnet module
and makes the menu item addition and PUI dialog invocation accessible.
A separate class can offer the same services but use a GTK backend.

That would let us all write nice features as python scripts which,
for single user, attach to the main FlightGear PUI interface or,
for training use, interact directly with the instructor's console.

Flightgear-devel mailing list

[Flightgear-devel] Re: Magnetic Compass

2004-11-22 Thread Alex Perry
From: Boris Koenig [EMAIL PROTECTED]
 David Megginson wrote:
  I understand
  that there are USB devices that you can wear on your head to control
  the view in games, and those would probably work in FlightGear, but it
  would be hard to survive the ridicule from family, friends, and
  neighbours for wearing one.
 LOL, that would indeed be very amusing ... must probably look very
 similar to the BORG on Star Trek ;-)

There are two different things here.

Normally, for gaming, people want to keep their head stationary
(in linear dimensions) and look in different directions (angular).
What people are talking about here is wanting to keep their
direction of gaze (fixed object) but change their point of view.

The former is easily addressed with a simple magnetic compass module,
to figure out which way you're looking, and a head mount display so
that the screen is always located in the correct direction (in front).
The compass module is usually integrated into the HMD and so not really
a source of looking 'odd', at least compared to the HMD unit itself.

However, the compass module doesn't work when the user wants to be able
to move their head and still look in the same direction.  For example,
to lean forward in order to read the tiny little numbers on the altimeter.
For that, you need to track the position of the head, not direction,
so you really want a different kind of sensor to address that need.
You don't need a HMD either, since the instrument panel doesn't move.
There are sensors for this, for example by putting ultrasonic ranging
transducers on your head and on the four corners of the monitor,
but nothing I'd really recommend to you as being a marvellous solution.

Assuming there is a network socket that is providing the 3D position
of the nose (for example) of the user with respect to the monitor,
how hard is it to get FGFS to slew the camera/viewport relationship ?
I've got stuff lying around at work here that is fairly cheap and can
be made to do the sensing job, so it'd be interesting to try it out ...

Flightgear-devel mailing list

[Flightgear-devel] Re: ATI 9200 Direct Rendering problem on Linux

2004-11-08 Thread Alex Perry
From: Martin Spott [EMAIL PROTECTED]
 Ampere K. Hardraade wrote:
  Sigh... and I thought ATI is supposed to be Linux-friendly?!
 Things have changed a bit these days, but the r200 chip is still one of
 the best supported GPU's in the OpenSource world. The problem on _your_
 computer is not ATI's fault

Martin isn't kidding.  You have to pick _one_ route, either the open
source one or the closed source one, and get your whole 3D system,
from user libraries through to kernel modules, lined up to support
just that execution path ... end to end.  That's the key point.

I can give you advice on the fglrx route (which is what I'm using),
Martin can give you advice on the route (which he knows).
However, if you don't choose and strip back your system, you'll fail.

Rmember:  Linux has compatibility way beyond Microsoft, which means that
everything will do its best to get it to work (badly) when misconfigured
instead of simply not working and spewing errors all over the place.
All it takes is one 'compatible' element in the path to break DRI.
If DRI doesn't come up, it means you have missed some key element.

Flightgear-devel mailing list

[Flightgear-devel] Re: Re: ATI 9200 - fglrx

2004-11-08 Thread Alex Perry
(Maybe we should fork the subject to the open and closed source alternatives)

From: Steven Beeckman [EMAIL PROTECTED]
 Alex Perry wrote:
 I can give you advice on the fglrx route (which is what I'm using),
 PS: Alex: what's fglrx? The drivers from ATI? I've tried the rpm I 
 think, but it didn't work out either :-s (probably because of what you 
 said: two ways to solve the same problem ...)

They've always worked for me (aside from the known rendering bugs sigh),
but it used to be a fair amount of hassle to get them running on Debian.
Currently, they rpm download seems to convert cleanly (using alien) into
a deb that works for both Stable and Testing.  You just need a single
dpkg-divert to deal with one file that is unnecessarily duplicated.

I suspect the biggest mistake people make, under Debian or similar,
is to try the install _outside_ their distribution's packaging system.
That drops your integrity to the level of a third party WinXP install.

Flightgear-devel mailing list

[Flightgear-devel] Re: ATI 9200 Direct Rendering problem

2004-11-08 Thread Alex Perry
 On November 8, 2004 11:12 am, Alex Perry wrote:
  Martin isn't kidding. ?You have to pick _one_ route, either the open
  source one or the closed source one, and get your whole 3D system,
  from user libraries through to kernel modules, lined up to support
  just that execution path ... end to end. ?That's the key point.
  I can give you advice on the fglrx route (which is what I'm using),
  Martin can give you advice on the route (which he knows).
  However, if you don't choose and strip back your system, you'll fail.

From: Ampere K. Hardraade [EMAIL PROTECTED]
 It turned out that the half of dozen kernel panic I have
 and my sloppy repair works was also a contributor to the problem.
 To make a long story short, I 
 wipped the drive clean and start fresh.
 I would certainly like to hear your advice on the fglrx route. =)

All, I'll respond to Ampere directly (feel free to ask me for copies
of the messages).  When he is up and running, he can post to the list
to say what the _important_ bit of what I told him turned out to be.

Flightgear-devel mailing list

[Flightgear-devel] Re: ATI 9200 Direct Rendering problem on Linux

2004-11-07 Thread Alex Perry
 Also, in the XFree86.0.log, this keeps coming up:
 (EE) fglrx(0): [agp] could not determine AGP since mode=0x
 I did some googlings but I couldn't find anything related to this problem

If my memory serves me correctly, this is referring to the mask by which
you specify which AGP modes the hardware is allowed to operate in.
The mask is needed because a lot of motherboards and cards specify
that they can support modes ... which don't actually work properly.

Flightgear-devel mailing list

[Flightgear-devel] Re: ATI 9200 Direct Rendering problem on Linux

2004-11-07 Thread Alex Perry
The bits I thought were relevant:

 (II) PCI: 01:02:0: chip 1002,5964 card 148c,2074 rev 01 class 03,00,00 hdr 00
 (--) PCI: (0:2:0) Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated 
 Graphics Device rev 1, Mem @ 0x2000/27
 (--) PCI:*(1:2:0) ATI Technologies Inc unknown chipset (0x5964) rev 1, Mem @ 
 0xc000/28, 0xff8f/16, I/O @ 0xd800/8
 (II) Primary Device is: PCI 01:02:0
 (--) Chipset ATI RV250SE Yd (R9200SE) found
 (**) fglrx(0): Option UseInternalAGPGART yes
 (--) fglrx(0): Chipset: ATI RV250SE Yd (R9200SE) (Chipset = 0x5964)
 (--) fglrx(0): (PciSubVendor = 0x148c, PciSubDevice = 0x2074)
 (--) fglrx(0): board vendor info: third party grafics adapter - NOT original 
 (II) fglrx(0): Kernel Module Version Information:
 (II) fglrx(0): Name: fglrx
 (II) fglrx(0): Version: 3.14.1
 (II) fglrx(0): Date: Sep 27 2004
 (II) fglrx(0): Desc: ATI Fire GL DRM kernel module
 (II) fglrx(0): Kernel Module version matches driver.
 (II) fglrx(0): Kernel Module Build Time Information:
 (II) fglrx(0): Build-Kernel UTS_RELEASE:2.6.9
 (II) fglrx(0): Build-Kernel MODVERSIONS:no
 (II) fglrx(0): Build-Kernel __SMP__:no
 (II) fglrx(0): Build-Kernel PAGE_SIZE:  0x1000
 (II) fglrx(0): [drm] register handle = 0xff8f
 (II) fglrx(0): [agp] Mode=0x bridge: 0x8086/0x2560
 (II) fglrx(0): [agp] AGP v1/2 disable mask 0x
 (II) fglrx(0): [agp] AGP v3 disable mask   0x
 (EE) fglrx(0): [agp] could not determine AGP since mode=0x
 (EE) fglrx(0): cannot init AGP
 (II) fglrx(0): [drm] removed 1 reserved context for kernel
 (II) fglrx(0): [drm] unmapping 8192 bytes of SAREA 0xe01d4000 at 0xb7db7000
 (WW) fglrx(0): ***
 (WW) fglrx(0): * DRI initialization failed!  *
 (WW) fglrx(0): * (maybe driver kernel module missing or bad) *
 (WW) fglrx(0): * 2D acceleraton available (MMIO) *
 (WW) fglrx(0): * no 3D acceleration available*
 (WW) fglrx(0): * *

It found the card, initialized the driver, everything is fine.
However, you told it to use the built in AGP driver, rather than
the kernel one, and it failed to initialize the motherboard.
This may be due to misconfiguration in the X driver config,
but is more likely because the kernel driver is already loaded.

Flightgear-devel mailing list

[Flightgear-devel] ATI 9200 Direct Rendering problem on Linux

2004-10-30 Thread Alex Perry
From: Ampere K. Hardraade [EMAIL PROTECTED]
 Subject: [Flightgear-devel] ATI 9200 Direct Rendering problem on Linux
   (wasAI Carrier)

I didn't follow the prior thread title due to too much day work.

First, I assume you have the correct version from the ATI website,
use the alien package to convert it into a deb and are only using
that deb package so that all files are being properly tracked.

 Thanks for helping me out on this problem.  So far, I have tried:
 - compiling agpgart as builtin and as a module

I've got agpgart built in ... check your motherboard chipset choice.

 - compiling with and without DRM

I've got new DRM built in (for 4.1 version) ... check the video chip.
Note that these answers are for an ATI 9600 laptop, but the same
approach worked for a ATI 9200 video card in a workstation chassis.

 - enabling and disabling the useinternalagpart in XF86Config-4

I've got it enabled in the file (but it will fail and use the kernel).

 - using either XF86Config-4 generated by fglrxconfig,
   or that generated by dpkg-reconfigure xserver-xfree86

I generated both, then used the dpkg one as a source of ideas to 
modify the fglrx one to be more like the way I really wanted it.

 - removing xlibmesa and reinstalling it

I never bothered trying to do that.  If you have a file conflict,
just use dpkg-divert so that the fglrx version can replace the other.
My output from dpkg-divert --list includes this line ...
diversion of /usr/X11R6/lib/ to \
 /usr/X11R6/lib/ by fglrx

 - removing xserver-xfree86 and reinstalling it

Never needed to do that.  I simply got everything working with the open
source driver, then archived the XF86Config-4 file (for comparison),
then installed the fglrx driver package on top, then the f*config.

 - removing and recompiling the fglrx modules

I load the fglrx module using /etc/modules on the line after agpgart.
I have the agpgart line in there so that it all still works if I use
a different kernel (such as a stock Debian one) that needs it loaded.

 - removing and reinstalling the fglrx drivers

Never needed to do that.  No opinions.

 (There is no enabling/disabling USB loading for DOS in my BIOS)

The setting doesn't affect me either way, but is handy to have on.
Among other things, it lets you use a USB keyboard during boot.

 This is the order at which I load the modules in /etc/modules:

Seems equivalent to mine.

 I think I am using unstable right now.  Originally, I installed Debian as 
 Sarge.  But I have changed the apt sources to use unstable/main and ran 
 apt-get dist-upgrade.

I'm running on Testing, and that install has been for about nine months.
Currently, Sarge and Sid are close enough that this should be fine for you.

 [EMAIL PROTECTED]:~$ uname -a
 Linux localhost 2.6.8 #1 Sat Oct 23 11:48:00 EDT 2004 i686 GNU/Linux

Aha.  I have been unable to compile a _working_ ATI fglrx module using
the source tree they provided for a 2.6.8 kernel (either i386 or amd64).
Their module source worked for either 2.6.7 and earlier or 2.4.x series.
Of course, they may have provided a newer source tree since then ...

Since the laptop has to have 2.6.8 (or a bunch of patches applied),
I've been using 2.4.25 for 3D work until I have time to investigate
the differences between 2.6.7 and 2.6.8 and come up with a workaround.

 XFree86 Version


Flightgear-devel mailing list

[Flightgear-devel] Re: Quick report from AOPA

2004-10-26 Thread Alex Perry
From: Curtis Olson [EMAIL PROTECTED]
 I was there with ATC flight simulators to demo their ATC-610 upgrade 
 package which turns their old 100% analog ATC-610 into a new, modern 
 digital flight simulator using FG as the visual system, and the core 
 software infrastructure, along with proprietary software [...]

 Alex and Trisha Perry stopped by the last day [...]
Please be kind to the cable modem ... and mirror or cache retrievals.

Flightgear-devel mailing list

[Flightgear-devel] Re: Runway distance remaining signs + placement

2004-09-09 Thread Alex Perry
From: David Megginson [EMAIL PROTECTED]
 On Wed, 08 Sep 2004 21:35:30 +0200, Erik Hofman [EMAIL PROTECTED] wrote:
  I do think so, don't we.
  I mean, this is an essential part of airfields, but don't know enough
  about this subject to assert that the numbers are always right this way.
  There's also the danger of overengineering our airfields

Yeah.  Most of the airports I fly into have them, but then they also have
instrument approaches and runways longer than 4kft.  I'm tempted to say
that we add them onto any runway longer than 5kft or having a LOC/ILS.

Basically, if it is obvious (to the pilot) how much runway remains when
at the midpoint of the runway for the minimum visual conditions ...
I suspect that the signage is not installed because it would be pointless!

class G airport can be clear of clouds ... but signage mostly missing.
class E airport requires 1 mile visual ... need signage at 10kft rwy.
class D airport can do SVFR and instrument ops ... signage at 3kft rwy.

Flightgear-devel mailing list

[Flightgear-devel] Re: Runway distance remaining signs

2004-09-09 Thread Alex Perry
 On Wed, 8 Sep 2004 22:01:29 -0400
 David Megginson [EMAIL PROTECTED] wrote:
  On Wed, 8 Sep 2004 18:35:07 -0400, Chris Metzler
  5.  I don't know anything about how these signs are handled outside
  the U.S.  If you do, let me know.
  I'd be interested in knowing more about how these signs are handled
  inside the US.  I've flown my Warrior to several US airports --
  Massena (KMSS), Caldwell (KCDW), Philadelphia (KPHL), Boston/Norwood
  (KOWD), Republic (KFRG), and Plattsburgh (KPLB) -- and I do not
  remember ever seeing signs like you describe, though I might have
  missed them in the clutter at KPHL.  I suspect that these might be a
  special case for a tiny handful of airports, not a common feature.

David, I have yet to notice a U.S. runway used for commercial service
that does not have them.  However, because of their coloring and 
placement, they tend to be easily overlooked unless you _want_ them.
That is, of course, a good thing ... avoid unnecessary distractions.

Oh, and I noticed their presence in Manchester and Basel-Mulhouse too.
There may be an ICAO rule for airports with international service
that was the original impetus for sign installation on major rwys ...

From: Chris Metzler [EMAIL PROTECTED]
 I'd be stunned if they weren't at KPHL.  I've never flown into/out of
 there, so I cannot say. 

I have and would have remembered if I had noticed them being missing.
Of course, that doesn't mean that they really _were_ there, sigh.

 And, sadly, I'm only hoping to be a pilot
 in the future, so I definitely can't speak to small airports --
 which, of course, are most of the airports out there.  But they're
 a fixture at larger airports here; when I land in an airliner, I
 always look out the window for these signs to see how much of the
 runway the pilot uses.

Yes, but that isn't strictly fair on the pilots.  Just because they
have to plan with balanced runway technique in mind does not mean
that they _need_ as much runway as you observe being used.
The takeoff profile at most airports is specified by noise abatement.
Multiengine only have to stay in ground effect until blue line speed.
Also, I often stay in ground effect to at least Vy for performance
reasons ... even if I'll subsequently use a Vx climb to the pattern.

Flightgear-devel mailing list

[Flightgear-devel] compass turning error gone

2004-08-05 Thread Alex Perry
I've just tried the 0.7.5 release and there is no wet compass turning error.
When did that go away ?  It's kinda important ...

PS.  I'm not receiving e-mail at my usual address for a while.  Use this
address or the list (since I can watch the archive).

Flightgear-devel mailing list

[Flightgear-devel] Re: Carb ice

2004-07-27 Thread Alex Perry
David mentioned:
 Carb icing is common on humid days in certain Continental engines such as 
 the one in the Cessna 150 and the old (pre-1967) 172, but it is very rare in 
 engines like the Lycoming O-320 (used in the Warrior and post-1967 Cessna 
 172's).  The warnings in the later 172 POH's about using carb heat at low 
 power are left over from the old Continental O-300 days -- the Warrior has 
 essentially the same engine, but my POH does not recommend carb heat for low 
 power operation unless I suspect actual icing.

I disagree about that ... I've had an O320 stutter on me due to carb ice.
At the last-but-one flyin I went to, they had two accidents.  The first
was due to poor crosswind skills and the second was a C172 with carb ice.

 David Megginson wrote:
  I don't think we should disable any systems, period, but we can put 
  users by default in situations where carb icing is unlikely (i.e. a 
  clear, dry day).

I think that is an excellent idea.  Treat the new pilot like someone
who is going to go on one of the 'taster' first student flight thingys.
No, David, not like _your_ first flight ... like mine, for example.  8-)

  Once you get into situations where carb icing is 
  likely, users are going to be dealing with other problems like reduced 
  visibility anyway.

Yeah, and if they haven't learned to do safe things routinely, such as
using carb heat, leaning and everything else, they'll have a short life.

Matthew mentioned:
 We lost a C150 last week to suspected carb ice.  The engine stopped dead 
 on base leg when the pilot (a recent PPL graduate) throttled down to 
 descend for landing.  The 'landing' appears to have been rather hard as 
 the 'plane is a write-off.  Thankfully he's OK...  I think my Vans RV-9 
 will have a diesel engine :-)

That's a point.  Once the engine stutters/quits due to carb ice,
you have to make it take a while for the ice to go away again.
... and it takes quite a while ...

Flightgear-devel mailing list

Re: [Flightgear-devel] Re: Carb ice

2004-07-27 Thread Alex Perry
From: David Megginson [EMAIL PROTECTED]
 Alex Perry wrote:
  That's a point.  Once the engine stutters/quits due to carb ice,
  you have to make it take a while for the ice to go away again.
  ... and it takes quite a while ...
 Once the engine quits, it's too late for carb heat, isn't it?

Not if you're quick ... and lucky.  If the engine wasn't originally heavily
leaned, then the reduction in airflow through the venturi will richen the
mixture early enough that the engine quits due to mixture before the opening
is completely blocked by the ice.  At that point, applying carb heat means
that the rotating prop is sucking warm air (which helps a bit), using full
throttle minimizes the braking effect of compression and keeps the prop
rotating as much as possible, and leaning the mixture avoids flooding it.

... but this does not reliably work, so you simply move the three
levers to those positions and immediately do the ABC for engine failure.
_Then_ you use the checklist, consider fiddling with the primer etc etc.
Of course, if the air filter ices up, applying carb heat fixes it quick!

If the engine runs rough, the EGT drops rapidly to the CHT ... and of course
when it stops then both quickly decay towards OAT due to the air cooling.
Anybody wanting to simulate should have fun guessing the intake temperature.

 I had my engine run rough once and suspected carb ice, but it smoothed out 
 the second I put on carb heat, so it obviously wasn't ice -- I was probably 
 just a little too lean.

Sounds likely.  It takes a while to burn significant ice deposits off.

A side point is that it is dangerous to fly heavily leaned beyond max RPM
in conditions where there is any chance of carb ice, even on fuel injected
engines.  There will be no indication of any icing problem until
the blockage is sufficient to return you past max RPM, to the rich side,
and then reduce the airflow still further.  It is then hard to melt off.

Flightgear-devel mailing list

Re: [Flightgear-devel] Some problems that I have ran into

2004-07-17 Thread Alex Perry
From: Ampere K. Hardraade [EMAIL PROTECTED]

 System spec:
 CPU: Intel(R) Pentium(R) 4 CPU 1.70 GHz
 Memory: 512MB
 Graphic card: Intel Corp. 82845G/GL[Brookdale-G]/GE Chipset Integrated 
 Graphics Device (rev01)(prog-if 00 [VGA])
 Sound card: Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 
 Audio Controller (rev 01)
 Operating System: Debian Linux Unstable 3.0
 Kernel: 2.6
 GUI: KDE 3.2.2
 Problem #1
 I am only able to run FlightGear once per login.  I am going to recompile 
 FlightGear and see how things go.

I'm running AMD64, ATI, Via, Debian, Testing, KDE.
I don't observe your problem #1 so I suspect some other interaction.

 Problem #2
 OpenAL gave me the following error:
 Initializing OpenAL sound manager
 open /dev/[sound/]dsp: Device or resource busy

Check your audio configuration for KDE; on my system it grabs /dev/dsp
to make desktop sounds such as the startup noise and then relinquishes
it sometime later.  If the desktop has not relinquished the soundcard,
FGFS is unable to get control of the device in order to do the audio.

 I have already included my login into the same group as /dev/dsp.  I have also 
 reinstalled OpenAL by apt.  The result is still the same.

On slower computers, you might want to log in using a plain xterm in order
to get the KDE program elements out of memory.  They tend to hang around
and steal video and processor resources ... and refuse to get swapped.

Curt:  Is the version of openal in Debian's unstable finally new enough ?

 Problem #3
 The morse code that was broadcast from KSFO only says 'SF'.  Is that normal?  
 Shouldn't it say 'SFO'?

Depends which radio is generating the morse,
and what the callsign of the associated transmitter is.
I don't know what the default configuration is, offhand.

... hope that helps ...

Flightgear-devel mailing list

[Flightgear-devel] Talk on FGFS at UKUUG's annual conference

2004-07-17 Thread Alex Perry
Curt:  Please add to the Events page.  It is not yet clear _when_
the FGFS talk and demo will occur during the three day conference.
Leeds, England
August 6 thru August 8, 2004.

Linux 2004

A wide cross-section of the Linux community will gather in Leeds
this August for the annual UKUUG Linux Technical Conference.
It's a great way to broaden your knowledge and keep up-to-date
with what's happening in the world of linux.
This low-cost event is for anyone with a serious interest in linux
including systems administrators, linux professionals, developers and
enthusiasts from companies and linux user groups throughout the UK and beyond.

The conference starts around 9.45am on Friday, 6th August,
continues with a full day of presentations on Saturday, 7th August,
and finishes about 4.30 p.m. on Sunday, 8th August.
Tutorials will be held on Thursday, 5th August.

Building upon previous years' events,
this promises to be a very successful conference.
There should be plenty of time for informal discussions.
There will be table-top displays on Friday and Saturday, and,
new this year, a keysigning session.
Places are limited, so early booking is advised.
Please recommend the event to your friends and colleagues
and download our Conference booklet (PDF). 

The FlightGear Flight Simulator

FlightGear is a superb open source flight simulation project,
offering the pilot's view of the cockpit and of the 3D scenery.
The simulator pilot uses joystick, keyboard, yoke, pedals and other
input devices to fly any of dozens of realistic aircraft around the world.

In order to run well on a commodity computer system,
XML files determine which software modules are to be used
and configure each so they integrate as the desired simulation.
Individual files for aircraft, engines, instruments
and other common components enables the simulation to reuse these files
much like aircraft manufacturers reuse engines and instruments.

Connections between software modules are resolved to objects
using a hierarchical namespace that is common to code and XML.
The same namespace is exposed as a network service,
enabling external software to monitor and modify the simulator state.

This talk introduces the scientific and engineering challenges
and presents some work currently in progress. 

Flightgear-devel mailing list

[Flightgear-devel] FGFS - latest CVS summary - no news

2004-07-17 Thread Alex Perry
Today's CVS checkout of: OpenAL, PLIB, SimGear, FlightGear and Base package.
On my usual laptop, everything works fine as normal in both configurations:
Config 1= fglrx driver for ATI9600, Kernel 2.4, Debian Testing, 32 bit x86
Config 2= xfree86 unaccelerated, Kernel 2.6, Debian Unstable, pure 64 bit

I'd observe that it would be nice to turn _off_ texturing of the models,
both the aircraft I'm sitting in and the AI aircraft around the airport,
and turn _on_ texturing for the head up display (needed for PLIB fonts).
That would make it much easier to fly with unaccelerated 3D drivers...

Flightgear-devel mailing list

[Flightgear-devel] Re: Next release of FlightGear

2004-07-17 Thread Alex Perry
 On July 17, 2004 04:54 pm, Erik Hofman wrote:
  This is the penalty for those who want eye-candy. If specular
  highlighting is supported it will be enabled an make FlightGear slower.
From: Ampere K. Hardraade [EMAIL PROTECTED]
 Please tell me that you don't play FlightGear in wireframe mode. =P

Thanks to ATI not releasing 64 bit drivers, or data for open source support,
yes I do run FGFS in wireframe mode.  But, I don't have a sweet eye.  8-)
Bear in mind that my simulation needs may be a bit different from yours,
since I personally mostly use FGFS for practicing in IMC for approaches.

Of course, when demonstrating to other people, I run with full graphics.

Flightgear-devel mailing list

[Flightgear-devel] Re: Laptop

2004-07-12 Thread Alex Perry
From: Chris Horler [EMAIL PROTECTED]
 Are the problems you're experiencing with 
 the drivers only experience on a 64 bit system?

No.  The driver is completely unusable in 64 bit mode.  In 32 bit mode,
it works fine providing you don't try to use the most recent kernel.
The 2.4.x series is fine, as is 2.6.5, but the more recent ones aren't.

 What are the power saving features like for this driver?  Can you configure 
 anything worthwhile?

I haven't tried.  It doesn't appear to have any ACPI support, for example.

Flightgear-devel mailing list

[Flightgear-devel] Re: Laptop

2004-07-11 Thread Alex Perry
 Chris Horler wrote:
 I'm going to buy a laptop very soon (pay day approaches).

You specifically need to decide whether weight is a factor for you:
(a) a desk top replacement, will weigh about 8 lb ... a luggable
(b) a lightweight powersaver, will weigh about 4 lb ... no gaming

I'm using an AMD64 laptop, works fine.  It's a desk top replacement and
achieves 2 hours battery at full speed, over 3 hours when speed throttled.
Bear in mind that, if you have a friend whose laptop takes the same model
of battery, you can double the available uptime when travelling by 
borrowing the second battery from each other.  Don't travel together!

You may have trouble buying a battery ... without a laptop included;
that's what happened to me.  The limit on the number of computers that
the manufacturer could sell was the number of batteries available.
They'd rather sell full laptops than just the battery, of course.

From: Curtis L. Olson [EMAIL PROTECTED]
 I've never bought a loptop for myself, but when I look, the first thing 
 I try to figure out is what video subsystem comes with it and how much 
 video ram.  I know I can get GeForce based laptops to run well.  I 
 assume that ATI based laptops also work well, especially with windows.  
 But if you find some other random video chipset that you've never heard 
 of before, you might do well to skip it ... at least if you plan to do 

Try booting the floppy with knoppix, if they'll let you, and then do
lspci and lspci -n to get the information for a careful online search.
The labels on the front (and in the Windows System Devices list) are
often misleading due to marketing factors that create odd names.

From: Chris Horler [EMAIL PROTECTED]
 ATI 9700 M11 128MB ram.
 ATI's driver says they support upto the 9600,

My laptop has the 9600, can't help you on the support level for 9700.
If you visit the ATI discussion boards, you'll find that ATI have been
playing marketing name games with the recently released chip designs.

Bear in mind that you will only get accelerated 3D when you are
(a) running the binary-only fglrx driver from ATI
(b) also running the kernel module from ATI (doesn't work with 2.6.7)
(c) using both a 32 bit userspace and a 32 bit only kernel
The last constraint is only a factor if you have an AMD64 processor
and are running linux (since Windows doesn't do 64 bit support yet).

Flightgear-devel mailing list

[Flightgear-devel] Re: Real Flight PLayback ?

2004-07-09 Thread Alex Perry
 If you *really* want the attitude information, your best bet is to buy one 
 of the new, portable backup gyros like this:
 They're not cheap, but they'd be an order of magnitude cheaper than trying 
 to set something up to interface with the panel gyros.

I'd turn the problem around and assume you're a reasonably competent pilot
who flies coordinated _and_ doesn't use flaps (so the wing chord is fixed).
While not strictly true, the assumption is close enough for playback.
You can infer AOA from airspeed and add this to the flight path angle.
Similarly, you can use airspeed and radius to infer roll angle.

Flightgear-devel mailing list

[Flightgear-devel] status of aircraft carrier

2004-07-05 Thread Alex Perry
Several years ago, we added the aircraft carrier into the static scenery
so people could land and take off ... but it didn't move or have effects
for relative wind, deck motion or the burble around tail and superstructure.
Is there a summary of its status and maybe recent screenshots somewhere ?

I'd like to include some information on it
in the presentation for UKUUG in August.

Flightgear-devel mailing list

Re: [Flightgear-devel] domain name

2004-07-03 Thread Alex Perry
From: Chris Metzler [EMAIL PROTECTED]
 Martin Spott [EMAIL PROTECTED] wrote:
 Ampere K. Hardraade wrote:
 On June 28, 2004 05:32 pm, Curtis L. Olson wrote:
  I have just reregistered the domain name for another
  I sense someone is asking for a donation... lol
  PayPal !?  ;-)
 This is just what I was thinking.  Lots of open source projects
 have set up PayPal accounts for collecting donations.

We have a sourceforge account for the project, and SF offers
some kind of built in capability for accepting donations.
I don't know how it works and have never used it,
but it might be worth investigating sometime in the next 11 months.

Flightgear-devel mailing list

[Flightgear-devel] Re: radio towers - and buildings

2004-06-15 Thread Alex Perry
 I recently
 modelled a 40-story building I wanted to put in its real-life location;
 the latlong I'd dug up for the building didn't match any of the antenna
 locations, so I didn't know what to substitute for.
 If you live in the area you could drive over with a gps and survey the 
 building yourself ... drive around the block a couple times and record 
 the track?  Gps's don't work well in down town environments because the 
 satellites are often obstructured, but maybe you can get lucky enough to 
 get a decent idea of the location.

Possibly easier, for most US cities, is taking advantage of the fact that
the roads are on a predictable grid.  You just need the GPS coordinates of
three intersections (four if you want to be paranoid for the projection)
and you can infer the location of anything within the grid from the address.
The nice thing about this is (a) someone might already have the coordinates
for some addresses online (many stores do, on their websites, for example)
and (b) someone you know might live _somewhere_ in the grid and own a GPS
or even (c) around the perimeter of the grid, buildings are much smaller.

Flightgear-devel mailing list

[Flightgear-devel] Re: RFD: default weather

2004-06-15 Thread Alex Perry
On Tuesday 15 June 2004 19:55, Curtis L. Olson wrote:
 I would like to propose that we set the default weather to zero winds,
 zero turbulence, and maybe (?) zero clouds.

I propose the default weather be ...

1. Low altitudes below 6k' have a stable airmass with an inversion
layer, which is a common state in the bay area and southern CA.
2. Medium altitudes below 15k' have a faster lapse rate and instability.
3. Jet stream related effects at high altitude (just for the jets).

* zero wind and turbulence, clear with 6SM visibility, below 3k'
* gradual transition from 3k' to 3k5'
* 20 knot onshore, no turbulence, clear, 30SM visibility 3k5' to 6k'
* 20 knot onshore, light turbulence, scattered cumulus, to 15k'
* ramp from 20 knot to 50 knot from 15k' to 20k' in moderate turbulence
* Scattered layer (the way we usually do it) at 28k'
* 50 knot onshore, no turbulence above 20k'

Benefit is that new users get to experience the magic of climbing
out of the inversion layer and seeing the hills in the distance.
Shows off most of our features and jets something to play with.

Flightgear-devel mailing list

[Flightgear-devel] Re: 64 bit compile speed

2004-06-15 Thread Alex Perry
Compiling FlightGear source (after make clean) on a M6805 laptop:
For pure 32-bit it took 00:10:03 using Debian Sarge
For pure 64-bit it took 00:10:10 using Debian Sid
The use of two Debian versions probably led to the timing difference.

Flightgear-devel mailing list

[Flightgear-devel] 64 bit compile speed

2004-06-14 Thread Alex Perry
Don't know offhand.  I personally haven't built under 64 bit,
since FGFS was prepackaged by Debian for AMD64 and I'm lazy,
and my 32 bit developer build is scripted - so I never wait.
I'll measure it with make clean; cvs update -APd; time make
later on today sometime, when the machine is not in use.
As a side note, FGFS's dependency tree is fairly reliable,
so you can use make -j on a SMP machine or mosix cluster.

From: Giles Robertson [EMAIL PROTECTED]
 How long does FG take to compile with that spec?

 From: Alex Perry [mailto:[EMAIL PROTECTED] 
 e-Machines M6805. The next up model in the series is the M6807
 with a better optical drive. They now have a M6809 which has a
 3200+ processor instead of a 3000+.

Flightgear-devel mailing list

[Flightgear-devel] Re: FlightGear runs cleanly on AMD64 in 64 bit mode

2004-06-13 Thread Alex Perry
  Alex Perry wrote:
   The framerate was just over 1fps, but that's because the laptop has
   the ATI 9600 chipset so I have to choose between the unaccelerated
   open source driver or the 32-bit only accelerated closed source

From Arnt Karlsen [EMAIL PROTECTED]:
 ..which laptop and which X? 

e-Machines M6805
The next up model in the series is the M6807 with a better optical drive.
They now have a M6809 which has a 3200+ processor instead of a 3000+.

Xfree86 version on both the 32-bit and the 64-bit chroots.

 How does 32- and 64-bit glxgears compare,
 native screen (no resizing),

32-bit ATI driver, kernelmod, userspace: 1833 fps
32-bit ATI driver, no krnmod, userspace: 93 fps
32-bit ATI driver with 64-bit userspace: 96 fps
64-bit Open Source driver and userspace: 720 fps

 full screen and same as FG?

32-bit ATI driver, kernelmod, userspace: 174 fps
32-bit ATI driver, no krnmod, userspace: 8.0 fps
32-bit ATI driver with 64-bit userspace: 8.5 fps
64-bit Open Source driver and userspace: 148 fps

   driver from ATI. I used the accelerated driver, running in a chroot
   on a biarch kernel, but ATI's kernel module doesn't compile for
   64-bit so I couldn't use it.
 ..does ATI know?

I put a note on their support site requesting a 64 bit clean fglrx.
The numbers above show why the lack of that kernel module matters.

Flightgear-devel mailing list

[Flightgear-devel] FlightGear runs cleanly on AMD64 in 64 bit mode

2004-06-12 Thread Alex Perry
I just noticed that the Debian autobuilder had quietly gone off and made
AMD64 packages to run FlightGear 0.9.4 and all its dependencies in 64-bit.
I did sudo apt-get install flightgear and fgfs ... and it ran fine.

The framerate was just over 1fps, but that's because the laptop has the
ATI 9600 chipset so I have to choose between the unaccelerated open source
driver or the 32-bit only accelerated closed source driver from ATI.
I used the accelerated driver, running in a chroot on a biarch kernel,
but ATI's kernel module doesn't compile for 64-bit so I couldn't use it.

Just thought you'd like to know ... 8-)

Flightgear-devel mailing list

[Flightgear-devel] FlightGear BOF, Boston, June 30, 7pm-9pm

2004-06-10 Thread Alex Perry
For people who might be in Boston (MA, USA) at the end of June:

There will be a FlightGear Birds-Of-a-Feather (BOF) session [1] on
Wednesday June 30 2004, 7pm to 9pm ... and I encourage you to come.
There is no charge to attend the BOFs, but you need to register [2]
if you're not already registered to attend the conference that day.

The Usenix conference [3] will have a FlightGear talk [4]
in the UseLinux stream on Thursday July 1 2004 around 10:30 am.


Flightgear-devel mailing list

[Flightgear-devel] Re: DME bias question

2004-06-09 Thread Alex Perry
From: Curtis L. Olson [EMAIL PROTECTED]
 Recently I added support for adjusting the DME readout based on an 
 optional per transmitter bias that is part of Robin's nav data.
 [...] so it reads 0.00 at the touch down point.

It is only in specific countries where the goal is to have it read zero.
More generally, the idea is to have it read the same for multiple runways
so that it is easier for pilots to fly various approaches w/out surprises.

Curt continued:
 My question is, in real life, what happens to the dme readout when you 
 get inside of the bias range. 

It is instrument specific as to what it does when the computed distance goes
below zero.  Some of them just report zero distance, while others go negative.
Often, the ones that clamp at zero will still be showing a non-zero speed.

From: David Culp [EMAIL PROTECTED]
 I've never seen a negative DME, and I don't think it's possible to see one.

The physical implementation of the bias is that the transmitter on the
ground responds to the incoming pulse slightly sooner than it 'should'
so that the speed of light round trip time is reported as a bit shorter.
It is equally feasible to respond slightly later than the standard
specifies, so that the reported distance is somewhat on the long side.
Thus, the bias value in the database of DME stations can have either sign.

From: David Megginson [EMAIL PROTECTED]
 I've never heard of DME bias either -- that's not to say that it does not 
 exist, but it's certainly not common.

I know at least one of the London airports does this, for example.

From: Curtis L. Olson [EMAIL PROTECTED]
 All the approaches at KLAX have a 1 or 2 nm bias for the DME. Like you 
 say, there is no *requirement* for this, but there are installations 
 that have a bias set up.

Yes, I believe, without having the plate handy, that LAX does this.

As I recall, the reason is that they use the same ILS frequency for
the two ends of each runway.  Since the ILS frequency is associated
with the DME channel, they either make life hard for the crews or
they use the same DME channel for both ends.  To use the same channel,
you either build two transmitters or build one with a bias applied.
Since LAX have four runways with this issue, bias saves a lot of money.

Flightgear-devel mailing list

[Flightgear-devel] Deb-a-day reference to FGFS

2004-05-26 Thread Alex Perry

Tuesday, May 25th, 2004
flightgear - Flight Gear Flight Simulator
This thing is huge. This package comes to our attention from Paul, a student at 
Griffith University in Australia. Paul says that this very large OpenGL flight 
simulator requires eleven CDROMs worth of data to deliver all of the world scenery.

Check out the package dependencies: libc6, libgcc1, libglut3, libstdc++5, plib1c102, 
simgear0, libgl1, libglu1, xlibs, zlib1g, and fgfs-base. That's a lot of heavy duty 
stuff for someone like me who runs headless Debian servers for living.

The upstream source for this package can be found on SourceForge. Note that the 
package description doesn't really help with making the decision on whether you'll 
want to install this or not:

Flight Gear is a free and highly sophisticated flight simulator.
This package contains the runtime binaries.

But checkout the upstream source for pretty pictures.
I'm going to try it out on Mac OS X myself.
More information on this package can be found on the Debian web site.

Flightgear-devel mailing list

Re: [Flightgear-devel] FlightGear news letter

2004-05-03 Thread Alex Perry
On Sunday 02 May 2004 17:20, Jonathan Richards wrote:
 Firstly, a title.

Runway behind you ... one of the three classic things, useless to a pilot

NewsGear ... in line with Curt's naming pattern

The shouting wind ... from High Flight (better for the mailing list tho)

Joystick and Pedal ... our version of title - Stick and Rudder

Flight Gear Checkout ... pun references CVS and also flight testing

Flightgear-devel mailing list

[Flightgear-devel] Impossible to run without sound?

2004-04-26 Thread Alex Perry
From: Frederic Bouvier [EMAIL PROTECTED]
  [...]  Is there a way to disable sound 
  support (besides the runtime parameter)? I would 
  like to know this, since I did not dive into the 
  OpenAl stuff yet, and really dont use sound anyway..
 I don't thing it is possible. Setting up FG with OpenAL
 is not a big deal though. I posted the stuff involved 
 2 days ago.

Sure, there's no _technical_ problem in installing OpenAL;
providing you don't mind upgrading to experimental
libraries (recent CVS, little testing) on a stable machine.
FGFS is disappearing from all but one of my computers and,
on the remaining one, it occupies a ChRoot for segregation.

A configure-time switch that eliminates the build dependency
would also be convenient because I normally run FGFS silent.
(I'm not suggesting that the switch to OpenAL was a bad idea)

Flightgear-devel mailing list

[Flightgear-devel] FlightGear talk, San Diego CA, tonight

2004-04-15 Thread Alex Perry
From: David M. Cook [EMAIL PROTECTED]
The next meeting of the SAN Diego PYThonistas will this Thursday, April 15.
Doors open at 6:30PM, and the meeting starts at 7pm at

San Diego County Office of Education
Rm. 306
6401 Linda Vista Road
San Diego, CA 92111

See our website for a map:

Alex Perry will be giving a talk on Flightgear and Python:

The FlightGear Flight Simulator and its Python Class

Alexander Perry a l e x . p e r r y @ i e e e . o r g
April 15th

FlightGear is an advanced open source flight simulation project,
offering the pilot's view of the cockpit and of the 3D scenery.
The simulator pilot uses joystick, keyboard and other input devices
to fly any of dozens of realistic aircraft models around the world.

The FlightGear python class offers scripted access into the running
simulation across the network, enabling a flight instructor to
adjust settings in a student pilot's flight training environment.
Both the simulator and the class are portable and platform neutral
so either can be run on Linux, MacOS, SGI or Windows systems.

This talk will explain how the python class achieves its goals,
show flightgear's capabilities for simulating light aircraft,
and then demonstrate the python making changes to the configuration.

Additional information:

Flightgear-devel mailing list

[Flightgear-devel] segfaults ?

2004-04-12 Thread Alex Perry
Having just rebuilt from scratch, I'm consistently getting segfaults
so the display never gets beyond the splash screen.  Is there something
I should know about ?  Debian/Testing with XFree 4.3 - PLIB examples ok.

Flightgear-devel mailing list

Re: [Flightgear-devel] Bug? [Was: Pre-Releases and Releases]

2004-03-28 Thread Alex Perry
From: Jon Berndt [EMAIL PROTECTED]
 [...]. This resulted in a little tumble, but when I came out of it and
 regained level flight, the ADI showed I had a left roll of about 40 degrees,
 but the visual scene (and more importantly for me) the FDM property that
 drives it showed  a roll angle of about -4 degrees.

Jon, as commented elsewhere, that is a feature of the actual aircraft
instrument and is intentionally present because is a source of fatal

An example: Imagine walking out the back door of your house, to your
grass strip, get in the plane, start the engine, taxi 100ft to the
end of the runway, take off, turn on the autopilot, enter the overcast,
start calling ATC to confirm time-off for the IFR departure, get hit
by a gust, see a pitch/roll upset, the autopilot corrects it for you,
die (unexpectedly).

The gyros still hadn't spun up, but the autopilot didn't know about that
and acted on the assumed correct data.  Had you been flying manually,
the instrument scan cross check should have noticed the inconsistency among
the gyro and non-gyro instruments and you would probably have survived.

But, speaking to you specifically and your role as an FDM author,
that's one of the reason why the HUD shows the raw uncooked data.
It lets you find out what's _really_ happening in your models.

Flightgear-devel mailing list

Re: [Flightgear-devel] Spinning gyro numeric model

2004-03-28 Thread Alex Perry
From: Roy Vegard Ovesen [EMAIL PROTECTED]
 I've created a new model for the spinning gyro (Instrumentation/gyro.*xx). 
 Now, I know that the existing gyro model and heading indicator and attitude 
 indicator work great and that some might think that I am trying to fix 
 something that is already working. I would argue that I am trying to improve 
 on something that is already working ;-). But if nobody else share my point 
 of view, I might abandon the idea.

My objections to people fiddling with the gyro model is because they usually
want to take out the mechanical errors so it becomes a perfect instrument.
From your description, you seem to be trying to make it a more accurate
simulation of real life, which is certainly fine by me.  Go for it!

  * The gyro is driven by a torque. It is slowed down by bearing
  * friction and air friction.
  * The gyro disk is defined by radius [m], width [m], and 
  * material density [kg/m?]. The disk is a solid cylinder.

Don't assume that the comments in the file, which were originally by me
and then modified by David to try and make sense of what my code did,
bear any relation to the actual engineering inside such a gyro unit.
It doesn't ... it is simply a description of the simplified physical
model that the code was written to implement.  I created that model
because it would show most of the errors, not because it is correct.

If you'd like to start from first principles and do a fully correct model,
I suggest you contact one of the manufacturers and ask for engineering data.
If you don't know who or how to go about doing that, let me know and I'll
try to arrange it for you.

Flightgear-devel mailing list

[Flightgear-devel] Old complaints about instability?

2004-03-27 Thread Alex Perry
I was just rebuilding FGFS's binary when I noticed these warnings.
Depending on what your compiler does, the runtime effect could be bad.
Someone was mentioning having occasional crashes.

source='tower.cxx' object='tower.o' libtool=no \
depfile='.deps/tower.Po' tmpdepfile='.deps/tower.TPo' \
depmode=gcc /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src  
-I/usr/X11R6/include  -g -O2 -D_REENTRANT -c -o tower.o `test -f tower.cxx || echo 
tower.cxx: In method `void FGTower::CheckCircuitList(double)':
tower.cxx:901: warning: `double' used for argument 1 of `abs(int)'
tower.cxx:934: warning: `double' used for argument 1 of `abs(int)'
tower.cxx:944: warning: `double' used for argument 1 of `abs(int)'
tower.cxx:954: warning: `double' used for argument 1 of `abs(int)'

Flightgear-devel mailing list

[Flightgear-devel] clouds3d broken ?

2004-03-25 Thread Alex Perry
I tried doing --enable-clouds3d and FGFS exits with a trap.
What am I supposed to do ?  The code doesn't look like it's disabled.

Flightgear-devel mailing list

[Flightgear-devel] applications for FGFS

2004-03-25 Thread Alex Perry
I've been looking for some new FGFS applications, compared to two years ago,
but none seem to be public ... as far as the website is concerned anyway.
Do any of you know of some that you just haven't mentioned on the list yet ?

Flightgear-devel mailing list

Re: [Flightgear-devel] Official 0.9.4 release???

2004-03-24 Thread Alex Perry
On Wed, 24 Mar 2004, Curtis L. Olson wrote:
 I'm seeing a last minute flurry of people trying to get final model
 tweaks into the base package (which is good--great work guys![1]), but
 haven't heard any other complaints about the pre2 release.  Are we
 getting pretty close to making this release official so we can get on
 with other stuff?

Well, it _compiles_ on the machine without 3D, and on the machine with
3D I can't get PLIB to work because of the previously-mentioned problem.
I may have time to do the manual fixup of the versions this evening,
in which case I can formally try out pre2 tomorrow.  But not before.
I agree with the others; you should keep pre2 until Sunday evening.

Flightgear-devel mailing list

[Flightgear-devel] gl-info suffers from undefined references when linking

2004-03-23 Thread Alex Perry
gcc  -g -O2  -L/usr/X11R6/lib -o gl-info  gl-info.o -lGLU -lGL -lXmu -lXt -lSM -lICE 
-lXi -lXext -lX11 -ldl -lm  -lglut 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
collect2: ld returned 1 exit status
make: *** [gl-info] Error 1

Flightgear-devel mailing list

[Flightgear-devel] The glX*SGIX are also a problem for fgfs binary

2004-03-23 Thread Alex Perry
g++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT  -L/usr/X11R6/lib -o 
fgfs  bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a 
../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a 
../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a 
../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a 
../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a 
../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a 
../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a 
../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a 
../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a 
../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a 
../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a 
../../src/Scripting/libScripting.a ../../src/Sound/libSound.a 
../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a 
../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a 
../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound 
-lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath 
-lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound 
-lsgserial -lsgstructure -lsgenvironment -lsgthreads -lpthread  -lplibpu -lplibfnt 
-lplibjs -lplibnet -lplibssg -lplibsg -lplibul  -lz -lGLU -lGL -lXmu -lXt -lSM -lICE 
-lXi -lXext -lX11 -ldl -lm  -lglut -lGLU -lGL -lplibsl -lplibsm 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../ undefined reference to 
collect2: ld returned 1 exit status
make: *** [fgfs] Error 1

Flightgear-devel mailing list

[Flightgear-devel] Re: gl-info suffers from undefined references

2004-03-23 Thread Alex Perry
From: Alex Perry [EMAIL PROTECTED]
 undefined reference to `glXChannelRectSGIX'

Never mind.  It looks like Debian Testing has managed to temporarily
have insufficient dependency constraints.  It is currently possible
to have incompatible versions of glut and glX libraries installed.
Other Debian Testing users might avoid doing an upgrade for a few days
until packages with correct version requirements have been propagated.

Flightgear-devel mailing list

[Flightgear-devel] pretty screenshots with clouds

2004-03-22 Thread Alex Perry
All the recent stuff in the gallery is for nice, cloudless skies.
Has anybody got a screenshot that shows off our cloud support well ?
If not, I'll try to set up something picturesque in the morning.

PS.  I _don't_ want a picture of the sky bowl infelicities.  8-)

Flightgear-devel mailing list

[Flightgear-devel] Minor - fgadmin

2004-03-20 Thread Alex Perry
Is the utils/fgadmin supposed to be portable selfcontained code?
It references a bunch of header files that are not in its own tree
and are not part of FLTK version 1.0.11-5 that's in Debian Stable.
Should there be a version number check inserted into configure?

source='fgadmin.cxx' object='fgadmin.o' libtool=no \
depfile='.deps/fgadmin.Po' tmpdepfile='.deps/fgadmin.TPo' \
depmode=gcc /bin/sh ../../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c -o fgadmin.o \
`test -f fgadmin.cxx || echo './'`fgadmin.cxx
In file included from fgadmin.cxx:3:
fgadmin.h:7: FL/Fl_Preferences.H: No such file or directory
In file included from fgadmin.cxx:3:
fgadmin.h:13: FL/Fl_Check_Browser.H: No such file or directory
fgadmin.h:14: FL/Fl_Progress.H: No such file or directory

Flightgear-devel mailing list

[Flightgear-devel] RE: [Plib-devel] new Release

2004-03-19 Thread Alex Perry
From: Norman Vine [EMAIL PROTECTED]
 Steve Baker writes:
  I just updated the current tarball at SourceForge

 I will manually force a tarball update if and when I see any CVS commit
 messages between now and the release so that the tarball is truely current.

I've been tracking PLIB CVS as well as the FGFS/SG CVS for the last
few days on all my machines and had no trouble between them all.

Flightgear-devel mailing list

[Flightgear-devel] Re: Removing WeatherCM

2004-03-16 Thread Alex Perry
Orthonormalize wrote:
 2) there seems to be a lot of code that is in transition, like the
 WeatherCM, Scripting modules. i was only able to compile after deleting

WeatherCM and the scripting code is working and has been stable for several
years.  I think it is wrong to suggest that powerful modules that have not
given problems to dozens of other people should be removed because one
person finds them to be an inconvenience in trying to start development.

Flightgear-devel mailing list

[Flightgear-devel] Problems building - multiplatform

2004-03-16 Thread Alex Perry
Orthonormalize wrote:
 -my solution: prebuild a few Lowest Common Denominator configurations
 (say lynux,windows and mac) and then call  it a day.

A key advantage of FlightGear is that it _does_ support high end platforms.
What's the point in having a simulator that only runs on low end systems ?
If someone is doing a professional research installation, they should be
able to use a cluster (as some do) or high end UNIX (tm) operating systems
(as others do) and not be summarily kicked out in favor of the home users.

From: Curtis L. Olson [EMAIL PROTECTED]
 -  There are a few things that are hard for us to control.
 Glut is not well supported on all versions of RedHat.

The PLIB team is, of course, trying to eliminate that dependency.

From: Orthonormalize [EMAIL PROTECTED]
 honestly have you ever tried building this thing from scratch?

Personally?  Last week, on an AMD64 laptop that's running Debian's Sarge.

The code downloaded and compiled from scratch (with PLIB and TerraGear)
in about 15 minutes.  Although that would run with software rendering,
it took me another hour to get ATI drivers and bring up accelerated 3D.
I'll be showing it at a San Diego Python Users Group meeting next month.

It also builds using the Debian pure 64 bit environment.  No FG problems,
thanks to the painstaking efforts of Erik et al, but I'm having trouble
with numeric libraries (including Mesa) so the simulator fails to run.

From: Orthonormalize [EMAIL PROTECTED]
 again i'm not
 trying to be harsh but the build process is really
 quite complicated and i haven't succeeded yet.

Bear in mind that is quite hard to get a Windows operating system to
transition into a development environment, because the basic install
does not offer any developer tools or header files for its libraries.
As a result, when you add all of that stuff on, independently of the
underlying operating system, it is very easy to make tiny mistakes.

Others have commented that you are using a different combination
of add-on Windows developer toolchains than the other developers.
That is of course your right, especially in an open source project,
but please don't be surprised when you experience unusual problems.

While most Linux based distributions also omit developer tools from
a basic install, they differ by making it trivial to add them later.

I would _strongly_ recommend that, as soon as you _think_ you have
PLIB built and installed right, you try to compile and run _all_
example programs that are provided by the PLIB project developers.
They should each work out of the box and provide nice little demos.
If they don't, there is no point trying to do SimGear or FlightGear
because they won't work either and the problems will be more subtle.

Hope that helps ...

Flightgear-devel mailing list

Re: [Flightgear-devel] Training costs

2004-03-15 Thread Alex Perry
From: Martin Spott [EMAIL PROTECTED]
 David Megginson wrote:
 Fuel costs don't help, obviously, but they're a relatively small percentage 
 of the cost of operating a plane (i.e. doubling the fuel cost might increase  the 
 cost of flying by 25%).  Is maintenance more expensive?  Is it taxation 
 and government fees?  Obviously, the money's not going into the equipment 
 they rent you.
 Maintenance _is_ expensive, because aircraft used for commercial
 training (not in a flight club) need to have commercial maintenance.
 Another part is fuel cost, because we're supposed to pay twice as much
 in Europe compared to North America.
 And - last but not least - the owner of an aircraft probably needs to
 pay the rates to his bank   you need some sort of amortization.
  At the Ottawa Flying Club, the 150's that most people train in do not have 
  DME, [...]
 The 150 that I fly most of the time doesn't even have an artificial
 horizon  :-)

For the San Diego rental market, where a non-modern non-upgraded IFR C172
(eg 160 hp, N series, dual NAV/COM, ILS/DME) rents for about $1/minute,
that cost splits into four equal $0.25/minute components for the following:
* Fuel (including fuel taxes), which is about $1/gal more than car fuel;
* Insurance (minimum hull and third party liability);
* Maintenance (airframe, engine and avionics only), includes owner repairs;
* Overhead (parking, washing, administration, etc, etc).

You're welcome to draw your own conclusions from those numbers.  If the
facility's accident rate, or the airport accident rate, is equal to or
greater than the national average, the insurance cost basically doubles.
Note that depreciation is not listed, since older C172s do not lose value,
and there is no allowance in those numbers for any profit for the owner.

Flightgear-devel mailing list

[Flightgear-devel] python - usable / presentable ?

2004-03-11 Thread Alex Perry
I haven't heard much talk about the python class wrapper for FGFS's
telnet remote access to the property tree.  The scripting directory
in CVS appears to have been untouched for the last couple of years.
Is it still a stable bit of code whose capabilities we promote ?

I'm asking because I've been invited to give a talk to the local
Python users group (maybe as a joint meeting with one of the LUGs).
However, I don't want to give a talk on something we don't use.

It occurred to me that the is a neat example of the
power of Python in allowing easy encapsulation of something that
wasn't originally designed with programmatic use in mind.

Comments ?
Does anyone have neat .py files other than the ones already in CVS ?
Has someone already given a talk like this, that I could build on ?
How many simultaneous users can connect to one FGFS using telnet ?


Flightgear-devel mailing list

[Flightgear-devel] FlightGear talk at UseLinux, Boston, July 2004

2004-03-06 Thread Alex Perry
Great news!
Usenix have accepted my abstract so I'm going to write the talk
and the paper over the next few weeks.

 Title: The FlightGear Flight Simulator
 Author(s): Alexander R Perry, PAMurray
 FlightGear has come a long way since first
 being showcased at LinuxWorld in San Jose.
 This talk provides an introduction to FGFS,
 an open source multiplatform flight simulator,
 and reviews the recent advances and challenges being faced.

I hope to promote interest in FGFS among those unfamiliar with it;
those Usenix attendees that haven't been to LinuxWorld, LinuxTag,
OSCon or one of the other events at which we had a booth or talk.
Also, for people who've not followed its progress in recent years,
I plan to present selected new features and practical improvements.

Suggestions for specific topics, as well as screenshots and photos,
will enable me to structure the talk to fairly represent the project.


Flightgear-devel mailing list

[Flightgear-devel] Data logging - IEEE 1451 standard

2004-02-19 Thread Alex Perry
The IEEE smart sensor standard is currently being updated from the
previous release, including the networked sensor array stuff that
is intended for the likes of Boeing when performing flight testing.
It occurs to me that the people who are interested in monitoring the
FDM behavior (i.e. the JSB team) and/or the simulation operations
(i.e. the property and network support team) might want to be involved.

I can see benefits in having the simulator be accessible using the
same network tools as are used to monitor real aircraft and factories,
because it lets us use the same data logging and analysis software.  and probably follow the links for .3
to learn more about their approach.  The websites are out of date.

There is an annual show, held in Anaheim California last year and
will be Detroit Michigan June this year,
which has a free presentation area where 1451 stuff is shown off.
Showing off the simultaneous logging of real sensors and simulation
output demonstrates the power of 1451 and is a free plug for FGFS.
I don't know where they're planning to hold the 2005 event tho.

Flightgear-devel mailing list

[Flightgear-devel] [Fwd: Planning Community Based FOSS Event in NYC] (fwd)

2004-02-07 Thread Alex Perry
Put onto the FGFS list in case east coast FGFS people are interested.

Subject: [Fwd: Planning Community Based FOSS Event in NYC]
From: Joe Phillips [EMAIL PROTECTED]
To: Debian Events NA list [EMAIL PROTECTED]
Date: 07 Feb 2004 13:05:02 -0500

 Subject: scosug-wheel: Planning Community Based FOSS Event in NYC
 Date: 04 Feb 2004 20:40:59 -0800
 This letter is to inform you and your group's members about current
 plans to try and organize a community based replacement for LinuxWorld
 in NYC.  This community driven effort is being organized in NYC and will
 consist of trying to create annual regional FOSS event somewhat
 analogous to LinuxTag in Germany, with both speaker tracks that are
 fully open to the public and drawn from the community at large, and
 exhibit space for both commercial and non-commercial entities to use.
 Currently, we are asking for those interested in participating in this
 effort to appoint two delegates.  These delegates will meet in NYC on
 Sunday, February 8th, 2004 (see details below) to elect an event
 committee.  Each delegate so designated will be given one vote.  The
 event committee so chosen will then be empowered to plan and organize
 this event, currently planned for the summer of 2005.
 By having delegates from interested parties choose to select the event
 committee, it is hoped to have a committee that can count on broad
 community support and legitimacy for their efforts, for working with
 corporate sponsors where nessisary, etc.
 We appreciate your time and patience in this effort.  Any questions can
 be referred to Lyn Ohira [EMAIL PROTECTED]
 David Sugar
 Lyn Ohira
 Meeting Details:
 Time: Noon
 Date: Sunday Feb. 8th
 Place: The New Yorker Hotel, room 1560.
 The New Yorker is between 34th
   and 35th Streets on 8th Avenue.
 Location Details:
 New Yorker Hotel
 481 8th Ave New York, NY
 Fallback Meeting Location:
 Three Jewels Outreach Ctr
 211 E 5th St New York, NY

Flightgear-devel mailing list

Re: [Flightgear-devel] SVFR

2004-02-06 Thread Alex Perry
David said:
 SVFR means something entirely different in North America. [...]

His was a good summary.  It did not address the pilot qualifications
and currencies needed to use SVFR, which exist in part because SVFR
is often used for scud running ... which is extremely dangerous.

The reason for SVFR as a third set of flight rules is that it basically
permits very near to clouds visual navigation under conditions which 
preclude see and avoid separation from other traffic.  Unusual situation.
Whereas IFR traffic could share airspace with VFR, because the ordinary VFR
keeps far enough away from clouds to allow aircraft to avoid each other,
no IFR is possible in a block of airspace that is being used for SVFR.
Of course, you cannot have two SVFR operations in the same airspace block.

Because SVFR shuts down IFR, it has to be granted by whoever owns the right
to grant IFR clearances through all airspace being approved for SVFR use.
For as long as the SVFR use is authorized, all IFR traffic is turned away.
All airlines are required to operate all scheduled flights under IFR,
and KLAX cannot accept the schedule disruption associated with _any_ SVFR
because the backlog of waiting aircraft would build up far too quickly.

Technically, there is no reason to specify the No SVFR because they can
simply always say no.  However, making the statement on charts saves them
having to say that often, and deal with the subsequent pilot complaints.

Not all SVFR uses are for scud running.  If the visibility drops very low,
as it often does in the Los Angeles basin, the airports can go below VFR
minimums and all VFR traffic is blocked on the ground or is above the 
inversion layer a couple of thousand feet above the airport runways.
Pilots then need an IFR clearance to fly the one mile of climb/descent
that gets them through the smog.  Alternatively, they can use SVFR.

Note that there are cases that are safe to fly and where it is illegal
to land at an airport under VFR or under IFR but still legal under SVFR.

I have never needed to request an SVFR ... yet ...

Flightgear-devel mailing list

Re: [Flightgear-devel] Faster responsiveness on the turn

2004-02-04 Thread Alex Perry
From: Roy Vegard Ovesen [EMAIL PROTECTED]
 I am currently in the process of implementing the Bendix/King KAP 140 
 autopilot. This is a rate based autopilot, it uses the turn rate and rate 
 of climb as its primary inputs. The turn indicator instrument implements a 
 low-pass filter so that the indicated turn rate output from this 
 instrument is a bit sluggish. This sluggishness is bad for controller 
 performance because it adds a time delay. I see two possible solutions:

A lot of autopilots have a rate-of-turn hold input, not just the KAP140,
so this is a generic problem.  Avoid any hacks specific to this device.
It is possible that the low pass is too strong, but I'd have to study it.
The turn indicator is a gyro instrument and, unlike the VSI for example,
doesn't actually have an inherent low pass that we _have to_ model right.

The low pass is primarily due to the fact that both the display routine
and the underlying FDM are running in observable timestep increments.
If we don't filter the data then the instrument looks different to the
pilot because the increments actually modulate subtle changes in the
indication so they become easier for the pilot to see and act upon.
As a result, the aircraft becomes unnaturally easy to fly on instruments.

However, there are other human-corrective hacks we can do to the data.

 1) Increase the responsiveness of the turn indicator. I'm not a pilot and 
 I've never seen a turn indicator in action so I don't know how resposive 
 these instruments are, so maybe increasing the responsiveness isn't a good 

Because the low pass is computed digitally without any noise contribution,
you can back it out in the AP algorithm.  I'm not suggesting you use a
filter with a carefully-placed zero to recover the raw signal though.
Instead, I suggest you put in a stronger differentiator term in the loop
and/or use a separate roll rate feedback loop from the roll angle feedback.

Bear in mind that the TC signal is a composite of rate-of-turn and of
rate-of-bank because the gyro is mounted at an angle, so the instrument
can indicate a standard rate of turn when the nose has not moved at all.
Thus, your feedback loop might be responding to the bank data component.

 2) Add another output property from the turn indicator instrument with 
 higher responsiveness.

The lazy solution is to ignore the property associated with the instrument
and feed directly off the raw body data.  The problem with doing that is
(a) it is not intuitive when working on the XML configuration files
(b) doesn't give the correct behavior for instrument failure situations

Flightgear-devel mailing list

Re: [Flightgear-devel] Airport lighting

2004-01-29 Thread Alex Perry
 From: Erik Hofman [EMAIL PROTECTED]
 Innis Cunningham wrote:
  Erik Hofman  writes
  Is it true that apron/platform/hardstand lights should be red instead 
  of blue?
  If we are talking about area lighting I would think yellow to
  light orange.
 I meant the edge lighting (just like the taxiway edge lights are blue).

In the U.S., the rule is as follows.  It is either similar or identical
to the ICAO rules because other airports have lighting looking similar.

Edge lighting that is at ground level is blue, both for taxiways and aprons.
However, unusual truncation of those areas, as often occurs for construction,
is in red and is often brighter because they normally use the same light
bulbs and a different filter (and lightbulbs have more red than blue).

Similarly, permanent obstructions such as walls, that are risks to be hit
with wings rather than the edge of the area for use by the wheels, will
have red obstruction lights on them.  Blue edge lights are then omitted.

Finally, permanenent lighting is often recessed into the tarmac.
For lights stuck on obstructions/construction, this is not done.
When a long way away, and standing at ground level, the recessed
lights can be invisible so you can only see the ramp edge indication
if it coincides with something that needs a red non-recessed light.

Flightgear-devel mailing list

[Flightgear-devel] JSBsim fails to build in FGFS cvs

2004-01-18 Thread Alex Perry
Making all in filtersjb
make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb'
make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim'
source='FGEngine.cpp' object='FGEngine.o' libtool=no \
depfile='.deps/FGEngine.Po' tmpdepfile='.deps/FGEngine.TPo' \
depmode=gcc /bin/sh ../../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/Include -I../../.. -I../../../src  
-I/usr/X11R6/include -DFGFS -g -O2 -D_REENTRANT -c -o FGEngine.o `test -f FGEngine.cpp 
|| echo './'`FGEngine.cpp
FGEngine.cpp: In method `JSBSim::FGEngine::FGEngine(JSBSim::FGFDMExec *)':
FGEngine.cpp:71: no matching function for call to 
`basic_stringchar,string_char_traitschar,__default_alloc_templatetrue,0 ::clear 
make[1]: *** [FGEngine.o] Error 1
make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim'
make: *** [all-recursive] Error 1

Flightgear-devel mailing list

[Flightgear-devel] Re: Linux User Developer Expo 2004

2004-01-14 Thread Alex Perry
I have no idea whether I can make it.  I am at serious risk of negative
spare time from August through November, and won't know for a while.

Curtis L. Olson [EMAIL PROTECTED] wrote:
 You don't necessarily need to 
 be a developer to help with the booth, but a moderate working knowledge 
 of FlightGear (and for this show, Linux) is always helpful.

Representing an open source project on a booth is a whole lot of fun,
because you get to talk about something that interests you for hours ...
and there is nobody trying to shut you up and/or change the subject 8-).
With proprietary projects, you have to be very careful about what you say,
which takes away a lot of the fun, so obviously open source is easier.

You will generally meet thousands of three kinds of people ...
(1) people who never even downloaded it, but are interested in flying.
(2) people who downloaded it and (probably) had a problem running it,
but were too shy to ask questions on the mailing list, and gave up.
(3) the other developers, as well as expert users who lurk on the list.
They're fun to talk to, and generally have interesting observations.

Curtis L. Olson wrote:
 a possible speaker slot at the Linux User  Developer Expo 2004.

If any of the booth people are willing to stand in front of a lot of people,
I really recommend trying for a slot.  In the booth, you get maybe one
minute to explain FGFS to most attendees - you really cannot cover much.
In contrast, in a speaker slot, may get as much as a hundred times longer,
with a hundred times more people listening, so you can go into some detail.

An FGFS audience will basically sit there as long as you're willing to talk.
This can be a problem (for you) if you've got the last slot of the day.
It's worth writing the talk up-front mostly so you don't realize, afterwards,
that there was something you really really wanted to cover ... and forgot.

Remember, the more people you tempt into trying the package, the better your
chance at crashing Curt's webserver.  There's the mark of a good show event!

PS.  Some events have installfests or other special categories of slots
that are extra long ... maybe as much as a couple of hours.  It's worth
trying for one of these, if available, because you'll easily fill the time.

Flightgear-devel mailing list

[Flightgear-devel] ATC talk - languages

2003-12-30 Thread Alex Perry
 From: Matthew Law [EMAIL PROTECTED]
 My sentiment was that there have also been many accidents caused by ATC
 talking in a foreign language (English) to another pilot who also doesn't
 speak English as a first language.

It's a lot worse than that, for simultaneous use of languages, actually.
Taking the Californias as an example:
* American, a derivative of English, used by locals (changes by state)
* English, used by visitors from the UK, with different terminology
* ICAO, a subset of English with restricted vocabulary and grammar
* FAA, a merging of American and ICAO into something for U.S. controllers
* Mexican, a derivative of Spanish, used for domestic activities in Mexico
* Far east english, the vocabulary of American with a _very_ strong accent

Mexican is not used in the U.S. airspace (except for some types of emergency).
The only one of those _I_ can reliably speak and understand is the fourth one.
I can usually manage the first one, until someone uses a colloquialism etc,
but the other three are simply an emergency waiting to happen to someone.

It is not funny (except in retrospect) to be sharing airspace with someone
whose accented english is so unintelligible that the only way to understand
the transmission is to watch what the aircraft does and think it through.
Similarly, having someone in a UK accent announce a maneuver, after which
there is a long silence on frequency till someone finally asks what's that?
and gets back the official ICAO description which is equally unhelpful to all.

I know for a fact that I cannot speak ICAO; I'd have to take the course first.
It's very hard to avoid using grammar and/or vocabulary that is not approved.
I'm tempted to say that the international pilot community would benefit most
if FGFS were very fluent in ICAO and, when we type or speech recognize pilot
responses back to the simulator, the ATC module rejects noncompliant usages.

As far as catching mistakes is concerned, most problems will still be detected.
Also, in many cases where multiple versions of english are in use at once,
there is more than one user of each version on frequency at any given time.
That enables someone else to spot the developing situation and announce it.

Flightgear-devel mailing list

[Flightgear-devel] Re: Flightgear-devel Digest, Vol 8, Issue 65

2003-12-25 Thread Alex Perry
 On Wed, 2003-12-24 at 05:51, David Megginson wrote:
  Cameron Moore wrote:
  All other things being equal, a plane that flies twice as fast
  (say, because of heavy wing-loading)
   needs twice as much time and four times as much space 
  to make a change in its flight path -- that's why a little Cessna or Piper 
  can start its landing flare over the runway itself, while a transport jet 
  has to start flaring at least a half mile back (pulling up the nose at the 
  last moment would only change the attitude in which the jet smashed into the 
 Airliners aren't that sluggish ... the flare is initiated below 50 ft
 AGL and that is definitely over the runway.

I agree with David.
Visual attitude is mostly unusable for such a discussion because it is
dependent on approach angle, angle of attack and changes in the wing chord.

It is unsafe to fly final in a light aircraft with a 3 degree slope
because the best glide angle is 7 degrees, steepened by any local wind.
A failure of the single engine would result in an off-airport crash.
In contrast, transport aircraft are multiengine are can maintain the
3 degree approach with no trouble following an engine failure.
Light aircraft landing visually therefore tend to be very nose down.

Large aircraft tend to have leading edge slats, unlike light aircraft,
so that the wing chord mostly lowers and lengthens for approach config.
Light aircraft only have flaps and the transition from takeoff flaps
to approach flaps is mostly adding drag, a small amount of length and
a lot of angle change on the chord.  A light aircraft flying in gusty
conditions, with reduced flaps, will have less change in the chord and
the visual attitude is _much_ more nose up.  In fact, for a no-flap
landing, a big part of the challenge is being able to see where you're
going so you have to use a faster short-final speed and the like.

Cessnas C172/C152 and similar aircraft are very draggy, normalized to
their momentum, so a speed change can occur over a short distance.
A low drag aircraft, of any size, takes a lot longer to slow down.
For example, it is hard to slow an AA5B from approach to final speed.
THe need to keep turbine engine RPMs up makes this even more difficult
for transport aircraft, so they start to transition from approach speed
to their landing speeds when there is still a mile (300 ft agl) to go.
The speed reduction causes a considerable change in pitch attitude.

The touch down zone for instrument approaches is 1000 ft down the
runway, with the threshold crossing height therefore being 50 ft.
There are six seconds of flight time from the threshold to the aim
point, and additional seconds from there to actual touchdown.
That is plenty of time to do the roundout (remove vertical speed)
and the flare (remove excess forward speed) before touching down.

Hope that helps ...

NB.  Our flight models should be good enough to represent all those
factors correctly, so you could verify all that description in the sim.

Flightgear-devel mailing list

Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion

2003-12-21 Thread Alex Perry
From: Martin Spott [EMAIL PROTECTED]
 Jon Stockill [EMAIL PROTECTED] wrote:
  And the open source drivers don't support some of the newer ATI cards.
 Sorry, why do you buy cards that are not supported by OpenSource
 drivers ? You are developing OpenSource software, why don't you take
 care of that. I can't accept this as a valid argument.
 I do look out for drivers _before_ I buy a card for my or my customers'
 PeeCee (currently I don't even own a PC  ;-)

There is little point making a Linux based LiveCD of FGFS, if it can only be
used on specific computers that a knowledgable person has already checked.
With that constraint, we might as well either
(a) do a full manual install of Linux with the driver downloading, or
(b) use the Windows version of FGFS and set the CDROM up for AutoRun.
Remember, the idea of the LiveCD was that people could use it at home.

From the pragmatic point of view, if (b) is the right way to go,  I've got
no objections to making the script up on a Linux machine then burning a
copy of the standard AutoRun FGFS image with the new script file inserted.
I won't be able to _use_ the CDROM myself, but I can still hand it out ...

Flightgear-devel mailing list

[Flightgear-devel] LiveCD for FGFS - suggestion

2003-12-20 Thread Alex Perry
For those people who enjoy this kind of challenge (I don't have time):
If someone has (or will have) a script for making a Knoppix style CD of FGFS,
I think the capability is directly relevant for teaching/instructional use.

The CD, when starting FGFS, might load a default configuration and then
give the user the option of running the sim with an automation sequence.
Ideally, the sequence should be easily replaced if the CD is re-burned.

Around the USA, Aviation Safety Counselors give safety related talks
to pilots and AMTs as part of the FAA's Wings program.  While the materials
for the presentation can be generated from scratch, it is usually easier to
take advantage of existing videos and other materials.  We could provide
such materials, in the form of an FGFS LiveCD with such a scripting file,
to both assist in the talk and to enable attendees to practice at home.

While I don't have time to work on the CD image, I'd be happy to make up
scripts so FGFS can be used in a Wings presentation, eligible for credit.
Pilots who take part in Wings need to attend at least one 2-hour session
every year.  I'm sure that, with the progress the project routinely makes,
we'd have no trouble creating at least one presentation topic every year.

Comments ?

Flightgear-devel mailing list

[Flightgear-devel] Re: Linux World Expo, NY, Jan 2004

2003-10-23 Thread Alex Perry
Curt asked:
 If anyone is interested in organizing a FlightGear booth at the Linux
 World Expo in NY, Jan 20-23 2004, now is the time to apply for booth

Sorry, we cannot guarantee to be in NY then so I cannot be the organizer.
If someone requests a booth, please allocate two exhibitor badges for us.
Don't forget to tell me - so I can start kicking the hole in my calendar.

Flightgear-devel mailing list

[Flightgear-devel] COMDEX in Las Vegas next month

2003-10-07 Thread Alex Perry
We have been offered free booth space at the COMDEX expo in Las Vegas.
If you'd like to spend a few days introducing thousands of people to your
favorite flight simulator, tell the show organizers and they'll provide space.

I've got the form and contact (keeping addresses out of our list archive)
so let me know if you'd like the information ...

I can help, but it'll be limited because I'm already involved in three
sessions and a different booth. Apologies if this has already been mentioned.

From Laura Taillie
 We are developing an Open Source and Linux Community area at COMDEX.
 We would love to have you be a part of that.
 We will provide:
 - a table, chairs, waste basket, carpet, electricity, signage with logo
 You will provide:
 - Yourself, laptop, internet connectivity you will need to pay for,
   anything else you would like to show.

Flightgear-devel mailing list

Re: [Flightgear-devel] server upgrade

2003-09-26 Thread Alex Perry
From: Curtis L. Olson [EMAIL PROTECTED]
 Thanks to a kind donation by an anonymous friend of the flightgear
 project we have just been able to upgrade our main ftp server [...]

Please thank the anonymous friend from me too, when opportunity arises.

Flightgear-devel mailing list

[Flightgear-devel] model airplanes - but without FGFS so far

2003-09-20 Thread Alex Perry

There _must_ be a better way to communicate with the remote model aircraft
than to use a web application server as the client software ...
... any ideas ? 8-)

Flightgear-devel mailing list

[Flightgear-devel] San Francisco city lake

2003-09-08 Thread Alex Perry
From: Erik Hofman [EMAIL PROTECTED]

Someone was complaining about the lake in the middle of the city.
I suspect it is the age of the vmap dataset that is to be blamed.

There is the long straight dip going towards downtown and also the
small lake on the San Andreas fault.  In real life, both are fairly
deep dips and were, I suspect, tidal and flooded respectively.

I suspect that, since the vmap data was collected, the dips were drained
and thereby turned into the parkland that you see in the photo.  

A similar effect is visible in San Diego for the Mission Bay area;
any long term local who sees our scenery immediately knows when the
vmap0 data was recorded; only recent arrivals refer to it as 'wrong'.

Therefore, I suggest we leave the lake as-is (unless someone who has
lived in the area for a couple of decades has better historical data).
I don't think we can have a simple rule to determine which lakes and
swamps will have been drained or paved over during the last 20-50 years.

Flightgear-devel mailing list

Re: [Flightgear-devel] EAA Sport Aviation - article

2003-09-08 Thread Alex Perry
From: Alex Perry [EMAIL PROTECTED]
 I've just been reading the April 2003 issue of EAA's Sport Aviation magazine
 and pages 50 through 58 are a nice article titled Virtual Building about
 Flight simulation for the homebuilder by Chuck Bodeen.  It includes a
 discussion comparing the benefits of FlightGear, X-plane-0.66 and MSFS2002.
From: Erik Hofman [EMAIL PROTECTED]
 A comparison between FlightGear *and* MSFS *and* X-plane.
 This and David's post give me the feeling we're on the right track!

Erik asked:
 Any conclusion on FlightGear?
Alex asked:
 [...] I am writing to request permission to scan pages 2 and 50-58 and
distribute the images to the engineers that develop the FlightGear product.
Editorial at EAA replied:
 As long as it's an internal distribution, that would be fine.
 Thanks for asking.

I'll send a set of scanned images to Erik (off list).  Any other developers
who're interested, just send me a note.  Our license to the images (as above)
allows you to forward them to other developers but not other non FGFS people.

Flightgear-devel mailing list

[Flightgear-devel] EAA Sport Aviation - article

2003-09-06 Thread Alex Perry
I don't recall seeing this go past previously; if it has, my apologies.

I've just been reading the April 2003 issue of EAA's Sport Aviation magazine
and pages 50 through 58 are a nice article titled Virtual Building about
Flight simulation for the homebuilder by Chuck Bodeen.  It includes a
discussion comparing the benefits of FlightGear, X-plane-0.66 and MSFS2002.

I haven't seen an online version of the article anywhere yet though.

Flightgear-devel mailing list

[Flightgear-devel] Really OT: Motion sickness

2003-09-01 Thread Alex Perry
Given historical precedent of FGFS developers going for flight training...
a magazine gave tips for motion sickness in boats, relevant to acft too.
1. Look at the horizon and try to have your side peripheral vision be
   horizon and not the moving side of the vehicle (if feasible).
2. Orient yourself and/or the vehicle so most of the motion is side to
   side; humans are more sensitive to longitudinal pitching.
3. Avoid tasks that require vision and preclude adherence to (1) above,
   so don't look at instruments or charts unless absolutely necessary.
4. Adjust air vents for a light draft of cool fresh air, but not a breeze.
5. Sit so your back and neck are supported and the muscles can relaz.
6. Do something active, such as fly the plane or discuss with instructor.
7. Eat and drink, preferably well before before takeoff, and avoid foods
   that cause dehydration such as coffee and some sodas (for example).
8. Always get plenty of sleep beforehand and avoid unnecessary stress.

An important element of 3,6,8 is to brief the flight carefully beforehand
and, where appropriate, pick up the lesson plan at the conclusion of the
previous lesson so you can practice the activity using FlightGear first.
Depending on the goal, FGFS may or may not accelerate that training,
but it will definitely reduce stress, help you relax and look outside.

Flightgear-devel mailing list

RE: [Flightgear-devel] [OT] Outlook comments

2003-08-28 Thread Alex Perry
I have been wondering whether the Outlook autorun feature
could conveniently be used to assist Windows users who would
like to use FlightGear.  They sign up for the mailing list
[EMAIL PROTECTED] as usual and their
start of subscription mail message has a PIF attachment
that autoinstalls FlightGear.  Thereafter, whenever we
have a version upgrade, the announcement is copied to that
mailing list ... together with a PIF autorun attachment
that will apply the upgrade without user intervention.

Convenient, no ?

From: Norman Vine [EMAIL PROTECTED]
 May we please put this thread to rest and allow FGFS 
 to return to soaring above petty OS bigotry

Seconded.  FWIW, the discussion is not about OS bigotry.
Anybody can run Outlook (with WINE) on Linux and run most
Linux mail readers on Windows.  With the former, a default
Outlook will behave just as badly on Linux, and, with the
latter, most casual users will have trouble with attachments.

Flightgear-devel mailing list

re: [Flightgear-devel] OT: First Solo

2003-08-24 Thread Alex Perry
Matthew Law writes:
 I did my first solo this evening after almost 13hrs.

Congratulations.  What are you training in ?

 In summary, it went OK. I can't wait for the cross countries, but
 I'm sure the inclement UK weather will impede those a little :-(

I much preferred to fly the cross countries with poor visibility.
There isn't much of a challenge to a 60 nm flight in 80SM visibility.
You haven't even climbed to cruising altitude, yet you've already got
the destination airport in sight.  The remaining bit of excitement is
which runway they're using ... which lasts until you tune the radio.

From: David Megginson [EMAIL PROTECTED]
 For me, the first solo cross-country was the best part of training.
 First solo was an important moment, of course, but it wasn't until
 I left the familiar airspace behind and started actually flying to a
 different city that I felt like a pilot.

Yep; meeting new pilots, and (once) having to hold short of the runway
for a harrier jump jet that was doing touch-n-goes in the pattern ...

Flightgear-devel mailing list

[Flightgear-devel] keyhole's earth viewer

2003-08-17 Thread Alex Perry
A bit off topic but may be of interest.  These people
provide photographic 3D views of the world (at various resolutions)
and it occurs to me that their positioning interface for the viewer
may be scriptable.  In that case, one computer could run FGFS and
show the instrument panel on the monitor, while another computer
could run their viewer with the viewpoint slaved to FGFS.

Just a thought for those people who want photo scenery ...

Flightgear-devel mailing list

Re: [Flightgear-devel] Small scenery comparison

2003-08-14 Thread Alex Perry
From: Erik Hofman [EMAIL PROTECTED]

Speaking from personal experience,
* I find that omitting horizon haze makes the two MSFS look quite silly.
* The visibility is ridiculously good for both the MSFS examples and it only
looks like that for a couple hours after a really good rain storm has hit.
The FGFS visibility is too good as well, but at least Catalina is merging
into the horizon haze layer and is realtively hard to find/identify.
* The way buildings are added to MSFS looks quite reasonable around downtown.
* The isolated buildings meld in quite nicely in standard MSFS but look
really silly in the enhanced version because the texturing doesn't match.
* The enhanced MSFS scenery looks like the colormap has been modified
and a hyperresolution algorithm has been applied to try to show detail.
This would be fine except that it has made the pixelation really obvious.
* Freeways are really obvious in real life, even in urban areas, and I find
both FGFS and enhanced permit reasonable IFR.  Basic MSFS hides freeways.
* They all show the reservoir, but FGFS doesn't apply a texture around the
edge to imply the white zone without vegetation due to changing levels.
* Both the main airports in the field of view are far too easy to see in
FGFS, and you can even see Hawthorne and Long Beach's (?) locations too.
That is definitely wrong; even LAX should be almost invisible from here.
* In terms of bringing out navigational details, basic MSFS doesn't show
the ridge of raised land at all, which is a major terrain landmark.

A couple of years ago, I posted photos corresponding to this screenshot:
If you have them still, you can compare the coloring and notice
just how different it looks.  Almost unrecognizable ... I can only
infer the location by the shape of the reservoir and adjacent mountain
and then confirm by the indian casino on the left side of the image.
FGFS has the mountain and reservoir (don't know about the casino offhand).

Amusingly, the other screenshots for San Diego area all appear to have
been selected for being inside the class B airspace (this one is right
on the hairy edge of the airspace and probably only just in the clear).
Maybe they're trying to make it difficult to take comparative photos?

Hope that helps, Erik ...

Flightgear-devel mailing list

  1   2   3   4   5   >