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 = globals->get_t
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
> > >
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, "%.4d-%.2d
* [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_m
> 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
- 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:
> >
> >
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 me
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!
- 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 ai
> 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. Ther
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
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
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
> f
> -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:
>
> >Curti
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
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
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 pro
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
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
>
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 countri
> 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
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 o
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
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.
> >
> > On
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 th
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:
...
/systems/electrica
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 ca
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
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
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
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 fee
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 k
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?
Ob
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
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
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 ava
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 mi
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 hitti
John Barrett wrote:
> what I'm asking is "everything looks like it works through globals
> rather than discrete instances of aircraft+fdm+autopilot -- am I
> looking at a serious architectural change to get multiple
> independent ac+fdm+ap simulated concurrently ??"
Pretty sure, yeah. :)
The last
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
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' me.umn.
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, t->tm_mday,
t->tm_hour, t->tm_min, t->tm_sec);
retu
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
multiplayer/multiaircraft/ne
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
___
John Barrett wrote:
> 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 ??
Um, isn't that t
- 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 f
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 rol
> (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
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
- 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 Hofm
- 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:
> >
> >
On Wednesday 12 Nov 2003 12:10 pm, Jonathan Richards wrote:
> Frustratingly, I can't get the geotiff packages to install.
> 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 to
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
Frustratingly, I can't get the geotiff packages to install. I have installed
libproj0-4.4.5-2mdk.i586.rpm, libgeotiff1-
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
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. O
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 be
On 11/11/03 at 8:22 PM 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 flying -- in Ca
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 multiple
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 sin
> -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 hav
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 hea
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 connectio
62 matches
Mail list logo