Re: [Flightgear-devel] 64 bit compile speed

[James A. Treacy]

On Mon, Jun 14, 2004 at 09:09:34AM -0700, Alex Perry wrote:
> 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
http://buildd.debian.org/fetch.php?&pkg=flightgear&ver=0.9.4-1&arch=ia64&stamp=1083643879&file=log&as=raw

> Build needed 00:23:49, 74856k disk space

Note that I have no idea what else (if anything) was running on the
machine at the same time.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] re: [Terragear-devel] SRTM 90 for Europe and Asia

[James A. Treacy]

On Wed, Nov 05, 2003 at 04:32:01PM -0500, David Megginson wrote:
> 
> Fantastic.  I guess that the Aussies, Kiwis, and S. Americans will
> still be stuck in flatlands, though -- serves 'em right for spinning
> the water down their drains backwards.
> 
Since there are probably a few folks here who don't know that David is
joking (I hope he is :), check out the following:
http://www.urbanlegends.com/science/coriolis/coriolis_force_sci_physics_faq.html

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Scenery mirrors

[James A. Treacy]

On Wed, Oct 15, 2003 at 10:49:36AM -0500, Curtis L. Olson wrote:
> 
> The difficulty for us is that our web and ftp trees are on separate
> machines.  They aren't even on the same server.  Our ftp tree is about
> 13Gb, our web site is about 100Mb.  If we merged all the ftp data in
> with the web site, we'd kill all our mirrors.  I strongly suspect that
> gnucash can get away with their scheme because their disk space usage
> is far less than ours.

Here is what I created for the Debian web site a number of years
ago when I was the webmaster. The changes needed for flightgear are
straightforward. The one requirement is a cgi which redirects the user
to the proper site:

http://cgi.debian.org/cgi-bin/redirect.pl";>

Select a server near you:



Australia
Austria

[lots of countries snipped]

United Kingdom
United States





I can provide the redirect script, but it's pretty simple.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Scenery mirrors

[James A. Treacy]

On Wed, Oct 15, 2003 at 12:36:26PM +0100, David Luff wrote:
> The http mirrors of FG are all straight mirrors of the master site, as are
> the ftp mirrors.  Hence the graphical scenery download page on the http
> mirrors points back to the master site.  Hence it's impossible to download
> scenery from the ftp mirrors using the graphical interface.  It seems to me
> it might be worth tweaking the http mirror's graphical download page to
> point to the corresponding ftp mirror if available?

This is one of the reasons that relative links are a good idea. As a
made up example, a link from http://gnucash.org/en/contribute.phtml to
http://gnucash.org/pub/gnucash/sources/stable/ should use
 instead of
http://gnucash.org/pub/gnucash/sources/stable/";>

As an aside, it is a good idea to include the final slash when linking
a directory. It removes the need for a redirect.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] web site updates

[James A. Treacy]

At the risk of offending the author of the text, I have modified the
last three paragraphs of overview.html to be a bit less personal.
Reading 'we' too many times gets distracting. Also, the reader has no
idea who wrote the page so I attributed the last paragraph as a quote
from Curt (assuming Curt wrote it :).



There are a wide range of people interested and participating in this
project. This is truly a global effort with contributors from just about
every continent. Interests range from building a realistic home
simulator out old airplane parts, to university research and
instructional use, to simply having a viable alternative to commercial
PC simulators.


Flight Gear and its source code have intentionally been kept open,
available, and free. In doing so, we are able to take advantage of
the efforts of tremendously talented people from around the world.
Contrast this with the traditional approach of commercial software
vendors, who are limited by the collective ability of the people they
can hire and pay. Our approach brings its own unique challenges and
difficulties, but we are confident (and other similarly structured
projects have demonstrated) that in the long run we can outclass the
commercial "competition."


Contributing to Flight Gear can be educational and a lot of fun. A long
time developer, Curtis Olson, had this to say about working on Flight
Gear:

Personally, Flight Gear has been a great learning experience for me. I
have been exposed to many new ideas and have learned a tremendous amount
of "good stuff" in the process of discussing and implementing various
Flight Gear subsystems. If for no other reason, this alone makes it all
worth while. 


-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] 64-Bit Question

[James A. Treacy]

On Thu, Jun 12, 2003 at 10:21:46PM -0500, Jonathan Polley wrote:
> Now that 64-bit processors are becoming more available, does anyone 
> know of any problems that FlightGear may have running on a 64-bit 
> processor (Opteron or PowerPC 970)?  I am assuming that those areas 
> that would be sensitive to data sizes (i.e., file formats) are safe?

Flightgear is automatically compiled on all debian architectures when a
package is uploaded. It compiles fine on alpha and ia64 (*)(0.9.1 is not
compiled yet on ia64 due to a dependency problem). Of course, this does
not guarantee that FG runs on those machines.

(*) See http://buildd.debian.org/build.php?&pkg=flightgear

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Viewer suggestion: acceleration effects

[James A. Treacy]

I forgot another possible effect: spinal compression. This one, if
necessary, can almost certainly be considered as being uncoupled from
any head rotations.

delta z = z-accel / Kspine

Also, it may be that the equation for pitch of the head is too simple
as the two terms can cancel each other out(*) and it would a good idea
if the model got this correct. It may be that the linear model is
close enough that picking the constants correctly will allow for this.
Unfortunately once you start rotating things intuition doesn't work
well.

(*)for example a forward acceleration while pulling back on the stick.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Viewer suggestion: acceleration effects

[James A. Treacy]

On Fri, Feb 07, 2003 at 09:43:59AM -0800, Andy Ross wrote:
> 
> Why not just model the "head" as a highly damped spring?  You'd need
> to fiddle with the constants a little to make it look right, but once
> it's fixed up it should work right for all heads. :)

Since this is simply a visual effect, let's start by trying a
linear system. If it turns out to be too simple we can simply add a
nonlinearity. If that is still not good enough (most likely due to the
head snapping back too fast), it isn't difficult to model a damped
spring system undergoing all the relevant effects.

Since I imagine that a jet fighter can generate head motion due to
both linear acceleration and pitch I've included both terms for head
pitch.

Since I don't know what coordinate system FG uses, I used words for
the accelerations. Also, the 'spring constants' (Ka, Kp, Kr and Ky)
are really fudge factors representing both the mass of the head and
the resistance to rotation. The coder will need to experiment.

angle of head pitch = forward accel / Ka  + (d^2/dt^2 pitch) / Kp
angle of head roll  = (d^2/dt^2 roll) / Kr
angle of head yaw   = (d^2/dt^2 yaw) / Ky

Having never flown on a high performance aircraft, it is unknown to me
whether the yaw effect is important.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] forwarded message from Henti Smith

[James A. Treacy]

On Fri, Jan 17, 2003 at 02:17:37PM -0600, Jon S Berndt wrote:
> 
> Instead of 1 two-year old, try 2 one-year olds. I've 
> gotten fairly good at programming in 4 minute chunks. 
> That's about how long my twins will stay occupied inside a 
> circle of toys, get bored, then crawl twenty feet to my 
> chair and start pulling/pushing on things. Then, repeat.

Instead of 2 one-year olds, try two 7 week olds. I wish I could get 4
minutes to do some programming. Of course, I guess you already went
through that stage to get where you are. :)

At least you get to sleep through the night.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Licensing issues

[James A. Treacy]

On Wed, Oct 16, 2002 at 03:51:17PM +0200, Christian Mayer wrote:
> 
> If you want to change the licence you must ask every contributor. If one
> doesn't answer or one rejects the change (you'll have to assume the
> worst) you must roll these commits back before you change the license.
> There's no other way to do it.
> 
> Code that has grown over the time is thus quite impossible to convert to
> a new license with out implementing it in a clean room.
> 
> As this sounds like *very* much work to me and all of us have no spare
> time (if they'd had they'd be improoving FGFS...) I can't see the FGFS
> changing the license in the near future. 
> If a company needs a differnt licence they could do it if they have the
> resources... (have a look at the Wine project as a reference)

IMO, changing licenses is one of those areas which end up being easier
in practice than expected - if people see a good reason to change the
license. If the reasons to change the license aren't strong enough you
are much more likely to encounter resistance (and as has been discussed
resistance would make changing the license very difficult).

To date, I don't believe the reasons to change the license are strong
enough to overcome any resistance.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Licensing issues

[James A. Treacy]

On Tue, Oct 15, 2002 at 11:15:08PM -0500, Curtis L. Olson wrote:
> Question: for a particular source file, if a person contributed a
> minor patch or tweak to compile on a new platform, does that person
> now have a "full" say in the future of that source, or are they giving
> their changes to the author of that file to be placed under the
> license terms chosen by the primary author.

Exactly the way I want to think of it. The law, though, seems to have
its own bizarre sense of logic. I belive that contributions are seen
as being individual items(*), like pieces of lego. You only have the
copyright on your 'pieces of lego'. Thus, if the primary author of
some code wants to release future versions under a different license
and a contributor disagrees, then the primary author would need to
back out the contributed code.

Obviously, as code evolves it becomes less clear who contributed what.

(*)This is what I have surmised from previous discussions on
copyright. I have never seen this explicitly stated. I don't like this
way of looking at things but we have to deal with the legal system we
have been given.

> My sense is that if it is only minor changes that were contributed by
> others, the primary author should be able to maintain complete
> "ownership" over the copyright and license terms of that code.

It is precisely because this is false that the FSF will not accept
code for software they own the copyright unless you sign a
document stating you own the copyright on code that you submit and
assign the copyright to the FSF.

> If someone else (in addition to the main author of a particular chunk
> of code) contributed new code, or a major rewrite, or something else
> significant, then we start getting into gray areas.  It seems like the
> primary author of that code probably still could have final say, but
> basic courtesy might dictate that the major contributors at least be
> consulted ... (?)

I wish common courtesy played a part in such matters. When it comes to
the law you can't trust people to be polite. Unfortunately, the legal
system is inherently combatative(**).

SUMMARY
If the developers decide to change the license it should be doable.
Some person or group will need to track down as many contributors as
possible and try to get them to agree to the switch. That is where the
real work is. My opinion is that the change won't bring enough benefits
to warrant the expenditure of energy.

(**) Off topic: the family of a co-worker of my wife completely
devastated a few million dollar estate (on lawyers) because one
group didn't agree with the terms of the will and contested it.
This is not a rare occurence.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Licensing issues

[James A. Treacy]

On Tue, Oct 15, 2002 at 03:22:02PM -0500, Curtis L. Olson wrote:
> 
> - If we wanted to tweak the licensing terms for the FlightGear
>   project, could we?  Who has authority to do this.  If we can get
>   most authors/contributors to agree, is that good enough?  Do we need
>   approval from 100% of the authors/contributors?  What if someone
>   doesn't respond negatively now (i.e. they are on vacation, or just
>   don't have time to think about it) and we change the licensing
>   terms, but then they come back in a year and make a big issue of it?
>   What do we do then?  Would that be a potential problem?

You should get as close to 100% of the contributors to agree as you
can get. Flightgear needs to be prepared to remove any code written by
someone who disagrees or who couldn't be contacted and appears later
on.

FWIW, wine did this earlier this year and they got all but a handful
of contributors to sign off on the change. The missing had made only
small contributions that they could easily recode if the need arose.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Accelerations and Rates

[James A. Treacy]

On Tue, Oct 01, 2002 at 10:18:36AM -0500, Curtis L. Olson wrote:
> David Megginson writes:
> > I'm hitting a wall with my limited knowledge of calculus.
> > Specifically, I'm looking at the following:
> > 
> > - latitude-dot
> > - longitude-dot
> > - radius-dot
> > - v-dot-local
> > - v-dot-body
> > - alpha-dot
> > - beta-dot
> > - phi-dot
> > - theta-dot
> > - psi-dot
> 
> I think "dot" means 'rate of change in' or 'derivative'.  latitude-dot
> would be the rate of change in latitude.  I.e. latitude is a position,
> latitude-dot is a velocity.  If you had velocity-down (earth centered
> coordinates) then velocity-down-dot would be the change in velocity
> (or an acceleration.)


latitude-dot is the rate of change of latitude but is not strictly
velocity. For an angular measure, angle-dot * radius would be the
(magnitude of) velocity.


-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Website updates

[James A. Treacy]

On Mon, Jul 22, 2002 at 03:59:44PM -0500, Cameron Moore wrote:
> * [EMAIL PROTECTED] (David Megginson) [2002.07.22 11:48]:
> 
> A related nit I have with the current homepage snapshots is that they
> show things we don't currently have in FG, ie. rivers, roads, etc.  I
> think we should stick with what is actually in CVS, not what David (or
> anyone) has cooked up on their home box.  We should show people what
> they should expect to see when they download FG, not what they will see
> after an overnight scenery building process...

This brings up something I've been wondering for a while. It appears we
can add roads and rivers. Why, then, isn't this the default?

Just curious.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Re: Environment subsystem status

[James A. Treacy]

On Thu, May 16, 2002 at 12:07:21AM +0200, Christian Mayer wrote:
> 
> Anyway to come back to the thread: isn't your story a proof that SI
> should be used?

Proof? That's a bit strong.

I'm somewhat torn on this issue. Having grown up using english units,
I have a (small) soft spot for them. On the other hand, SI units are
more logical and reduce the chance for errors. Also, being a volunteer
group, it is difficult to impose a rule such as 'thou shalt use SI'.

If anyone cares about the opinion of a non-coder (on this project) a
reasonable solution to the issue of units could be that a piece of
code must provide an SI interface. This way parts of the project, such
as jsb, can use whatever units they want internally as long as they
provide an SI interface. They are, of course, free to provide other
interfaces if they choose.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Re: Environment subsystem status

[James A. Treacy]

On Wed, May 15, 2002 at 10:47:03AM -0700, Tony Peden wrote:
> 
> --- Melchior FRANZ <[EMAIL PROTECTED]> wrote:
> > * Andy Ross -- Wednesday 15 May 2002 18:44:
> > > Typical (North American, anyway) altimeters still
> > > report feet, VSI indicators read in fpm, etc... 
> > 
> > Same here. But please don't tell me that US
> > meteorologist work
> > with slugft3.
> 
> Don't be so quick to slight slugs, feet, etc.
> 
> The fundamental units of each system are
> ***arbitrarily*** defined and, because of that
> each system requires everybody to agree on a 
> common set of arbitrary definitions.

I wish it was that simple. After moving to Canada, I was doing an off
the cuff calculation and said '1 gallon of water is roughly 8lbs'.
Imagine my surprise when everyone in the room disagreed with me,
saying a gallon weighs 10lb. All was made well when I was reminded
that Canadians use imperial gallons. Aaargh.

SI is a real international standard, while 'english' units are just a mess.

Of course, I am constantly reminded of my US background when I tell
the Scouts in my troop to cut a 6' piece of line and get blank stares.
They want me to say 2m. At the same time almost none of them can tell
me their 'weight' in kilograms.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Propeller animation speed fix

[James A. Treacy]

On Thu, May 02, 2002 at 10:22:22PM -0500, Jon Berndt wrote:
> > So, is dt recording elapse time or set to the current step time? If a
> sharp
> > programmer like Andy is getting confused about what dt really is, then
> > perhaps the variable should be called "ms_elapsed" or "t_stepsize",
> etc.?
> 
> This is ridiculous. "dt" is short for delta T. In a 100 Hz simulation, the
> corresponding dt is 0.04. For 120 Hz it's 0.00833. For people that do
> simulation for a living this is one of the *most* recognized parameters
> around.

Jon almost assuredly meant dt = .01 for 100 Hz or dt = .04 for 25 Hz or 
he was testing us. :)

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Notice Upcoming Property changes

[James A. Treacy]

On Tue, Apr 16, 2002 at 01:27:24PM -0700, Andy Ross wrote:
> 
> To make things even worse, plib uses a different convention from raw
> OpenGL.  So the places in the code that manipulate the matrix stack by
> hand (the panel and HUD, at least) are working in yet another
> coordinate convention. :)

The great thing about conventions is there are so many to choose from.

-- 
James (Jay) Treacy   stolen from: The great thing about standards in
[EMAIL PROTECTED]computer science is there are so many to choose from

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Switching to SI units [was [Flightgear-devel] JSBSim changes]

[James A. Treacy]

On Fri, Mar 01, 2002 at 10:48:39AM +0100, Erik Hofman wrote:
> Andy Ross wrote:
> 
> >Well, fear not, there is.  This magical unit world is called "SI", and
> >it works like this:
> >
> >mass: kilogram
> 
> This is where it usually goes wrong. In the general language the weight 
> is usually measured in kilos (or kg). It *is* plain wrong, but bad 
> habbits slowly (or never?) fade away.

While a degree in the sciences, which hopefully all teach SI, should
not be necessary to work on FG, I think that a willingness to learn
is. Given that, general usage is not important.

The real question is, is there a consensus to eventually move to SI
units?

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] JSBSim changes

[James A. Treacy]

On Thu, Feb 28, 2002 at 08:00:49PM +, Jon Stockill wrote:
> 
> Now, feet, inches, miles, furlongs, etc are another matter :-)

Let's not go too far. Furlongs? Next you'll want us to start using
stones. :)

Actually, I'd like to see everything converted to metric in FG.

I never had a problem with english units until I took thermodynamics.
The prof would pose a question in one system and expect the answer
in the other. That borders on torture. I wish that all engineering
classes used metric only these days. Unfortunately, I'm sure it's not
the case.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear Priorities

[James A. Treacy]

On Mon, Feb 18, 2002 at 02:23:47PM -0500, John Check wrote:
> 
> And they do it for entertainment value. For most people FGFS
> is classified as a game. That's right up there with offensive capability 
> on the top 10 list at demos . Besides, we can always have a switch 
> to turn it off. 
> 
You mean a switch to turn it on - the default should be off. :)

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Wind confusion.

[James A. Treacy]

On Sun, Feb 17, 2002 at 04:00:03PM -, Jim Wilson wrote:
> Tony Peden <[EMAIL PROTECTED]> said:
> 
> > I'd be happier if we kept it as is.  Wouldn't be the first time
> > engineers have traded correctness for pragmatism.
> >
> 
> Ah pragmatism!  Is that the excuse engineers use when they get their vectors
> math bass-ackwards? ;-)

Bah humbug. Engineers, seeing that there were two incompatable
standards simply choose to break the one normally seen by people who
should be able to understand the problem and adapt. Obviously, in this
case, they chose the wrong group. :)

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] for the upcoming release

[James A. Treacy]

On Wed, Feb 13, 2002 at 12:43:05PM -0600, BERNDT, JON S. (JON) (JSC-EX) (LM) wrote:
> 
> Hilarious. That's right. Why would anyone be on the runway, ready to take
> off, with the engine off.

It happens - with multi-engine aircraft anyway. Some years ago a plane
(747 I believe) taking off from Tokyo had trouble starting one of the
engines. The captain said something to the effect, 'no problem. once we
go to full power there will be plenty of air pressure to get the other
engine started".

They did start the engine as suggested and got partway down the runway
before the first stage turbine (somewhere around 200lb spinning at
15000rpm!) literally fell out of the engine. It started digging a hole
in the runway before taking off running. Every 10-20 feet it would hit
the ground and take a divot out of the runway. Since the runway is
built out into Tokyo Bay it soon hit the water. It is estimated that
it went about 1/2 mile out, running on the water, before it finally
sunk. It was never found.

IIRC they had a light load and managed to take off.

Be very happy when you hear the engines start up after they close
the doors. They aren't wasting fuel, but letting the engine come to
thermal equilibrium.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] OT: Easy on the rudder there, Cowboy

[James A. Treacy]

On Mon, Feb 11, 2002 at 04:45:16PM -0600, Curtis L. Olson wrote:
> 
> Wow ... when it broke, it broke ... interesting test.  I wonder if the
> 'rate' of flex is important, not just the amount of flex?  They were
> bending the wing pretty slowly ...
> 
They would run the test slowly for a number of reasons. First, test
machines are built for creating large loads not setting speed records.
Second, the manufacturer wants the wing to last as long as possible and
adding dynamic effects (generally) only makes matters worse.

You should see the tests that jet engines are subjected to.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] FreeGLUT

[James A. Treacy]

On Sun, Jan 06, 2002 at 10:34:46PM +, Ross Golder wrote:
> It seems Mesa 4.0.1 doesn't come with glut, like 3.4. Has using freeglut
> been discussed before? I couldn't find anything in the archives.
> 
> 
> 
Besides being maintained upstream, are there any benefits to freeglut?
I ask because I maintain the glut package for Debian and have been
considering packaging freeglut as well.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] FreeGLUT

[James A. Treacy]

On Sun, Jan 06, 2002 at 08:20:14PM -0500, Norman Vine wrote:
> Ross Golder writes:
> >Anyone thought about this before? Care to comment?
> 
> the PLib team has a long range goal of using freeglut as a base
> for a 'better' gaming oriented library, but none of us have felt the
> mecessary 'itch' as GLUT seems to work well enough.
> 
One of the advantages people give for freeglut is that glut isn't
being updated. Looking at the download page for freeglut, it appears
it hasn't been updated since Jan 2000.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel