2,561
edits
Decoupling the AI traffic system: Difference between revisions
Jump to navigation
Jump to search
m
→Partitioning Rationale
| Line 14: | Line 14: | ||
* "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] | ||
* "From a multi-player standpoint. Any additional "AI" aircraft to be seeded into the world, should be handled by the server. The server will create and delete them, the server will fly them, script them, etc. etc."[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] | |||
* "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] | |||