durk wrote in Wed Aug 24, 2011 8:11 am:the first few milestones would be something like:
1). Enabling controllers for all stages of flight, and making sure the transistions between them work.
It would be great if the flexibility of the current system could at least be retained or possibly even extended, for example: your heavy use of the property tree and listeners for instantiating new traffic has made many things possible that you probably never were planning to support, such as AI traffic or AI guided missiles controlled by Nasal scripts.
If this pattern could also be transferred over to the ATC component, then we might eventually have ATC controllers scripted entirely in Nasal space, interacting with AI "pilots" controlled from Nasal. The C++ code would just provide the interface for Nasal scripts.
Given the small number of C++ developers working on the ATC/AI systems and given the complexity of creating a full working AI/ATC system, it would seem to be a sensible decision to move more and more parts out into scripting space where functionality can be developed, contributed and maintained by users rather than core developers?
The underlying C++ code is already fairly sizable and complex, so it would be great if it could be controlled from scripting space and down-stripped to just provide the required interface itself, that should also make your job much easier.
Some time ago we already talked about what it'd take to implement scripted pilots and scripted controllers in Nasal:
viewtopic.php?f=23&t=6807&p=66463#p66463
durk wrote:2). Honour data that is in the user aircraft's flight plan (currently I'm just using defaults).
3). Adding additional stages of flight: (go around, holding patterns, etc).
4). Enable the user to change his or her flight plans dynamically (choose alternate runways for departure / approach), change destination, change from VfR to IfR, etc etc.
Regarding "flight plans", I was just reading this on the atlas mailing list.
It seems there is some confusion regarding the different types and roles of "flight plans" supported by FG.
In the long run it would be great if the concept of a "flight plan" could become well-defined for all affected systems, so that the same code could be used for both, the AI/ATC systems, as well as the built-in route manager - then we would have just one single type of "flight plan", which would eventually also improve code reuse and sharing among related systems.
I think zakalawe mentioned plans along those lines some time ago, so it'd be good to keep those things in mind:
For instance, the addition of support for DPs, STARs and IAPs is something that would quite obviously be useful for all 3 components, AI, ATC and the route manager. Same applies to RNAV support, I guess?