>> 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. > 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. 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. > 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. > This would then be modified or complemented by xml files for individual > airports and scripts. For an individual airport, the file could specify > just the general type eg GA, military, to help the heuristics, or possibly > the general traffic level, right through to full airline flight schedules > completely replacing the heuristic traffic for that airport. A custom xml > file for KOSH could specify a lot more arriving planes on certain days > without disabling the heuristics. Custom scenario scripts could disable > heuristic traffic at any airport or completely. For instance, your KSFO > arrival script could disable heuristic traffic into and out of SFO to avoid > my Cessna's going there! 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. > 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 :) > I'm coming round to the idea of merging AILocalTraffic and AIGAVFRTraffic. > The inheritance was rather ugly. I still think the difference between VFR > and IFR operation is probably sufficiently large to warrant a split, but > I'm not planning on implementing IFR stuff for a while. (Hoping someone > else will :-)) 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! > 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. Dave -- **************************** David Culp davidculp2[at]comcast.net **************************** _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
