Andy Ross wrote:
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
Erik Hofman writes:
Andy Ross wrote:
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
Andy Ross writes:
The existing hit list code works well and runs fast, so it hasn't been
tinkered with to try to fix this. The right interface would be a
way for the FDM to hand a bunch of line segments (not points; landing
gear can compress) to FlightGear and get back an indication of
Yes I would prefer an ac+fdm+autopilot solution strictly
for realism purposes -- but anything that instances planes controled by
FG needs to be hooked into my network code so that ac status updates can
be made visible to all other participants. AIPlane
definitly meets some of my needs
- Original Message -
From: David Luff [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 5:18 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
I not trying to put you off - I welcome all efforts in this area.
The only reason I'm not done with the fly together code is I'm packing
to
move from Kentucky to Texas this weekend
Good move. :-) ;-)
Where in Texas?
Jon
(Houston)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
On 11/13/03 at 8:13 AM John Barrett wrote:
The only reason I'm not done with the fly together code is I'm packing
to
move from Kentucky to Texas this weekend -- there is a uhaul in front of
my
apartment stacked to the ceiling with stuff and we still got loading yet
to
do today :)
I'm looking
- Original Message -
From: Jon Berndt [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 8:33 AM
Subject: RE: [Flightgear-devel] ACScript RFC (or FGScript ??)
The only reason I'm not done with the fly together code is I'm
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 11:48 PM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
I would like to request your ideas and wishes for an aircraft AI
John Barrett writes:
on (climbrate 100) {
elevators--;
}
on (climbrate 100) {
elevators++;
}
Look out below (and above) which ever comes first! :-)
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin
- Original Message -
From: John Barrett [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 8:45 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
on (speed = 140) {
elevators = 20; // pull
- Original Message -
From: Gerhard Wesp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:29 AM
Subject: Re: [Flightgear-devel] Multiplayer RFC -- wire protocol
spec --preliminary
Unless there are objections, byte order is
On 11/13/03 at 8:15 AM Curtis L. Olson wrote:
John Barrett writes:
on (climbrate 100) {
elevators--;
}
on (climbrate 100) {
elevators++;
}
Look out below (and above) which ever comes first! :-)
I used to try flying the Navion like
* [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
Unless there are objections, byte order is little endian, and floats
are intel FPU standard (ok -- i'm making it easy on the PCs that will
likely be used to run display clients :)
Is there any specific reason not to use human readable messages (i.e.,
ASCII)?
It's a waste of bandwidth.
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:24 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
Ok -- all you have done is state that takeoff is a procedure to be
John Barrett writes:
Very different indeed -- I'm trying to model the pilots deciscion processes
and interactions at a general level sufficient to write procedures to do
ANYTHING that can be done with a plane. Directly controlling an aircraft via
FDM just insures that the generic procedures
Gene Buckle wrote:
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
I have a need to develop a simulation of a terrain following system. The system is
presented a flight corridor (start point, end point, and corridor width) and need to
return the location, and elivation, of the highest point in that corridor. I
remember seeing some discussion a while back
John Barrett wrote:
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:24 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
[Dave's message]
--
This would be the easy way to supply the data. However, I think it
might be better if the power draw figure was part of the instrument
definition itself. This would require 2 new tags added to the xml files
that are used to define each instrument - I'm referring to the
configurationd
[Starting a new thread. John's reply was burried in the parent thread]
John Barret wrote:
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.
There is some support already in place
Norman Vine wrote:
Somethng like this is easy enough to implement with the current
hitlist code but ... I don't understand why the compressability of
the gear has any bearing on the point of contact. It is the AC that is
changing not the Terrain
Gear don't always compress perpendicular to
Andy Ross writes:
Norman Vine wrote:
Somethng like this is easy enough to implement with the current
hitlist code but ... I don't understand why the compressability of
the gear has any bearing on the point of contact. It is the AC that is
changing not the Terrain
Gear don't always
Jonathan Polley writes:
I have a need to develop a simulation of a terrain following system. The system is
presented a flight corridor (start
point, end point, and corridor width) and need to return the location, and
elivation, of the highest point in that
corridor.
Hi Jonathan
I
David Culp [EMAIL PROTECTED] said:
Ok -- all you have done is state that takeoff is a procedure to be followed
without defining the procedure (i.e. its hard coded and there is no
variation from that procedure)
Actually, I don't see a need for the AI airplanes to have brakes, elevators,
- Original Message -
From: Curtis L. Olson [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 10:15 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes:
Very different indeed -- I'm trying to
- Original Message -
From: Andy Ross [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 10:29 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett wrote:
- Original Message -
From: David Culp
- Original Message -
From: Andy Ross [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 10:46 AM
Subject: [Flightgear-devel] ACScript RFC (or FGScript ??)
[Starting a new thread. John's reply was burried in the parent thread]
John Barrett writes:
And I envision a client that handles multiple AI aircraft on behalf of a
server thats plenty busy enuf handling message passing and other management
functionality (this client really it could be considered part of the
server, but so much of the code is the same compared to
Curtis L. Olson wrote:
John Barrett writes:
And I envision a client that handles multiple AI aircraft on behalf of a
server thats plenty busy enuf handling message passing and other management
functionality (this client really it could be considered part of the
server, but so much of the code is
- Original Message -
From: Curtis L. Olson [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 1:19 PM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes:
And I envision a client that handles
Without a scenario loaded, or a
connection to a server, its just you all by your lonesome (which I had
thought was the situation given my experience loading up FG and flying
around with the default settings)
The AI already in place is little used because it's tied to one airport and
needs
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 2:12 PM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
Without a scenario loaded, or a
connection to a server, its just
On 11/13/03 at 1:48 PM John Barrett wrote:
Why is an interactive session by default generating AI aircraft without
a
loaded scenario to control those aircraft ?? The server should be
loading
the scenario. Having an airport spawn aircraft just because someone is
close
by the airport should not be a
John Barrett wrote:
Why is an interactive session by default generating AI aircraft
without a loaded scenario to control those aircraft ??
David Luff wrote:
Um, my plan was actually to have the sim spawn appropriate random
aircraft as the user gets near, and to have each airport populated
- Original Message -
From: Curtis L. Olson [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 3:34 PM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes:
Why is an interactive session by default
Andy Ross writes:
So long as you two don't share code at the top level, and instead are
simply using the same foundations, you won't care. By analogy: hand
two kids a box of legos and they can both play happily. Hand them the
same blocks in the form of a space cruiser and you have a fight.
John Barrett writes:
Why is an interactive session by default generating AI aircraft without a
loaded scenario to control those aircraft ?? The server should be loading
the scenario. Having an airport spawn aircraft just because someone is close
by the airport should not be a default behavior
On 11/13/03 at 12:50 PM Andy Ross wrote:
John Barrett wrote:
Why is an interactive session by default generating AI aircraft
without a loaded scenario to control those aircraft ??
David Luff wrote:
Um, my plan was actually to have the sim spawn appropriate random
aircraft as the user gets
On Thursday, 13 November 2003 00:36, Norman Vine wrote:
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
David Luff writes:
Younger (still destructive) kid went to bed early the other night, so I got
to play Lego (Duplo - the next size up bricks) with slightly older kid
only. My wife seemed somewhat surprised to find a tower stretching from
floor to ceiling when she got in, held in place at the
On 11/13/03 at 2:53 PM Curtis L. Olson wrote:
My little brothers would always destroy my lego creations the instant
I turned my back in order to build their own. Grrr ... :-)
Younger (still destructive) kid went to bed early the other night, so I got
to play Lego (Duplo - the next size up
I'm sure this subject has been brought up plenty of times but I think it would
be great to compile a list of all the features that we need the FG terrain
rendering system to support.
I want to keep this to features only - lets forget about the implementation
for the moment so we can at least
Paul Surgeon writes:
I'm sure this subject has been brought up plenty of times but I think it would
be great to compile a list of all the features that we need the FG terrain
rendering system to support.
I want to keep this to features only - lets forget about the implementation
for the
Paul Surgeon writes:
On Thursday, 13 November 2003 00:36, Norman Vine wrote:
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
Curtis L. Olson writes:
Paul Surgeon writes:
I'm sure this subject has been brought up plenty of times but I think it would
be great to compile a list of all the features that we need the FG terrain
rendering system to support.
I'll add in a few things:
me too
- Ability to cut
* Melchior FRANZ -- Monday 03 November 2003 08:36:
The first bug is quite old and was already reported a few
times, the second is a cosmetic problem, while the third
is more than a cosmetic problem: [...]
Could somebody please fix this?
m.
___
On 11/14/03 at 12:17 AM Paul Surgeon wrote:
I'm sure this subject has been brought up plenty of times but I think it
would
be great to compile a list of all the features that we need the FG terrain
rendering system to support.
I want to keep this to features only - lets forget about the
On Thu, 2003-11-13 at 07:55, Andy Ross wrote:
Norman Vine wrote:
Somethng like this is easy enough to implement with the current
hitlist code but ... I don't understand why the compressability of
the gear has any bearing on the point of contact. It is the AC that is
changing not the
Paul Surgeon writes:
I'm sure this subject has been brought up plenty of times but I
think it would be great to compile a list of all the features that
we need the FG terrain rendering system to support.
Norman Vine writes:
- Ability to cut in polygon models of airports.
Any cut in
Hello list,
Basically more for info and speculation than anything else.
I've just received an e-mail from a 'John Ridouts' that consists of
nothing but an attachment titled '~WRD0564.scr'
The reason I mention it here is that it was also addressed to a number of
people I recognise from this
52 matches
Mail list logo
