Decoupling the AI traffic system: Difference between revisions

Jump to navigation Jump to search

Decoupling the AI traffic system (view source)

Revision as of 17:22, 8 March 2011

21 bytes removed ,  8 March 2011
m
Robot: Cosmetic changes
m (Bot: Automated text replacement (-aircrafts +aircraft))
m (Robot: Cosmetic changes)
Line 11: Line 11:
* "I agree that the approach you suggest, of starting with a single subsystem/module is probably the best way to start tackling this issue."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg09064.html]
* "I agree that the approach you suggest, of starting with a single subsystem/module is probably the best way to start tackling this issue."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg09064.html]


* "It'd be worth identifying which subsystems are the big time sinks (FDM? AItraffic?) to prioritise this." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18063.html]
* "It'd be worth identifying which subsystems are the big time sinks (FDM? AItraffic?) to prioritise this." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18063.html]


* "I think the main targets for parallelization are the rendering pipeline and various "add-on" systems, like the traffic manager."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16400.html]
* "I think the main targets for parallelization are the rendering pipeline and various "add-on" systems, like the traffic manager."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16400.html]
Line 19: Line 19:
* "This way, an instance of FlightGear needs to send the position of the aircraft it is responsible for to the server, and then it will receive the positions of any other aircraft (AI or human controlled) in the vicinity."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18503.html]
* "This way, an instance of FlightGear needs to send the position of the aircraft it is responsible for to the server, and then it will receive the positions of any other aircraft (AI or human controlled) in the vicinity."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18503.html]


* "Once that is fleshed out, we can worry about seeding additional AI aircraft into the world to make things more interesting. At that point we can decide how to fly them, script them, animate them, etc. But I think most of that should be handled on the server side.A single instance of flightgear would get the same information on other aircraft regardless of whether they are human or AI controlled."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18503.html]
* "Once that is fleshed out, we can worry about seeding additional AI aircraft into the world to make things more interesting. At that point we can decide how to fly them, script them, animate them, etc. But I think most of that should be handled on the server side.A single instance of flightgear would get the same information on other aircraft regardless of whether they are human or AI controlled."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18503.html]


* "And I envision a "client" that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this "client" really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes)" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18513.html]
* "And I envision a "client" that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this "client" really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes)" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18513.html]


* "my preference would be to control all the AI traffic in the server and not burden the core FlightGear code with it. Note that unless you are < 100' away from an airplane, there is no way you are going to be able to tell if it's running real flight dynamics, or some ultra-simple non-physics based engine that just moves the airplane along some predetermined route. 99.9999% of the time in civilian aviation, you should never get that close to an airplane."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18525.html]
* "my preference would be to control all the AI traffic in the server and not burden the core FlightGear code with it. Note that unless you are < 100' away from an airplane, there is no way you are going to be able to tell if it's running real flight dynamics, or some ultra-simple non-physics based engine that just moves the airplane along some predetermined route. 99.9999% of the time in civilian aviation, you should never get that close to an airplane."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18525.html]




Line 30: Line 30:
= Background Information =
= Background Information =
== 2002 ==
== 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. "[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08701.html]
* "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. "[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08701.html]


* "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'." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04952.html]
* "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'." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04952.html]


* "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.)" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04952.html]
* "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.)" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04952.html]


* "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." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04952.html]
* "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." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04952.html]


* "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." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08708.html]
* "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." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08708.html]
Line 49: Line 49:
* "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)." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18517.html]
* "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)." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18517.html]


* "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" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18440.html]
* "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" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18440.html]


* "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." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18437.html]
* "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." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18437.html]


* "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 Git tree until everyone forgets about them. " [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18446.html]
* "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 Git tree until everyone forgets about them. " [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18446.html]




Line 59: Line 59:
* "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 ?"[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26021.html]
* "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 ?"[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26021.html]


* "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" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26021.html]
* "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" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26021.html]


* "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." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26021.html]
* "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." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26021.html]
Line 89: Line 89:
* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13222.html]
* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13222.html]


* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13223.html]
* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13223.html]


* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13223.html]
* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13223.html]
Line 107: Line 107:
* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13249.html]
* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13249.html]


* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13252.html]
* "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." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13252.html]


* "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?"[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13213.html]
* "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?"[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13213.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]
* "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]
Line 118: Line 118:
* "Hopefully, once we start working on a new architecture, in which AI traffic is fed from a separate application into FlightGear, using the multiplayer system, hopefully much of that load will be offloaded from FlightGear. This could be run either on a separate computer, or using a network connection from the same machine..." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16075.html]
* "Hopefully, once we start working on a new architecture, in which AI traffic is fed from a separate application into FlightGear, using the multiplayer system, hopefully much of that load will be offloaded from FlightGear. This could be run either on a separate computer, or using a network connection from the same machine..." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16075.html]
* "refering to the idea of moving the core of the AI traffic code out of FlightGear itself, and communicate positions of other aircraft through the multiplayer system. We discussed this idea a few months ago, and IIRC, everybody seemed to respond fairly positive to the idea. " [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16077.html]
* "refering to the idea of moving the core of the AI traffic code out of FlightGear itself, and communicate positions of other aircraft through the multiplayer system. We discussed this idea a few months ago, and IIRC, everybody seemed to respond fairly positive to the idea. " [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16077.html]
* "FG multiplayer can support multi aircraft to fly together,but that means I need twenty persons to control twenty FG instances.My question is that how can I modify FG to adapt multi aircraft to run in one instance and I can switch from one aircraft to another to control it.When I control one aircraft ,the others could move automatically." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15027.html]
* "FG multiplayer can support multi aircraft to fly together,but that means I need twenty persons to control twenty FG instances.My question is that how can I modify FG to adapt multi aircraft to run in one instance and I can switch from one aircraft to another to control it.When I control one aircraft ,the others could move automatically." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15027.html]
* "I think this quite doable using the AIModels module. What is needed is a way to reinitialize the user aircraft structure from the data of the FGAIAircraft. In essence this is online plane switching, which everyone wishes for but is not implemented yet. I can see some logical issues though switching to a MultiPlayer controlled aircraft, so this needs be sorted out." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15029.html]
* "I think this quite doable using the AIModels module. What is needed is a way to reinitialize the user aircraft structure from the data of the FGAIAircraft. In essence this is online plane switching, which everyone wishes for but is not implemented yet. I can see some logical issues though switching to a MultiPlayer controlled aircraft, so this needs be sorted out." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15029.html]
* "your requirements except plane switching can be done quite easily using existing FG code. Online plane changing is a long wanted feature" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15029.html]
* "your requirements except plane switching can be done quite easily using existing FG code. Online plane changing is a long wanted feature" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15029.html]
Line 137: Line 137:
* "I would think that the big benefit of having an MP client feeding traffic is that we'd only need one traffic client for all the people connected to MP around the world." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13228.html]
* "I would think that the big benefit of having an MP client feeding traffic is that we'd only need one traffic client for all the people connected to MP around the world." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13228.html]
* "Personally, I think that out-weighs the performance implications for those people not connected to MP who want AI traffic and who have to run a client locally." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13228.html]
* "Personally, I think that out-weighs the performance implications for those people not connected to MP who want AI traffic and who have to run a client locally." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13228.html]
* "Having a separate client for traffic also has the benefit of allowing the user to prioritize my own flying over that of the AI traffic. I'd rather have the AI traffic stutter than my own aircraft." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13228.html]
* "Having a separate client for traffic also has the benefit of allowing the user to prioritize my own flying over that of the AI traffic. I'd rather have the AI traffic stutter than my own aircraft." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13228.html]
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/29270"

Navigation menu