I'm pretty much done with the client/server startup handshake -- ready to do
the code at the peer to register active aircraft with the server (active =
aircraft for which this FG peer is responsible for FDM calcs, the protocol
supports the idea of multiple aircraft sharing a single server
Gene Buckle wrote:
FDM for a parachute ?? round or rectangular chute ?? joystick controls the
shrouds ?? cutting loose the main and deploying the spare ?? skydiving ??
(ok -- not really related to the ejection code itself, but it would be nice
:) )
In those cases, would be nice == way over my
-Original Message-
From: Phil Spurr [mailto:[EMAIL PROTECTED]
Sent: 12 November 2003 12:24 am
To: [EMAIL PROTECTED]
Subject: [Flightgear-devel] Newbie needs a mentor(s)
Hi all
I've recently (with help from Curt) managed to download and
run the Win32
binaries and have been
John Barrett wrote:
I'm pretty much done with the client/server startup handshake -- ready to do
the code at the peer to register active aircraft with the server (active =
aircraft for which this FG peer is responsible for FDM calcs, the protocol
supports the idea of multiple aircraft sharing a
Erik Hofman wrote:
John Barrett wrote:
I'm pretty much done with the client/server startup handshake -- ready
to do
the code at the peer to register active aircraft with the server
(active =
aircraft for which this FG peer is responsible for FDM calcs, the
protocol
supports the idea of
Manuel Bessler wrote:
I've thrown together something similar with the plib js and net examples
and changed the joyclient on fgfs side. This allows you to use a
joystick port on another machine via the network.
One thing I'd like to change is to make it configurable via the property
tree what is
On Wed, 12 Nov 2003 08:25 pm, [EMAIL PROTECTED]
wrote:
Message: 9
Date: Wed, 12 Nov 2003 09:12:57 -
From: Richard Bytheway [EMAIL PROTECTED]
Subject: RE: [Flightgear-devel] Newbie needs a mentor(s)
I am not a programmer or pilot, but I use Cygwin on Win2K to build
Flightgear. Other than
On Wednesday 12 Nov 2003 1:22 am, David Megginson wrote:
There are raw, scanned sectionals and terminal charts available
online. I haven't downloaded and unpacked the zipfiles yet, so I'm
not sure of the format.
Sectionals, at 1:500,000 scale, are the most commonly-used charts for
VFR
Try using the ignore dependencies flag on RPM to override the dependency checking.
Ugly, but it might work.
Alternatively, start from source and built it yourself.
Richard
you wrote
Frustratingly, I can't get the geotiff packages to install. I have installed
libproj0-4.4.5-2mdk.i586.rpm,
On Wednesday 12 Nov 2003 12:10 pm, Jonathan Richards wrote:
Frustratingly, I can't get the geotiff packages to install.
snip
Anyone know how to unstick this? geotiff gives us a tool to read the tags
in the TIFF files.
Sorry to follow up my own post. I gave up on the rpm packages and tried
- Original Message -
From: Erik Hofman [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 4:22 AM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
Erik Hofman wrote:
John Barrett wrote:
I'm pretty
- Original Message -
From: John Barrett [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 8:50 AM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
- Original Message -
From: Erik Hofman [EMAIL
On Wednesday 12 November 2003 13:10, Jonathan Richards wrote:
[EMAIL PROTECTED] rpms]# rpm -ivh geotiff-1.1.4-6mdk.i586.rpm
error: failed dependencies:
libgeotiff.so is needed by geotiff-1.1.4-6mdk
I don't really understand why this is a problem, because the libraries
seem to be
(if its just the one plane, once I get it to fly multiplayer, my focus will
be to add multiple/AI plane support to the code, so comments towards
achieving that goal will be welcome also)
I think it would make sense to have the server handle any non-human
controlled vehicles. It would keep
John Barrett writes:
when you say null fdm + autopilot -- it doenst appear the null FDM is a
plane at all - wouldnt it make more sense to use the full FDM code with
scripting to drive the existing autopilot code ?? i.e. script sets desired
altitude, heading, speed, limits on pitch yaw roll
- Original Message -
From: Gene Buckle [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 10:48 AM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
(if its just the one plane, once I get it to fly
Is there any designed rhyme or reason to the layout of the properties
from the top down in FlightGear? Any particular conventions? I think
there ought to be something written down if there is not in order to
allow the FDM authors (and others) to splice in nicer.
Jon
Andy Ross wrote:
Erik Hofman wrote:
I think that needs a bit more thought. Most FDM's are just too heavy
for having a lot of them work together. I think we need a NULL FDM
with autopilot support for that.
Exactly. It seems to me like we're swimming in half-finished
Erik Hofman writes:
I vote for pushing NetworkOLK to the bitkeeper by now.
Yes, I'll second that, with appropriate thanks to Oliver for being the
first one forge his way down that path.
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at'
On 11/11/03 at 6:55 PM Seamus Thomas Carroll wrote:
I have the timings you asked for. The output from my GroundActivity
class is as follows:
1) Total Time: 221.99
2) total calc of lon, lat: 0.52
3) total calc of elev: 116.74
4) total model placement time: 0.95
1 is the total
Dave Luff wrote:
Thanks for posting those. As you say, the time spent in
DoGroundElev() looks quite frightening. I'm afraid I have no idea how
to make the function call more efficient - walking hit lists and so
forth isn't really my forte.
However, it does look as though you are hitting it
in ..src/Main/README:
fgfs.cxx
fgfs.hxx
This module defines FGSubsystem, the abstract base class (or
interface) for subsystems in FlightGear. Most of the important
subsystems already extend this class, and eventually, all subsystems
will.
Have these files been removed or did they go
Jonathan Richards writes:
listgeo gives a whole shedload of information about the mapping,
too much to report here unless anyone's interested, in which case
mail me.
I'd just like to take another opportunity to express my appreciation
to the U.S. government for making so much geodata
On Wednesday, 12 November 2003 16:36, David Megginson wrote:
Those of us who are not Americans need
to press our own governments to follow suit.
Bwaahahaha!
Over here that would be like the ant asking an elephant to not step on him.
Even our constitution get's changed without any consultation
David Megginson writes:
Jonathan Richards writes:
listgeo gives a whole shedload of information about the mapping,
too much to report here unless anyone's interested, in which case
mail me.
I'd just like to take another opportunity to express my appreciation
to the U.S.
I'm not sure how to compute this :
If I lay out a runway in an unprojected view (flat) and then convert it into
FG format (projected) how much will the runway be distorted at latitudes of
60 degrees?
i.e How much distortion could I expect over a distance of 2-3 km at latitudes
of 60 degrees?
Paul Surgeon writes:
I'm not sure how to compute this :
If I lay out a runway in an unprojected view (flat) and then convert it into
FG format (projected) how much will the runway be distorted at latitudes of
60 degrees?
i.e How much distortion could I expect over a distance of 2-3 km at
On Wednesday, 12 November 2003 21:22, Curtis L. Olson wrote:
FlightGear goes to great lengths to map the airports correctly on the
curved surface of the earth at any latitude.
If I recall, the procedure converts each runway corner to an angle and
distance from the center point, then it feeds
Paul Surgeon writes:
Holy cow!
About 25% of that passed right over my head. :)
Good, you are doing better than me then. :-)
When you said that FlightGear goes to great lengths to map airports
correctly I assume you mean that the TerraGear scenery building
process does that?
Yes.
Am I
On Wednesday, 12 November 2003 22:28, Curtis L. Olson wrote:
Good, you are doing better than me then. :-)
What? I thought you wrote this stuff.
The FlightGear world preserves the shape of the wgs-84 ellipsoid, so
if you draw things far enough out, you will see the actual curvature
of the
On 11/12/03 at 10:16 PM Paul Surgeon wrote:
On Wednesday, 12 November 2003 21:22, Curtis L. Olson wrote:
FlightGear goes to great lengths to map the airports correctly on the
curved surface of the earth at any latitude.
If I recall, the procedure converts each runway corner to an angle and
Paul Surgeon writes:
What? I thought you wrote this stuff.
Yes, I wrote a lot of it, but I'm not claiming perfect memory. :-)
Yes you mean it actually wraps the data around an ellipsoid not on a
flat plane like some simulators. It's a very nice accurate system
although a bit complex to
In part of my learning the ins and outs of how FG really works, I found
another space I can contribute - the electrical system.
The current system has no way of handling circuit breakers or measuring a
load across a whole bus.
The system now expresses a bus like this:
bus
name.../name
On Wednesday, 12 November 2003 23:04, David Luff wrote:
Hi Paul,
I'm not entirely sure what you're trying to do, or where in the world
you're trying to do it to, but from some of your previous comments it
sounds like you might be trying to overlay satelite or aerial photo images
onto the
On Wed, Nov 12, 2003 at 11:07:48AM +0100, Erik Hofman wrote:
Manuel Bessler wrote:
I've thrown together something similar with the plib js and net examples
and changed the joyclient on fgfs side. This allows you to use a
joystick port on another machine via the network.
One thing I'd
Paul Surgeon writes:
If anyone who understands this is still reading, am I right in thinking
that FG loads up all of the possible scenery textures mentioned in the
materials file at startup and keeps them until shutdown
I get a strong feeling that this is the way it works (haven't stuck
Gene Buckle wrote:
in ..src/Main/README:
fgfs.cxx
fgfs.hxx
This module defines FGSubsystem, the abstract base class (or
interface) for subsystems in FlightGear. Most of the important
subsystems already extend this class, and eventually, all subsystems
will.
Have these files been removed
Gene Buckle wrote:
in ..src/Main/README:
fgfs.cxx
fgfs.hxx
This module defines FGSubsystem, the abstract base class (or
interface) for subsystems in FlightGear. Most of the important
subsystems already extend this class, and eventually, all subsystems
will.
Have
Paul Surgeon writes:
The USGS is unfortunately a rare example of good governance.
Where I live the tax payers pay to get the government to do surveys and then
the government sells us the data. :(
Ditto for Canada. Fortunately, the U.S. is making more and more data
free for our countries
Curtis L. Olson writes:
Like you say, to do this well, we would need some way to efficiently
page texture data in and out. We'd also want to be able to load
lowres mipmaps for distant stuff and hold off loading the full
resolution version of the textures until they are close enough to
On 11/12/03 at 5:36 PM Norman Vine wrote:
Curtis L. Olson writes:
Like you say, to do this well, we would need some way to efficiently
page texture data in and out. We'd also want to be able to load
lowres mipmaps for distant stuff and hold off loading the full
resolution version of the
David Luff writes:
One way todo this is to always use the same size texture so as to
be able to use glTexSubImage2D() to control the level of detail and
mipmaping ourselves.
Easiest todo this if the scenery is laid out so when you go to
a lower level texture it covers 4 times the area and
David Luff wrote:
I'm not entirely clear on this - are mipmaps pre-built and available
on disk for FG to load, or are they built from the main texture at
runtime?
The latter. I believe in our case it's done by plib, but there's a
standard gluBuild2DMipmaps() routine in OpenGL too. The time
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David Luff
Sent: Wednesday, November 12, 2003 5:39 PM
To: FlightGear developers discussions
Subject: RE: [Flightgear-devel] Geo formulae
On 11/12/03 at 5:36 PM Norman Vine wrote:
Curtis L. Olson
Curtis L. Olson wrote:
This can get to be a really complicated subject if we let it. But,
as it works now, a single full res texture is stored on the disk.
It is loaded at run time, and the mipmaps are generated using a
simple 2x2 - 1x1 averaging scheme. (I think this is called a box
Curtis L. Olson writes:
But, we could always just do the internal mipmap generation as we need
it. That would mean keeping a copy of the full res texture in main
ram though.
Not necessarily. i.e. glTexSubImage2D() actually replaces the texture content
so as to have it cover 4 times the
Andy Ross writes:
David Luff wrote:
I'm not entirely clear on this - are mipmaps pre-built and available
on disk for FG to load, or are they built from the main texture at
runtime?
The latter. I believe in our case it's done by plib, but there's a
standard gluBuild2DMipmaps() routine
In the current code -- there is just the single airplane being simulated on
the display ?? or where could I find a list/array of a/c that are being
managed so I can register each plane with the server and have the server
relay updates for all of them ??
Look in the src/ATC directory. There
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 7:51 PM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
In the current code -- there is just the single airplane
On 11/12/03 at 4:45 PM Curtis L. Olson wrote:
David Luff writes:
I'm not entirely clear on this - are mipmaps pre-built and available on
disk for FG to load, or are they built from the main texture at runtime?
This can get to be a really complicated subject if we let it.
...snip lots!
Thanks
On 11/12/03 at 8:08 PM John Barrett wrote:
Sounds good -- like most of what I'm looking for is there -- would
definitly
like to look over the code and see how much work to hook it into my
network
setup
Sorry - I thought you were looking for an fdm-autopilot based solution,
else I'd have
- Original Message -
From: David Luff [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 8:20 PM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
On 11/12/03 at 8:08 PM John Barrett wrote:
Sounds good
I would like to request your ideas and wishes for an aircraft AI scripting
language sufficiently generic in scope to handle piloting any aircraft
running on FG.
My generalized AI airplanes were originally going to be defined in
preferences.xml (like the ai-tanker), something like this for
* [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
code:
static const char *
getDateString ()
{
static char buf[64]; // FIXME
struct tm * t = globals-get_time_params()-getGmt();
sprintf(buf, %.4d-%.2d-%.2dT%.2d:%.2d:%.2d,
t-tm_year + 1900, t-tm_mon + 1,
On Wed, 12 Nov 2003, Cameron Moore wrote:
* [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
code:
static const char *
getDateString ()
{
static char buf[64]; // FIXME
struct tm * t = globals-get_time_params()-getGmt();
sprintf(buf,
On Wed, Nov 12, 2003 at 09:54:34PM -0800, Gene Buckle wrote:
On Wed, 12 Nov 2003, Cameron Moore wrote:
* [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
code:
static const char *
getDateString ()
{
static char buf[64]; // FIXME
struct tm * t =
On Thursday 13 November 2003 06:54, Gene Buckle wrote:
On Wed, 12 Nov 2003, Cameron Moore wrote:
* [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
static const char *
getDateString ()
{
static char buf[64]; // FIXME
struct tm * t =
Jim Howarth wrote:
Ahhh... Well.. I got to it.. Started to fly under it and flightgear
crapped out..
No. It just flagged a collision. The FDMs can only ask FlightGear
how high above sea level is the ground at this location?. This is
fine for doing ground handling on runways.
But the
58 matches
Mail list logo
