Re: [Flightgear-devel] Re: AI merge
On 11/18/03 at 12:51 AM John Barrett wrote: Dont go too fast :) No chance of that - busy decorating the kids room, real work is spilling over into the evenings, and I've a sudden urge to hack at a taxiway editor! I'm working on my aiScript engine while I'm stuck in this hotel room house hunting Good luck, and make sure you buy one already decorated, or your coding time really will go down the tube! and dont have access to my other machines for working on my network code I should have the prototype engine up and running on top of PSL in a few days (I've parked the JS code for the time being, permanently if I can get a couple of new features added to PSL) FlightGear - an experiment to determine if an infinite number of monkeys typing at an infinite number of computers can produce an infinitely complex AI system ;-)) It occurred to me what a server would be *really* useful for the other day - load it up with full US airline timetables, and it should be able to generate approximately the right traffic at any portion of any airway or airport, with a bit of a random delay factor thrown in, and remove them when out of user range. I wonder if anyone has already compiled full airline timetable data in a freely available, digital form? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: AI merge
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 6:00 PM Subject: Re: [Flightgear-devel] Re: AI merge On 11/18/03 at 12:51 AM John Barrett wrote: Dont go too fast :) No chance of that - busy decorating the kids room, real work is spilling over into the evenings, and I've a sudden urge to hack at a taxiway editor! I'm working on my aiScript engine while I'm stuck in this hotel room house hunting Good luck, and make sure you buy one already decorated, or your coding time really will go down the tube! and dont have access to my other machines for working on my network code I should have the prototype engine up and running on top of PSL in a few days (I've parked the JS code for the time being, permanently if I can get a couple of new features added to PSL) FlightGear - an experiment to determine if an infinite number of monkeys typing at an infinite number of computers can produce an infinitely complex AI system ;-)) Thats my goal... infinite complexity through modular stucture :) Which brings up another issue... I'm I'm having a problem tracking down in aiPlane where everything happens so I can hook in and have my script engine drive the plane... want to work together to do a new version of aiPlane that will hook in with aiScript ?? For aiPlane, I guess I would need hooks for throttle, airspeed, turning the plane, position, etc... need to figure out an abstracted plane that the script can control, and the plane implementation will carry out a simple set of commands (turn, climb, dive, etc... would need to decide what level of abstraction we want to interface at) It occurred to me what a server would be *really* useful for the other day - load it up with full US airline timetables, and it should be able to generate approximately the right traffic at any portion of any airway or airport, with a bit of a random delay factor thrown in, and remove them when out of user range. I wonder if anyone has already compiled full airline timetable data in a freely available, digital form? I was actually lookin at that some today -- AirNav Systems will make the data available to you for $250 a month -- tell me where they source their data from and maybe we can sneak around them :) They have a nice semi-realtime ASD app that feeds off of FAA and other aircraft position reports Was thinking about doing a scenario that would have all the planes on that feed displayed using a multi-plane client to feed the server with data for all the active planes -- they have schedule and terminal/gate info available also -- would be better than just the schedules as this data would be actual traffic in real time ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: AI merge
It would definately make sense to unite our AI systems at some point. At the moment I'm carrying a stack of diffs locally to mine since I'm about half way through getting generic GA VFR traffic to appear randomly at controlled airports, so I'd rather not try a major merge and restructure just at the moment though! I'll jot down a few of my thoughts below though... A merge of AI systems at the bottom end looks easy. Our base classes are nearly identical. The merge at the top end, the manager, would be more difficult. I'd like the manager to be dumb as well, in that no scenarios are hard coded. In my view the manager should do nothing that it hasn't been told to do in a start-up XML file, like preferences.xml. The start-up instructions could be made broad enough to avoid having to hard-code scenario activity. For instance, the instruction to Make random AI appear around KSJC could be done something like this: ai ... entry methodrandom/method classlocal-traffic/class airportKSJC/airport /entry ... /ai I believe the manager should: 1) read its configuration file 2) instantiate the AI objects it's been told to 3) tell each AI object to update 4) check each AI object to see if it needs to be destroyed (i.e. it has reached the end of its flight plan and wishes to disappear) Besides a random instantiation method, there could be once, to have an AI object instantiated once at startup, whereupon it will do its thing; scheduled, to have an AI object appear at a specified sim-time, whereupon it will do its thing; repeat, to have an AI object disappear at the end of its plan and reappear at the beginning. Any intelligence in the AI objects would be contained within the object itself. The manager just manages. That's my idea anyway, and it would make it easy to have dumb and smart AI at the same time, including ships, cars, whatever. At the moment it doesn't work quite like that - FGAILocalTraffic contains a lot of the detail on how to fly that should be in FGAIPlane - I agree AIPlane should do the dirty work. It will contain a huge amount of code, but it will also make the derived classes much more pleasant to work with. Oh yes, and some of the class names are ridiculously ugly ;-) Perhaps if enough of the intelligence goes into AIPlane you'll only need one derived class, AITraffic. The differences between your present AILocalTraffic, AIVFRTraffic, AIIFRTraffic, etc., would then amount to different flight-plans (scripts) rather than different classes? The only trouble with this is that they might land on top of the user? Yes. Or you may land on them (i.e., the Saratoga). As a general observation, I think radio traffic is quite important. My impression from flying MSFS for a while was that I'd hear more traffic than I ever saw, even using the same airport. For me it's about 50/50. Most of the airports I fly into use different frequencies for different runways. It's been a while since I flew into KSFO, but I believe they use different approach frequencies for 28L and 28R, then, if in VFR conditions, traffic shares the tower frequency. It would be interesting to use your AIIFRTraffic to simulate PRM approaches, like they have at KMSP. This allows simultaneous ILS approaches to closely-spaced runways as long as both pilots monitor a common frequency with an approach monitor, who watches on radar and breaks an airplane out of the approach if one of them drifts too close to the other. That's something we don't get to practice much. Personally, I think that in the long term we should aim for all traffic using controlled airports to communicate and avoid sharing the runway with the user. At small airports they may be on the same frequency, but this is often not the case at larger airports. As far as sharing runways, it should be possible for the AI manager to be told to instantiate a stream of dumb traffic on a runway parallel to yours, and smart traffic on your own runway. That way, if you land on the wrong runway you may run into another plane operating on a different frequency, just like in real life. interesting to see how much simple heavy traffic we can get away with before frame rates suffer I noticed a difference in frame rates while flying formation with the A320 as opposed to the KC-135. A stream of high-poly objects may grind the sim to a halt. Fortunately the ships and cars are low-poly. What's your feelings on merging the systems - do you want to merge soon so we're not duplicating, or do you want to run them both in FlightGear for a while so we get a feel for how things might go and then merge them if appropriate? The easiest way would be to run them seperately at first, then merge the base class and manager at a later time. This way the code is available to all. I'll need either a) write access to FG CVS, or b) a co-developer who does. Dave --
Re: [Flightgear-devel] Re: AI merge
On 11/17/03 at 8:34 AM David Culp wrote: A merge of AI systems at the bottom end looks easy. Our base classes are nearly identical. The merge at the top end, the manager, would be more difficult. I'd like the manager to be dumb as well, in that no scenarios are hard coded. In my view the manager should do nothing that it hasn't been told to do in a start-up XML file, like preferences.xml. The start-up instructions could be made broad enough to avoid having to hard-code scenario activity. For instance, the instruction to Make random AI appear around KSJC could be done something like this: ai ... entry methodrandom/method classlocal-traffic/class airportKSJC/airport /entry ... /ai Thats a lot of files for every airport!!! I believe the manager should: 1) read its configuration file 2) instantiate the AI objects it's been told to 3) tell each AI object to update 4) check each AI object to see if it needs to be destroyed (i.e. it has reached the end of its flight plan and wishes to disappear) Besides a random instantiation method, there could be once, to have an AI object instantiated once at startup, whereupon it will do its thing; scheduled, to have an AI object appear at a specified sim-time, whereupon it will do its thing; repeat, to have an AI object disappear at the end of its plan and reappear at the beginning. Any intelligence in the AI objects would be contained within the object itself. The manager just manages. That's my idea anyway, and it would make it easy to have dumb and smart AI at the same time, including ships, cars, whatever. 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. 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!!). 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! 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). At the moment it doesn't work quite like that - FGAILocalTraffic contains a lot of the detail on how to fly that should be in FGAIPlane - I agree AIPlane should do the dirty work. It will contain a huge amount of code, but it will also make the derived classes much more pleasant to work with. Oh yes, and some of the class names are ridiculously ugly ;-) Perhaps if enough of the intelligence goes into AIPlane you'll only need one derived class, AITraffic. The differences between your present AILocalTraffic, AIVFRTraffic, AIIFRTraffic, etc., would then amount to different flight-plans (scripts) rather than different classes? 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 :-)) (Actually, that's not strictly true - I'm planning on implementing IFR ATC control for the user at some point, but not IFR AI traffic until well after that.) I noticed a difference in frame rates while flying formation with the A320 as opposed to the KC-135. A stream of high-poly objects may grind the sim to a halt. Fortunately the ships and cars are low-poly. Yes, we're going to need some low-poly models, possibly on a range
Re: [Flightgear-devel] Re: AI merge
for instance, the instruction to Make random AI appear around KSJC could be done something like this: ai ... entry methodrandom/method classlocal-traffic/class airportKSJC/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
Re: [Flightgear-devel] Re: AI merge
David Culp writes: for instance, the instruction to Make random AI appear around KSJC could be done something like this: ai ... entry methodrandom/method classlocal-traffic/class airportKSJC/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
