Arnt Karlsen wrote:
..most people will the source tarballs goes into the /usr/local/ tree
as told by the docs. When co'ing from cvs, they haul in _everything_
_again_, instead of just update what's new in cvs since the tarball
release.
As I did, it's been a bit of a learning curve but well
Jon Berndt wrote:
I'm not aware of the internals of the autopilot, but it might be usefull
to wait a bit until the script manager is working properly, and then
make the autopilot script driven.
What is the script manager?
David comitted a new FlightGear/src/Scripting directory containing
Matthew writes:
I know I should know this, but what is the roadmap for version 1.0?
Sorry, this reply got a little long ...
From my perspective, version numbers are pretty arbitrary. We assign
version numbers simply so we can keep track of which version is older
or newer than which other
Curtis L. Olson writes:
We do use a convension where odd numbered releases are considered
developmental, and even numbered releases are considered stable.
Except that all development stops on the even-numbered version as soon
as it's released, so bug fixes show up only in the unstable
No. Some of the 2D instruments, like basic gauges, are OK projected
onto a 3D surface, but levers and knobs just look silly. The
background texture won't be used in 3D either, and I'll bet that
Martin ends up putting a lot of his effort into that.
Instrument panels done in the style used
On 1/14/03 at 2:58 PM Curtis L. Olson wrote:
David Megginson writes:
Except that all development stops on the even-numbered version as soon
as it's released, so bug fixes show up only in the unstable version
(which is usually more stable).
That may be true. Personally I keep my focus on the
In 2001 David Megginson had submitted bug no 433286 Sun lights plane at
night.
to http://sourceforge.net/projects/flightgear/. His summary was:
Sun lights plane at night.
After the sun disappears below the line of sight, it
continues to light the plane throughout the night; the
part of the
[...] My personal hope as a
non-US citizen is that world-wide DEM-3 data from STRM becomes available
prior to 1.0, but I'm not holding my breath on that one any more.
To be honest - I don't believe SRTM data will be available for free for the
next decade
Martin.
--
Unix _IS_ user
David Luff writes:
As for 1.0, although its just a number, I personally think its a
pretty significant number, and probably worth a bit of work
polishing bugs , user interface, and installation problems out as
much as possible before release.
David,
Definitely we want to get out releases
[EMAIL PROTECTED] writes:
In 2001 David Megginson had submitted bug no 433286 Sun lights plane at
night.
to http://sourceforge.net/projects/flightgear/. His summary was:
Sun lights plane at night.
After the sun disappears below the line of sight, it
continues to light the plane throughout
On Tue, 14 Jan 2003 16:15:50 -0600
Curtis L. Olson [EMAIL PROTECTED] wrote:
The policy is that we say nice things about sourceforge and we
appreciate the service they provide to the open-source community.
But they really pissed me off one day with some of their policies, so
we vacated and
On 1/14/03 at 4:10 PM Curtis L. Olson wrote:
Lots
David Luff writes:
As for 1.0, although its just a number, I personally think its a
pretty significant number, and probably worth a bit of work
polishing bugs , user interface, and installation problems out as
much as possible before
On 1/14/03 at 4:29 PM Jon S Berndt wrote:
On Tue, 14 Jan 2003 16:15:50 -0600
Curtis L. Olson [EMAIL PROTECTED] wrote:
The policy is that we say nice things about sourceforge and we
appreciate the service they provide to the open-source community.
But they really pissed me off one day with
Curtis L. Olson writes:
Building a 3D cockpit for a transport jet will be quite an adventure
-- in terms of runtime GPU overhead, it will be equivalent to having,
perhaps, 10-15 3D 172 cockpits on the screen at once. Of course, by
the time we finish one, that probably won't be a
Gene Buckle writes:
No. Some of the 2D instruments, like basic gauges, are OK projected
onto a 3D surface, but levers and knobs just look silly. The
background texture won't be used in 3D either, and I'll bet that
Martin ends up putting a lot of his effort into that.
Instrument
Curtis L. Olson writes:
2) There seems to be a principle at work that very few people download
and test development and pre-releases. Mostly it's a few
developers who already know all the tricks, already have all the
prerequisites on their systems, etc. This means that the big
Gene Buckle writes:
No. Some of the 2D instruments, like basic gauges, are OK projected
onto a 3D surface, but levers and knobs just look silly. The
background texture won't be used in 3D either, and I'll bet that
Martin ends up putting a lot of his effort into that.
Jon S Berndt writes:
The policy is that we say nice things about sourceforge and we
appreciate the service they provide to the open-source community.
But they really pissed me off one day with some of their policies, so
we vacated and moved all our services to two machines I admin locally
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Megginson
Even so, we probably need a prolonged 1.0beta period -- perhaps two
months -- with a complete feature freeze. When we all get bored not
being able to create new features, we might actually start swatting
bugs. I agree that we need a
David Luff writes:
Can someone who lives in Texas actually call someone else a redneck?
Yeah, and Houston no less ...
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota
Even worse is this crappy proprietary driving sim software I have to
curse all day at my day job. If I wasn't so busy trying to coax it
through and endless series of segfaults, crashes, bugs, and other
unrepeatable behaviors I'd be tempted to make an open source driving
sim based on
On 1/14/03 at 4:10 PM Curtis L. Olson wrote:
David Luff writes:
and I'd have thought that displaced thesholds and the arrows
pointing to them would have to be pretty high on the list of
features that would be expected to make it in.
Do we actually have these in our airport data? If so (or if
David Luff writes:
Can someone who lives in Texas actually call someone else a redneck?
Yeah, and Houston no less ...
Curt.
Dang! I set myself up again!
Well, I don't think *I* qualify as a redneck. I'm an engineer. I don't drive
a pickup. I don't own a shotgun.
[now let's see ... where
On Tue, 14 Jan 2003, David Luff wrote:
Got it. The Dafif has separate landing and takeoff distances for each
direction of each runway, and on the airports/runways I've looked at (in
the UK) these seem to correspond to the displaced thresholds. To be quite
honest I never realised one could
2) There seems to be a principle at work that very few people download
and test development and pre-releases. Mostly it's a few
developers who already know all the tricks, [...]
I'd be happy if we would have some more time between pre-releases and final.
During development cycles I'm
Michael Basler writes:
Wouldn't we require to have at least one airport (KFSO?) rendered with
reasonable 3D objects etc. (buildings, trees, taxi ways, gates...) at least
as a proof of concept we can do it?
That's not a bad idea. Everything is in place for it, including
animated windsocks.
David Luff writes:
David Luff writes:
and I'd have thought that displaced thesholds and the arrows
pointing to them would have to be pretty high on the list of
features that would be expected to make it in.
Do we actually have these in our airport data? If so (or if the data
Jon Berndt writes:
Well, I don't think *I* qualify as a redneck. I'm an engineer. I don't drive
a pickup. I don't own a shotgun.
A failed redneck, then (redneck manqué).
[now let's see ... where did I leave the phone number I call to get tickets
to the Houston Livestock Show and Rodeo
Jon Stockill writes:
I can import and export the xplane database, and have some code which
parses the DAFIFT data, and compares it with the existing database,
however:
1. Not all airfields in the xplane database are in DAFIF
2. Not all DAFIF airfields are in xplane
therefore
3.
David,
David Megginson writes:
Michael Basler writes:
Wouldn't we require to have at least one airport (KFSO?) rendered with
reasonable 3D objects etc. (buildings, trees, taxi ways,
gates...) at least
as a proof of concept we can do it?
That's not a bad idea. Everything is in place
On 1/15/03 at 12:39 AM Jon Stockill wrote:
On the subject of runways - I've been working on the database today.
I can import and export the xplane database, and have some code which
parses the DAFIFT data, and compares it with the existing database,
however:
1. Not all airfields in the xplane
David Megginson writes:
Real rednecks wear baseball caps with farm-equipment logos on them,
don't they? Where's your bikini-inspector tee shirt?
My favorite is the I'm with stupid tee shirt, but with the arrow
pointing up (or is it down?)
I'm more of a geek than a redneck too ... my best geek
David Luff writes:
Yep, here's my stats from the program I ran to compare the databases when I
imported the atis data:
*** STATS ***
9873 airports in DAFIF
16937 airports in default.apt
1384 airports had K added to match default.apt
Also note that the Alaska and Hawaii airports
On 1/14/03 at 8:11 PM David Megginson wrote:
For now, let's just get all the airports in. The way that X-Plane
implements taxiways is just horrible -- aprons are just wide taxiways,
for example, and taxiways are always rectangles run together. Perhaps
we'll be able to think of a better system.
On Tue, 14 Jan 2003 18:03:25 -0600,
Jon Berndt [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
David Luff writes:
Can someone who lives in Texas actually call someone else a
redneck?
Yeah, and Houston no less ...
Curt.
Dang! I set myself up again!
Well, I don't think
Anyone have an IEEE membership?
http://www.computer.org/proceedings/ds-rt/1053/10530045abs.htm
On Tuesday 14 January 2003 06:14, ace project wrote:
Original message (copypaste for digest):
Date: Sat, 11 Jan 2003 09:00:34 -0600
From: Mike Bonar [EMAIL PROTECTED]
Subject: Re:
David Luff writes:
I believe his intention/achievement
is to allow the editing of scenery superimposed over calibrated maps or
ariel photos, which would ease the task of getting the aprons/taxiways etc
in the right place.
I can heartily reccomend two OpenSource packages for doing this
On Tue, 14 Jan 2003 16:10:08 -0600,
Curtis L. Olson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
3) Expectations are somewhat different for us than many other
open-source applications like autoconf/automake. Those guys
just wrap up a tarball and release it and are done.
On Tuesday 14 January 2003 14:23, David Megginson wrote:
...snip
You can already do some of that with the new XML GUI support, but it
needs to be integrated with the drop-down menus and with an expanded
scripting manager. Most of the building blocks are there now.
Can you elaborate on the
My favorite is the I'm with stupid tee shirt, but with the arrow
pointing up (or is it down?)
snicker
By the way, Jon, what do guys at
Nasa say when something is relatively easy?
We say: OK, what did we miss? [BTW, I am not employed by NASA, but by a
major aerospace corporation who supports
Technically, Y'alls is more of a possesive form of Y'all.
At least that's how I use it. Y'all can use it yall's own way.
And yes, that paticular usage is techically wrong too, considering
that its usually used to refer to an physical object, such as an
airplane :)
Nyeh.
Y'all have fun.
Jon
On Wed, 15 Jan 2003 01:45:30 +
David Luff [EMAIL PROTECTED] wrote:
[snip]
... FWIW I'm currently writing a
program to allow the laying out of a logical taxiway and parking place
network for AI planes to follow over an image of Flightgear's rendered taxi
and runways by clicking on it
Guys!
We can't achive MSFS2002 quality without multitexture support
so First task we have to work on is multitexture support
Steve Baker said that he wait until shader languages become popular and
OpenGL2.0 come out
so or we wait OpenGL2.0 or implement multitexure
I start work on it
my primary
43 matches
Mail list logo
