snip a lot of good reasons for using an fdm/autopilot combination for AI
traffic from David Megginson and Alex Perry
(Following an OS re-install I can reply now!)
OK, I can see the point of wanting a proper simulation when within
reasonably close visual distance of the target. My concern was
On 10/7/02 at 5:50 AM ace project wrote:
I want to know how you guys want the property list to
be organised. Do we use something like:
/network/pilot[n]/callsign
/network/pilot[n]/position/ (lat,alt, etc)
/network/pilot[n]/[network-module-name]/ (module
specific stuff)
I will need this soon(3
I'm sure someone on this list has mentioned that they're developing an
interactive scenery editor, but I can't find a link to it either on the
Flightgear site or Google. Could someone post a link if they know it
please. I'm basically looking for the easiest way to position a cursor
over part of
David Luff writes:
OK, I can see the point of wanting a proper simulation when within
reasonably close visual distance of the target. My concern was that if
there were a lot of traffic being simulated, a lot of it known to the pilot
only through the radio communication, then using an
David Luff wrote:
I'm sure someone on this list has mentioned that they're developing an
interactive scenery editor, but I can't find a link to it either on the
Flightgear site or Google. Could someone post a link if they know it
please. I'm basically looking for the easiest way to
David Megginson writes:
That's a good point. The other option would be to cut down the Hz for
the AIs -- how low could we make it before the autopilot lost control
-- 10Hz? 2Hz?
you can easily experiment for yourself by playing with the
/sim/model-hz value
good luck !
Norman
David Megginson writes:
David Luff writes:
I'm sure someone on this list has mentioned that they're developing an
interactive scenery editor, but I can't find a link to it either on the
Flightgear site or Google. Could someone post a link if they know it
please. I'm basically
On 10/7/02 at 5:50 AM ace project wrote:
/network/pilot[n]/callsign
/network/pilot[n]/position/ (lat,alt, etc)
/network/pilot[n]/[network-module-name]/ (module
specific stuff)
I think that is fine, but ...
* I recommend you explicitly state that the 'n' for the same callsign
is likely to
Norman Vine writes:
David Megginson writes:
That's a good point. The other option would be to cut down the Hz for
the AIs -- how low could we make it before the autopilot lost control
-- 10Hz? 2Hz?
you can easily experiment for yourself by playing with the
/sim/model-hz value
David Megginson
David Luff writes:
I'm sure someone on this list has mentioned that they're developing an
interactive scenery editor, but I can't find a link to it either on the
Flightgear site or Google. Could someone post a link if they know it
please. I'm basically looking for
Still, regardless of how much get ripped out and rewritten eventually, its
still progress for now...
Definitely. If one of the computers taking part in the multiplayer network
has generated a bunch of AI aircraft, will they all be propagated to the
rest of the multiplayer members ? If so,
Curtis L. Olson writes:
David Megginson writes:
David Luff writes:
I'm sure someone on this list has mentioned that they're developing
an
interactive scenery editor, but I can't find a link to it either on
the
Flightgear site or Google. Could someone post a link if they know it
Norman Vine writes:
David Megginson
David Luff writes:
I'm sure someone on this list has mentioned that they're developing an
interactive scenery editor, but I can't find a link to it either on the
Flightgear site or Google. Could someone post a link if they know it
* Norman Vine -- Thursday 10 October 2002 17:36:
--fdm=ufo
Its nice to have reverse
Both the ufo and the carpet have reverse mode. :-)
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
On Thu, 10 Oct 2002, David Luff wrote:
Once you get this working we all ought to have a communal virtual fly-in at
David M or Alex's local airports sometime :-)
Now *THAT* would be truly impressive.
(No laughing when I bounce the landing!)
--
Jon Stockill
[EMAIL PROTECTED]
Curtis L. Olson writes:
There was a time when if you paused the sim, it would dump the local
lon, lat, elev to the console so you could copy/paste that into some
other file you were working on, but I don't think that feature has
survived the peer review process.
You can get that now by
Curtis L. Olson writes:
For what it's worth, I will be out of town Friday through Monday,
likely with minimal net access (if any.) So, please don't panic if
you email me and don't get a reponse back before next week. :-)
In Canada, this is Thanksgiving weekend coming up.
All the best,
I've been pulling information out of the DAFIF in different shapes and
trying to decide how we should model our own airport database. For
the external representation, we want something flexible enough that we
can add new types of data easily -- fixed-length records with
fixed-width fields just
Jon Stockill writes:
(No laughing when I bounce the landing!)
Why not? People laugh at me when I do it, so it's quite realistic.
It's even worse nowadays since the smokers have to go outside even
when it's not sunny and warm.
All the best,
David (who hasn't bounced for a few weeks now)
David (who hasn't bounced for a few weeks now)
Don't say that. You know what'll happen _now_ when you next fly ...
Also, although I've said it before, don't forget to practice a bit,
before flying to an airshow or other event with _many_ spectators !
Why can't we stick it into the scenery directories, but one directory
up from the tiles, so we have one file per 10degx10deg of planet.
That should ensure that FGFS doesn't need to load all that many files,
and just having the one file in the base package will allow initial use.
I've been
Alex Perry writes:
David (who hasn't bounced for a few weeks now)
Don't say that. You know what'll happen _now_ when you next fly ...
Also, although I've said it before, don't forget to practice a bit,
before flying to an airshow or other event with _many_ spectators !
Would you like to
Alex Perry writes:
Ok, I found the problem. You're computing the dynamic pressure in
psf and adding it to the static pressure in inHg to form the
total pressure. The attached patch is the simple fix to the source.
That's nasty, because the resulting airspeed is still correct under
Norman Vine writes:
Hmm... maybe this would help
untested - but it 'looks' like this will fix 'this' problem,
don't thin it will cause any new ones
It won't work because the properties in the *-set file will override
anything specified on the command line. I'm going to go in today and
* Alex Perry -- Thursday 10 October 2002 20:10:
Why can't we stick it into the scenery directories, but one directory
up from the tiles, so we have one file per 10degx10deg of planet.
That should ensure that FGFS doesn't need to load all that many files,
and just having the one file in the
Alex Perry writes:
David (who hasn't bounced for a few weeks now)
Don't say that. You know what'll happen _now_ when you next fly ...
Also, although I've said it before, don't forget to practice a bit,
before flying to an airshow or other event with _many_ spectators !
Actually, I
Alex Perry writes:
Why can't we stick it into the scenery directories, but one directory
up from the tiles, so we have one file per 10degx10deg of planet.
That should ensure that FGFS doesn't need to load all that many files,
and just having the one file in the base package will allow
David Megginson writes:
Alex Perry writes:
Ok, I found the problem. You're computing the dynamic pressure in
psf and adding it to the static pressure in inHg to form the
total pressure. The attached patch is the simple fix to the source.
That's nasty, because the resulting
Alex Perry writes:
Ok, I found the problem. You're computing the dynamic pressure in
psf and adding it to the static pressure in inHg to form the
total pressure. The attached patch is the simple fix to the source.
Once again: This wouldn't have happend if we'd use real units like
David Megginson writes:
I just checked in changed to fix the init-order problem for *-set.xml
files. My solution was blunt but effective. I simply parse all of
the system.fgfsrc, $HOME/.fgfsrc, and command-line options twice --
once before loading the *-set.xml file, to make sure the
David Megginson wrote:
Alex Perry writes:
Why can't we stick it into the scenery directories, but one directory
up from the tiles, so we have one file per 10degx10deg of planet.
That should ensure that FGFS doesn't need to load all that many files,
and just having the one file in the
On 10/10/02 at 12:02 PM Alex Perry wrote:
I wonder if the casual users appreciate all the work we're doing to
make the instruments less reliable.
Don't you remember the massive amount of whingeing (a couple of years ago)
when I stuck all the compass turning errors onto the DG instrument ?
The
Curtis L. Olson writes:
There is a *lot* of subtle things built into FlightGear that most
users probably don't realize. It might be interesting to make some
sort of tour of the flightgear sim which would highlight or point out
many of the more subtle features.
Why not post a version of
David Megginson writes:
Curtis L. Olson writes:
There is a *lot* of subtle things built into FlightGear that most
users probably don't realize. It might be interesting to make some
sort of tour of the flightgear sim which would highlight or point out
many of the more subtle
David Luff wrote:
On 10/10/02 at 10:42 AM Curtis L. Olson wrote:
Yes, and everyone knows that there is no such thing as magic carpets,
so running with the ufo FDM is a lot more realistic since the ufo is
based on real world data and uses actual real life sound samples.
Yes, and
Christian Mayer writes:
Once again: This wouldn't have happend if we'd use real units like SI...
I live in a (mostly) SI country and went through school learning SI
units -- I have to convert Fahrenheit to Celsius to know how cold it
is, for example. Still, converting to new units has its
Alex Perry writes:
That's true, but now I wonder ...
When we are in multiplayer mode, and I fly up behind some unsuspecting
pilot who is plugging along on autopilot, slightly above and at his
five o-clock position, can I pick up a pair of electronic binoculars
(what used to be the Z
Curtis L. Olson writes:
David Megginson writes:
I just checked in changed to fix the init-order problem for *-set.xml
files. My solution was blunt but effective. I simply parse all of
the system.fgfsrc, $HOME/.fgfsrc, and command-line options twice --
once before loading the *-set.xml
Alex Perry writes:
David writes:
I wonder if the casual users appreciate all the work we're doing to
make the instruments less reliable.
Don't you remember the massive amount of whingeing (a couple of years ago)
when I stuck all the compass turning errors onto the DG instrument ?
The
Andy Ross
Curtis L. Olson wrote:
Just a couple thoughts to consider. We are looking at 16-20,000
airports so we couldn't stuff them all in a single directory. Even
splitting them into subdirectories by first letter probably isn't
enough.
There are 17073 airports in the current
Norman Vine writes:
Curtis L. Olson writes:
David Megginson writes:
I just checked in changed to fix the init-order problem for *-set.xml
files. My solution was blunt but effective. I simply parse all of
the system.fgfsrc, $HOME/.fgfsrc, and command-line options twice --
once
On Thu, 10 Oct 2002, David Luff wrote:
Possibly true. Still, however the ai aircraft eventually end up getting
stored in the property tree and rendered, the actual logic of when to
appear, where to fly and how to communicate and interact with other traffic
will still be needed and won't be
I will still argue that the method used was and still is poor
There are those who want 'steam' and those who don't
I have advocated, all along, that both the correct and the cooked
values should be available through the property system. I also
think that all panel instruments, and panel
On Thu, 10 Oct 2002, Andy Ross wrote:
And remember, we can split on the first two bytes (K/S/KSFO.xml)
without any more difficulty (one extra line of code) and the whole
problem goes away.
From a processing point of view this makes sense - you don't need to store
extra information about the
Norman wrote:
[ ... indexing scheme involving spacial partitions and trees ... ]
With such a scheme we should be able to access any airport and
determine which airports are within some sane distance in much
less then a few tenths of a second order of manitude less at least
True, but
Doh, and I am flying to Minneapolis again this weekend! Not sure if I am
going to ANE or MIC yet. Need to get the charts tomorrow.
Ryan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L.
Olson
Sent: Thursday, October 10, 2002 10:45 AM
To:
Andy Ross writes:
Norman wrote:
[ ... indexing scheme involving spacial partitions and trees ... ]
With such a scheme we should be able to access any airport and
determine which airports are within some sane distance in much
less then a few tenths of a second order of manitude less
Andy Ross writes:
[* Geeky aside: reiserfs doesn't. It has a unique tail folding
feature where the last sub-block of files gets folded into a single
block with the tails of other files, so small files take space
proportional to their actual size. Very cool, although apparently
Norman Vine writes:
I think preferences.xml and the aircraft-set.xml files pretty much
cover any functionality that was intended to handle.
PLEASE DO NOT REMOVE the .fgfsrc option until
such time has we have a 'options editor'
I have not suggested doing so; I'm suggesting only
On Thu, 2002-10-10 at 11:54, David Megginson wrote:
Curtis L. Olson writes:
Don't say that. You know what'll happen _now_ when you next fly ...
Also, although I've said it before, don't forget to practice a bit,
before flying to an airshow or other event with _many_ spectators !
Norman Vine writes:
I will still argue that the method used was and still is poor
There are those who want 'steam' and those who don't
Sure, and we make both available through the property tree. If you
want to know the exact true heading, look at /orientation/heading-deg;
if you want to
On Thu, 2002-10-10 at 12:02, Alex Perry wrote:
David writes:
I wonder if the casual users appreciate all the work we're doing to
make the instruments less reliable.
Don't you remember the massive amount of whingeing (a couple of years ago)
when I stuck all the compass turning errors
On Thu, 2002-10-10 at 11:59, Christian Mayer wrote:
Alex Perry writes:
Ok, I found the problem. You're computing the dynamic pressure in
psf and adding it to the static pressure in inHg to form the
total pressure. The attached patch is the simple fix to the source.
Once
Jon Stockill writes:
Is there any sort of master database from which all this can be
generated? Or should we create one?
No and yes. Note that I'm discussing only the external format, not
the internal format someone might use in a SQL master repository (or
whatever).
That said, these are
Jon Stockill writes:
From a processing point of view this makes sense - you don't need to store
extra information about the location of the airfields, wher if as was
suggested before it's broken down by state, then presumably you need to
store the state for each and every airfield too,
Tony Peden writes:
In real life, it's also much harder to do a tail strike than it is
with the JSBSim 172 -- it's quite safe to pull all the way back on the
yoke to keep the weight off the nosewheel.
Hmm, downwash (or, more precisely, the lack thereof)
I cannot say. One thing
Ryan Larson writes:
Doh, and I am flying to Minneapolis again this weekend! Not sure if I am
going to ANE or MIC yet. Need to get the charts tomorrow.
Well if you go to KANE and happen to be about 3 miles east of the
airport, and happen to look down and see a big high school complex
with a
David Megginson
Norman Vine writes:
I think preferences.xml and the aircraft-set.xml files pretty much
cover any functionality that was intended to handle.
PLEASE DO NOT REMOVE the .fgfsrc option until
such time has we have a 'options editor'
I have not suggested doing
David Megginson writes:
Norman Vine wrote:
To sum up I think that the work that has been done to make the
'instruments' act like a C172 is fantastic but it SHOULD be an option
and not 'the way'
It should be not just an option but the default option, at least when
we're simulating
David Megginson wrote:
I cannot say. One thing we're not modelling yet is nosewheel
shimmy:
Does this really have to be modeled, per se? Until we get support for
force-feedback rudder pedals and seat cushions, the only thing we can
reasonably do is play a sound. That can be done already
Andy Ross writes:
Does this really have to be modeled, per se? Until we get support for
force-feedback rudder pedals and seat cushions, the only thing we can
reasonably do is play a sound. That can be done already with some
fancy thresholding (gating with /gear[0]/wow and groundspeed) using
David Megginson
Norman Vine writes:
I will still argue that the method used was and still is poor
There are those who want 'steam' and those who don't
Sure, and we make both available through the property tree. If you
want to know the exact true heading, look at
Norman Vine writes:
Yes thank you for finally making doable but it did take
a lot of simulated aluminium just _raining_ out of the sky ...
and a lot of rewriting code that just plainly ignored the
the 'true' values that were there
I'm pretty sure that the true values were accessible
Andy Ross writes:
I have limited experience here, but the nosewheel shimmy I noticed in
a friend's PA-180 was only a rumble. It didn't seem to effect the
orientation or handling of the aircraft.
If it's bad enough, the whole plane shakes (we've had trouble with the
nose strut on C-GPMR
I'm not sure what changed, but I can no longer start the c310u3a-3d
engines. They will fire and turn over, but as soon as I disengage the
starter, they spin back down and refuse to run. Also, they no longer
come up running by default.
Regards,
Curt.
--
Curtis Olson IVLab / HumanFIRST
On Thursday 10 October 2002 10:49 pm, Curtis L. Olson wrote:
I'm not sure what changed, but I can no longer start the c310u3a-3d
engines. They will fire and turn over, but as soon as I disengage the
starter, they spin back down and refuse to run. Also, they no longer
come up running by
On Thursday 10 October 2002 10:49 pm, Curtis L. Olson wrote:
I'm not sure what changed, but I can no longer start the c310u3a-3d
engines. They will fire and turn over, but as soon as I disengage the
starter, they spin back down and refuse to run. Also, they no longer
come up running by
Cameron Moore writes:
Dang. I was going to have you man the list admin duties. :-) I will
be away Friday and Saturday, so Sunday you guys may see some delayed
posts if I have to approve any.
Also while I'm here, I wanted to mention that I get around 3 spams per
day to the flightgear
Who emptied the fuel tanks?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of John Check
Sent: Thursday, October 10, 2002 10:43 PM
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] starting the c310u3a-3d
On Thursday 10 October 2002 10:49 pm, Curtis
On Friday 11 October 2002 12:05 am, Jon Berndt wrote:
Who emptied the fuel tanks?
Dunno. I checked a few revisions back and didn't see anything.
I'm committing wet tanks shortly.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of John Check
Sent:
On Friday 11 October 2002 12:08 am, John Check wrote:
On Friday 11 October 2002 12:05 am, Jon Berndt wrote:
Who emptied the fuel tanks?
Dunno. I checked a few revisions back and didn't see anything.
I'm committing wet tanks shortly.
I forgot to put it in the log message, but I also moved
Is this a side effect of no longer getting the C172 defaults?
Jon Berndt writes:
Who emptied the fuel tanks?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of John Check
Sent: Thursday, October 10, 2002 10:43 PM
To: [EMAIL PROTECTED]
Subject: Re:
On Friday 11 October 2002 12:15 am, Curtis L. Olson wrote:
Is this a side effect of no longer getting the C172 defaults?
That sounds like a reasonable deduction. I'm checking the rest
of the planes to see if we need to gas up. I noticed the yasim planes
have thier own definition for fuel
John Check writes:
Also, what happened to the runway lighting? I'm a little out of touch
since I've spent the last week (at least) installing Gentoo
It should still be there, isn't it? I have been working on building
more infrastructure for doing runway/approach lighting and working on
using
On Friday 11 October 2002 12:15 am, Curtis L. Olson wrote:
Is this a side effect of no longer getting the C172 defaults?
That sounds like a reasonable deduction. I'm checking the rest
of the planes to see if we need to gas up. I noticed the yasim planes
have thier own definition for fuel inside
Whats the deal with the x24b fuel wise? That's missing a consumables
section as are the shuttle and x15
??
The JSBSim config files have fuel loaded for the X15, the X24B, the C310,
the C172, etc. But NOT the shuttle (we just use it as a glider). I don't
know what this consumables thing it,
This coming Saturday is the annual safety competition for San Diego and,
as one of the organizers, I've been thinking about the spot landings task.
It occurs to me that FGFS should be able to do that really well, except
the touchdown report is minimal. How much hassle would it be, to have
the
I was going through the c172 variants and adding the electrical system
and I fired up the c172-larcsim. It's got a major problem. It just sits on the
runway no matter how much throttle you give it.
I took a quick look at the xml file in case it was something obvious.
I gave comparative analysis
John Check wrote:
I was going through the c172 variants and adding the electrical system
and I fired up the c172-larcsim. It's got a major problem. It just sits on the
runway no matter how much throttle you give it.
I took a quick look at the xml file in case it was something obvious.
I
Curtis L. Olson writes:
Don't say that. You know what'll happen _now_ when you next fly ...
Also, although I've said it before, don't forget to practice a bit,
before flying to an airshow or other event with _many_ spectators !
Would you like to buy a pair of slightly used C172
David writes:
I wonder if the casual users appreciate all the work we're doing to
make the instruments less reliable.
Don't you remember the massive amount of whingeing (a couple of years ago)
when I stuck all the compass turning errors onto the DG instrument ?
The simulated aluminium was just
Alex Perry writes:
* Alex Perry -- Thursday 10 October 2002 20:10:
Why can't we stick it into the scenery directories, but one directory
up from the tiles, so we have one file per 10degx10deg of planet.
That should ensure that FGFS doesn't need to load all that many files,
and just
On 10/10/02 at 5:42 PM Frederic BOUVIER wrote:
David Luff [EMAIL PROTECTED] wrote :
I'm sure someone on this list has mentioned that they're developing an
interactive scenery editor, but I can't find a link to it either on the
There is fgsd ( for FlightGear Scenery Designer ) at
1. I'm assuming we keep the airport database (but maybe omit runways
etc)
Then someone will want to teleport to a specific runway at a specific
airport. :-)
Yeah, but the runway-based user request is precisely why I stated that
the file is priority loaded ... so we get the runway
Curtis L. Olson wrote:
There is a ton of internal infrastructure stuff that is useful in the
geek sense ... property system, interfacing to external programs. The
ability to build instrument panels, electrical systems, 3d models,
animation, with absolutely no coding or plugins.
Many
On 10/10/02 at 8:38 AM Alex Perry wrote:
Definitely. If one of the computers taking part in the multiplayer
network
has generated a bunch of AI aircraft, will they all be propagated to the
rest of the multiplayer members ?
Now theres a scary thought! What happens if one multiplayer has
In real life, it's also much harder to do a tail strike than it is
with the JSBSim 172 -- it's quite safe to pull all the way back on the
yoke to keep the weight off the nosewheel.
Try playing with your CG in JSBsim; I routinely see aircraft with their
tail tiedown heavily abraded due to
On 10/10/02 at 10:42 AM Curtis L. Olson wrote:
Yes, and everyone knows that there is no such thing as magic carpets,
so running with the ufo FDM is a lot more realistic since the ufo is
based on real world data and uses actual real life sound samples.
Yes, and non-Americans know that there's no
On 10/10/02 at 6:13 PM Jon Stockill wrote:
Indeed - it'll be nice to have a quick and easy way of getting other
aircraft in the sky, however, I think from a long term point of view
automated traffic would be best managed by simply being a task which
appears as another remote user (yes, I know the
89 matches
Mail list logo
