Hi Paul,

I think I haven't been mentioned in this discussion yet but I started to
work on an ATC interface together with Dave. My original thought was that
it would be nice if the ATC system wouldn't have to differ between the
player and AI aircrafts, i.e. both type of planes send transmission in
text form (or the player maybe later even as wave files) to the ATC
system which are then analyzed by a parser and the answer is sent back as
in real life. I think this would fit in your ideas quite nicely. I also
thought about doing the ATC stuff in a separat program but I'm not
experienced enough with this kind of programming to know how to establish
the communication between the programs. Therefore, I started to do it
within FlightGear.

Cheers Alexander

> Hi David,
>    I have been reviewing the current situation, I am
> not here to try to take over and start redoing stuff,
> BUT what I am proposing is a radical change to what is
> men't by "Dynamic Scenario".  As said when I first
> joined in, I work for a very large flight simulation
> company, where we have a dynamic flight simulation
> server.
>
> I know there are two concerns with having a server:
> 1) Communicating with the main system (latency)
> 2) Some peopele don't have ethernet connections thus
> how will it work on a stand-alone machine (like a
> laptop).
>
> My proposal solution to the above questions are that
> we use "shared memory" or ethernet communications
> (user selectable), the main flight-gear app will not
> really contain the AI code, it will be done by the
> server, which updates lat, long, altitude, heading
> etc, this is sent to flight-gear that then does the
> displaying, sounds etc.
>
> The server (dynamic scenario) could then be used to
> manage plane routes, knowledge bases for the flight
> dynamics etc.
>
> comments?
>
> Paul
>
> ----- Original Message -----
> From: "David Luff" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, February 10, 2003 11:46 AM
> Subject: Re: [Flightgear-devel] Dynamic Scenario's
>
>
> > Hi Paul,
> >
> > As others have pointed out, there has been a small
> amount of AI traffic
> > development going on, and as the guilty party I'd
> better pipe up sooner
> > rather than later :-)  I'll describe what I've been
> doing and leave it up
> > to you whether you want to join in with that or
> start afresh.
> >
> > I've started from the premise that if there's going
> to be a number of
> > planes in the sky at once, then they should take up
> as few CPU cycles each
> > as possible.  Hence my vision is for very simplified
> mechanics of flying -
> > basically known ranges of speed, bank, climb etc for
> a given flight
> > condition, and a bit of smoothing of transitions in
> between.  Also only
> > very near AI planes to the viewer to be updated
> every frame, the rest to be
> > updated 1 per frame, and hence robust to variable
> times between updating.
> > I'm pretty sure that not everyone agrees with that,
> and that some would go
> > for coupled autopilot/fdms flying the planes as if
> they were another
> > user-fidelity flight-model, but the simplified route
> is the one I started
> > down.  Then my basic structure is that an AI manager
> iterates through a
> > list of AIEntity classes, and updates one per frame.
>  The AIEntity has the
> > minimum logic necessary to be drawn on the screen,
> and progressivly more
> > complex classes are derived from it - for instance a
> plane that can taxi,
> > then a light plane that can fly circuits could be
> derived from that and
> > would already know how to taxi, and then a light
> plane that flys from one
> > airport to another could be derived from that and
> would already know how to
> > fly circuits and taxi.
> >
> > Having said all that, I've basically hardly started!
>  I've got one
> > hardwired AI plane in so far, that can be seen by
> starting FlightGear with:
> >
> > fgfs --airport-id=KEMT
> --prop:"/sim/ai-traffic/enabled"=true
> >
> --prop:"/radios/comm/frequencies/selected-mhz[0]"=121.2
> --heading=10
> >
> > You do need to download the w120n30 scenery block as
> well.  This will start
> > you at El Monte behind a light single (no, NOT
> cheese!!!)  that takes off,
> > flys a circuit, and then taxis back to a parking
> spot.  It's great fun to
> > try following it round.  You can make it fly touch
> and go's by changing
> > line 54 in AIMgr.cxx: local_traffic->FlyCircuits(1,
> true); to a larger
> > value than 1.
> >
> > The limit of my ambition at the moment is to get
> light planes taxiing in
> > and out of and flying circuits around GA airports at
> the moment.  This is a
> > huge amount of work in itself - particularly the
> taxiing part, which also
> > involves writing an infrastructure to describe
> logical taxiway and parking
> > networks at airports, and tools to allow users to
> create/modify them.
> > There's absolutely no way I'm going to get time to
> do any planes that fly
> > from one airport to another in the next year or so.
> >
> > Anyway, the nub of the matter is that you can either
> join in with what's
> > started, where the best separation of work is
> probably to go for planes
> > that fly from one airport to another, or start
> afresh if you think I'm on
> > the wrong track.  If you start afresh bear in mind
> you'll need some
> > communication with the ATC system - both to send and
> recieve messages.
> > Interactive communication with tower control (You
> are number 2, extend
> > downwind for traffic on straight in / go-around I
> repeat go-around /
> > cleared to land etc) should be comming quite soon
> and you'll need to
> > respond to those.  If you do you're own taxiing
> system then communication
> > with ground control (in a programming logic sort of
> way rather than spoken
> > transmission) is a right can of worms since we need
> to communicate a
> > logical representation of a path to follow to and
> from tower and plane.
> >
> > James Turner has started some impressive work on
> implementing Flightplans
> > in Flightgear, and an interface to the DAFIF data
> which includes loads of
> > stuff such as airways, TMAs, SIDs, STARs, etc.  I'd
> thoroughly recommend
> > getting in touch with him before doing too much
> since you'll almost
> > certainly want to use his stuff.
> >
> > Whatever you do, any logic on how to fly from one
> place to another will be
> > useful whatever system to glue it in ends up getting
> used.
> >
> > Have fun,
> >
> > Cheers - Dave
> >
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>
> _______________________________________________
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to