David Culp writes: > >> for instance, the instruction to "Make random AI appear around > > >KSJC" could be done something like this: > > > > > ><ai> > > > ... > > > <entry> > > > <method>random</method> > > > <class>local-traffic</class> > > > <airport>KSJC</airport> > > > </entry> > > > ... > > ></ai> > > > > Thats a lot of files for every airport!!! > > > Actually it's only one file. One part of one file even. >
OK then, it's a lot of entries for global coverage :-) > > > > I mostly agree with that, except that I think the random traffic should be > > more general. Take the example of a GA pilot going for a flight in real > > life. (S)he doesn't know what traffic will be encountered, but might be > > able to make a reasonable guess which airports might be busy, and which > > not. Likewise, AIMgr could create random traffic designed to fit > > heuristically with the airport/airspace being flown at/through. Things > > such as a very small chance of one other GA plane at an airport with a < > > 1000ft runway, a bigger chance of arriving and departing GA traffic and > > planes doing circuits at 1000 - 5000 ft runways, turboprops and 737s at > > longer runways, and medium and heavys at v. long runways. Runway lengths > > might need to be adjusted for altitude. As the pilot flew, planes would be > > generated with a random destination based on airports within a plausible > > range, and the plane would be removed if the user diverges from it. > > > This makes it less likely that your AIMgr and my AIManager could ever be > merged, unless we add another class, an AIScenario class (or something like > that) that is started by the AI manager. AIScenario would then create a > world of AI traffic to suit your scenario. That would leave the manager free > to do basic managerial work for all kinds of AI. That seems a reasonable possiblity. Whether the manager and random traffic generator are separate or part of the same class is a bit of a moot point really. > On the other hand, it > wouldn't be all that bad to have two different AI managers, since they > probably wouldn't be running concurrently. > But I'd *like* the default, random, AI to be overridable by user-specified or scripted AI either locally or globally. Locally would require them both to be able to work together. > > > That would be a base level of random traffic, settable from zero to sparse > > to dense (similar to real-life) to mega-dense (2020 traffic levels) (if the > > ATC will handle it!!). > > > I'd like to see that. > Lets just say that I'm shooting for very sparse at the moment! > > It seems that if the "smart AI" are aware of each other (are they?) they > wouldn't see a "dumb AI" object, as it exists outside of the scenario. They > could coexist, but they would also on occasion fly through each other. > At the moment the "smart AI" should avoid each other and the user on the runway, but there is no avoidance in-air. I plan on gradually increasing this by first adding avoidance on approach and in the pattern, and finally possibly a generic free-flight avoidance mechanism, depending on how cpu hungry it becomes. Having said that, on my last test the first plane to arrive simply landed on top of me instead of going around, so there's still bugs to be splatted!! > > > I guess there's a certain GA / airline split here, in that in real-life GA > > traffic is pseudo-random, whereas airline traffic is essentially scripted > > (by timetables). > > > Not just that. I'd also like to go practice approaches to a single dumb-AI > carrier without also processing the whereabouts and communications of a world > full of smart-AI Cessnas (although it would be interesting to see if the > computer can do it). I think the biggest difference in our vision of AI is > that you're looking at a per-world, or per-region, or at least a per-airport > scenario system, whereas I'm looking at a per-object AI system. I think they > can coexist, whether partially merged or not merged at all, and they can even > be run concurrently, with humorous results :) Yeah, but I'd make the carrier a special case scenario, and simply disable the default AI. > > > Hmmm, then you'll have an AI approach control and departure control? That > would be interesting. I would love to have an AI PAR approach! > Is that the one where the plane is basically talked down continuously. If so, I'm tempted! > > > Depending on where we put the traffic, we might well be able to run > > >bothsystems at once if you're concentrating on airline traffic and I'm > > > >concentrating on GA traffic - I could simply not generate GA traffic at any > >airports for which you've specified scripts for instance. > > I think we should leave it up to the user to decide. If the user is weird > enough to enable heavy VFR GA traffic and several individual AI airplanes at > the same airport then so be it. Comedy will ensue. Parallel development probably makes sense for now, and see what we think when there's some traffic in the sky... Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
