Decoupling the AI traffic system: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 87: Line 87:


* "Should not be necessary. All you do is to output the AI aircraft positions to all clients connected. The server itself fetches the data from the internet or whatever the source. No need to have a client for every AI plane."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13215.html]
* "Should not be necessary. All you do is to output the AI aircraft positions to all clients connected. The server itself fetches the data from the internet or whatever the source. No need to have a client for every AI plane."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13215.html]
= 2008 =
* "This would also be a great way to help start factoring out the current AI Traffic code, so that it may run separately from flightgear, possibly even standalone directly on the machine hosting a server!" [http://sourceforge.net/tracker/index.php?func=detail&aid=1849308&group_id=161928&atid=821811]
* "What's even more important: having such a capability would mean that we automatically end up with a very convenient high level tool to EASILY stress-test multiplayer servers and the underlying multiplayer code!! Of course, this capability should be optional and configurable to ensure that not arbitrary "multi-aircraft clients" can connect to a server and bring it to a breakdown by inserting thousands of traffic nodes. But if there is a way for authenticated/trusted clients to employ such functionality, it would be really awesome."[http://sourceforge.net/tracker/index.php?func=detail&aid=1849308&group_id=161928&atid=821811]

Revision as of 16:29, 16 March 2010

This article is a stub. You can help the wiki by expanding it.

Goals

Decouple the AI traffic system from FlightGear so that it may eventually become a standalone component, which would not only help improve runtime performance but also provide a possibility to handle AI state synchronization across multiple FlightGear multiplayer clients by feeding in all AI traffic via the FlightGear multiplayer server, so that all connected clients would get to see identical AI traffic, that is properly synchronized.

2002

  • "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, you might be able to dodge the processor load of full aircraft simulations, by having two computers with one having the human and a graphics display and the other having all the AI and no graphics display. Just a thought. "[1]
  • "What I would like to see implimented is a 'standard' DCS system (where DCS stands for dyanamic coordinate system which is industry lingo for objects that move in the scene ... their local coordinate system is 'dyanamic'." [2]
  • "I'm envisioning a DCS manager where you can register 'entities' with an associated 3d model and an associated 'behavior'. The behavior could be a preset path to follow, or something more AI-ish, or even something like JSBSim or YAsim (or perhaps entity positions could be driven externally from a server to produce a 'shared' world for collaborative flying.)" [3]
  • "The DCS system would take care of loading and attaching the 3d models to the correct place in the scene graph and removing them. It would call the update() routine for each of their "engines". And it would probably provide some sort of property interface to the positions, orientations, and velocities of these dynamics entities." [4]
  • "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 multi user stuff isn't ready quite yet, but it strikes me as being the most "obvious" way to implement it." [5]
  • "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 wasted." [6]
  • "Yes - you still need the "pilot" logic however it's done. It certainly won't be wasted."[7]

2003

  • "the protocol supports the idea of multiple aircraft sharing a single server connection for FG instances that are primarily handling a number of AI planes on behalf of a multiplayer scenario" [8]
  • "just one instance of FlightGear feeding the server with the AI traffic (just like it was a client, but in this case a very special one). This seems like a good approach because the AI generator could run on one, or several different machine(s)." [9]
  • "It seems to me like we're swimming in half-finished multiplayer/multiaircraft/network-data/network-interface implementations. What we need really isn't another one to plug into the mess, it's someone to *finish* the whole project" [10]
  • "I think it would make sense to have the server [or a separate client instance] handle any non-human controlled vehicles. It would keep the load off the client which already has its hands full doing a full systems simulation as well as doing graphics work." [11]
  • "FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either. The problem with some great new features is that they show up with code that is "ready" to integrate, but without the integration work done. So they languish in the CVS tree until everyone forgets about them. " [12]


2004

  • "Is there a way to create new instances of AIAircraft or another kind on the fly, just by adding some nodes in the property tree, or running a command from the telnet interface, that is, without modifying the source code ? Is there something planned in this direction ?"[13]
  • "I have plans (but very little time unfortunately) to add a property to the scenario file that will trigger the creating of an AIAircraft after a specified elapsed time, or periodically at a specified rate. This will be an inprovement" [14]
  • "The traffic scheduler creates the AIAircraft according to a schedule, so new instances of AIAircraft are created during the sim run, however I don't think this scheduler is set up to allow a user to trigger the creation of an AIAircraft using a key-stroke." [15]
  • "To create AIAircraft interactively will require a new module, and it will require that the newly created instance be given enough information to have a model and a fightplan." [16]
  • "Creating a traffic file is probably the closest you can get to creating AIAircraft instances dynamically during the simulation, but it is not possible at the moment to start traffic by interacting with the property tree. As David already explained, creating traffic is rather involved and probably requires new code. While I like the idea and can see some uses for it, I didn't really design the traffic manager with that idea in mind, and I don't really see how the code could be adapted to do this." [17]
  • "The idea would be to control the AI traffics ( creation, animation and deletion ) from an external program [or Nasal scripting] with the telnet interface. Someone ask me if it is possible lately, and I think he is prepared to do the required changes. I already suggested him to design new commands for creation/deletion and use the properties for animation. They would be 'run' from the telnet prompt." [18]
  • "Hmm, that's an interesting thought, because that was actually one of the possible mechanisms that I had in mind for the traffic manager. That is, have the schedules managed by an independent program that would communicate with FlightGear through a network layer."[19]
  • "In the end I decided not to go into this direction after doing some tests and finding that the the easiest way to do it was by adding the traffic manager as a subsystem to the main FlightGear program, specifically because the overhead of managing the schedules turned out to be a quite low. Doing this through a network remains an interesting option though..." [20]
  • "If you're going with the "independant program" route, then wouldn't it make sense to have the AI handled in that program - this way it could feed as many flightgear systems as you like, and they'll all have a consistent view of available traffic." [21]
  • "If handled in this way there'd basically be no difference between an AI aircraft, and another instance of flightgear running over the network. It also presents some interesting opportunities for ATC when you have a consistent view of the world like this." [22]
  • "Curt and I have agreed that we need some sort of DCS (Distributed Content System) that synchronizes instances of dynamic models between multiple running versions of FlightGear. That way a multi display setup of FlightGear will work with ATC/AIModels/AI Traffic (and MultiPlayer) code enabled." [23]

2007

  • "Yeah! How about setting up an mp-server feeding in real traffic? Or even just AI? So that every client would see the same traffic."[24]
  • "In order to feed in multiple aircraft that's probably the best approach - generate a multiplayer data stream for each aircraft you want to display - it'll benefit from the internal interpolation in the mp code too (I'm guessing you won't have 20 updates a second as would be fed from an instance of flightgear, so the interpolation will help immensely). " [25]
  • "I've been thinking about this idea for some time now; separate out the "intelligent part of the AI code" into a separate program, and run this as a dedicated standalone program that feeds aircraft positions into flightgear. This would solve many initialization problems, because the server could run completely independently of FlightGear itself. " [26]
  • "If somebody would care to assist in working out the details of the networking code, I'd be happy to investigate the possibilities of setting up a dedicated AI traffic server." [27]
  • "I really think, setting up a mp-client which feeds traffic is the right way to go. That way it does not matter, if the traffic is real or artificial. And best of all, flightgear itself does not need any changes at all." [28]
  • "While the feeded vehicle is in the air, there are no problems at all. But when approaching ground, or the vehicle is bound to the ground, there is one obstacle: The used terrain. In order to have the vehicle exactly on ground, the client must have the same terrain data which flightgear has. Therefor I thought of flightgear itself as the "feeder". If you somehow manage to get the terrain ripped of in some kind of library, it would be possible to build just any kind of feeder via the mp-protocoll." [29]
  • "I fully agree. To FlightGear it would be visible as multiplayer aircraft, coming in over the network. There would be some special cases to consider, but the general infrastructure of the multiplayer server could serve as a template for an AI server as well." [30]
  • "The traffic manager subsystem itself not so much as the AIModels system that eventually drives it. In this respect, there is still a lot of room for optimization. " [31]
  • "A particular problem with the integrated solution is that both the traffic manager and the AI models code occasionally need peaks of CPU activity, in particular during flightplan creation. Although it would be possible to spread the load across multiple frames, doing so is a lot harder within flightgear than doing this as a separate program. " [32]
  • "Assuming that AI aircraft behave in a reasonably sane fashion, you'd only need to take care of elevation points across the runways and taxiways. These data could be sampled straight from the flightgear scenery, and perhaps stored locally on the server machine."[33]
  • "One thing that a traffic server would require is metar parsing, so that AI traffic would make sensible runway selections. " [34]
  • "FWIW, I think that separating out as many FG subsystems as possible would be a very good way to go, especially in view of how CPU development is now solidly focussed on multiple core CPUs rather than ramping processing speeds, as was inevitable in the longer term." [35]
  • "Re this particular subsystem, it might be worth also thinking about handling some of the weather stuff i.e. 3d clouds, storms and thermals, so these are also consistant over MP." [36]
  • "There's no reason why it shouldn't run on the same box as FG - it could communicate via loopback or localhost. Ideally, FG would automatically start a local process to use if a net or lan server isn't specified." [37]
  • "A "virtual" client (perhaps a thread) for each aircraft that connects to the multiplayer server as a computer-controlled "player". Then I would connect to the server myself and perhaps fly around manually so I can see the other aircraft?"[38]
  • "Should not be necessary. All you do is to output the AI aircraft positions to all clients connected. The server itself fetches the data from the internet or whatever the source. No need to have a client for every AI plane."[39]

2008

  • "This would also be a great way to help start factoring out the current AI Traffic code, so that it may run separately from flightgear, possibly even standalone directly on the machine hosting a server!" [40]
  • "What's even more important: having such a capability would mean that we automatically end up with a very convenient high level tool to EASILY stress-test multiplayer servers and the underlying multiplayer code!! Of course, this capability should be optional and configurable to ensure that not arbitrary "multi-aircraft clients" can connect to a server and bring it to a breakdown by inserting thousands of traffic nodes. But if there is a way for authenticated/trusted clients to employ such functionality, it would be really awesome."[41]