Status of AI in FlightGear

Caution  Developer information: Some, and possibly most, of the details below are likely to be affected, or even deprecated, by the ongoing work on FGTraffic. This is because Durk is inclined to break away from the approach he took for the current AI traffic system. In his opinion, the code has become too clunky too be maintainable, he will try to spend a limited portion of his development time for bug fixing the current code, but please don't expect any major changes any more. The new approach he has in mind should surpass everything we currently have, but it's going to take some time until it's all implemented. To avoid conflicting efforts, you are advised not to start working on anything directly related to this without first coordinating your ideas with FlightGear core developers using the FlightGear developers mailing list. talk page..

the built-in AI is extremely simple, and there's no FDM used, and aircraft systems (Autopilot/Route Manager etc) are also not used, the hard-coded AI is agnostic to weather/turbulence bombable is bit more advanced, but works around these limitations in scripting space through scripted FDMs and pilots - it would be possible to create a script "bot" (pilot) that actually flies the thing, and that deals with failures. weather/gusts and wind shear should be possible to simulate through "advanced weather" (also scripted) failure management is meanwhile also scripted through galvedro's work: A_Failure_Management_Framework_for_FlightGear bombable is pretty sophisticated, and could also be extended with NN for better AI — Hooray (Wed Jun 25). Re: How advanced is FlightGear's AI?. (powered by Instant-Cquotes)

The whole "FGCanvas" effort thing is actually about something different, but it entails moving FDM, AP, RM etc into an "AircraftManager" class, which would be the main step required to allow AI aircraft to be also driven by FDM, AP and route manager (and possibly even an aircraft-specific Nasal instance) — Hooray (Thu Jun 26). Re: How advanced is FlightGear's AI?. (powered by Instant-Cquotes)

I went ahead to see how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably. — Hooray (Mon Jul 07). Re: FGCanvas Experiments & Updates. (powered by Instant-Cquotes)

AI Scenarios vs. Scripting

I have the feeling they're a bit of a legacy feature. The AI system is pretty limited in what you can do, so AI gets replaced by more versatile Nasal solutions. Compare tanker.nas with the AI aerial refueling demos - you can call the Nasal-spawned tanker everywhere when you're out of fuel, it interactively can provide you instructions to reach it, it automatically selects the tanker apprpriate for what you're flying,... Compare the thermal demo with Advanced Weather - the AI thermals are on pre-defined locations, so there's just zero element of surprise in glider flight, you have to do a lot of preparation up-front in order to get gliding in a different location - Advanced Weather just generates them anywhere in the world, merged right into the other weather patterns,... Nasal in static models makes them interact with aircraft, no need to pre-define AI or pre-load anything. So if not for the Carriers, I think we could safely get rid of the AI scenarios - Nasal-driven Wingmen would be far superior in interactivity. — Thorsten (Fri Feb 08). Re: AI-Scenarios. (powered by Instant-Cquotes)

I have to agree completely with Thorsten here. Scripting via Nasal makes it possible to move development of such features to the base package and delegate it to "user space" (contributors not core developers). So that core developers can focus on writing C++ core. Just look at examples like tanker.nas, fox2.nas, [url]Curt's fully autonomous f14 demo[/url] or flug's bombable addon: They all use Durk's AI traffic system as their backbone and foundation, but they provide totally different and novel features on top of it. In fact, there has so much more "AI" development taken place, just because the AI traffic system has become scriptable through the property tree. Using Nasal, it would be possible to create AI traffic that responds to ATC instructions, and even ATC controllers that control simulated and AI traffic So there's tons of flexibility here without C++ developers and their spare time being the bottleneck — Hooray (Fri Feb 08). Re: AI-Scenarios. (powered by Instant-Cquotes)

Basically you can steer/animate an AI object in 2 different ways: 1.)Use the existing scenario/AI and update heading, position via a nasal script advantages: less coding, good integration drawbacks: has to be loaded at startup, therefore omipresent 2.)The nasal/model placement like in tanker.nas drawbacks: requires more coding advantages: (un-)loadable at runtime, very flexible So it would be possibly the best way to generate an ai_plane.nas file similar to tanker.nas, that could be used for a wide range of applications. This script can then be steered via your own nasal AI script that is written for a specific purpose. The second method is already in use for some model animations/movements and works well, so you could concentrate on the "real" AI part. — glazmax (Thu Mar 25). Re: AI development (bots) / AI engine. (powered by Instant-Cquotes)

The AI system itself is not all that flexible, but the various scripted approaches (tanker.nas, bombable etc) do use it as the backend for placing traffic, even though all the control logic is then handled in scripting space. — Hooray (Thu Aug 29). Re: Suitability of this software to run a swarm simulation. (powered by Instant-Cquotes)

the code to do this is already readily available in FlightGear. $FG_ROOT/Nasal/tanker.nas is a good demonstration for code that iterates over the AI properties. Another good example is the multiplayer pilot list, which also iterates over the property tree. You only need to combine snippets from these two files to come up with what you need. — Hooray (Mon Nov 29). Re: Working with AI/Multiplayer properties. (powered by Instant-Cquotes)

the most flexible approach would be using scripting - FligthGear has a built-in scripting language (called "Nasal"), that can be used to control aircraft, and even to instantiate multiple AI aircraft, one of the most straightforward examples is the "tanker.nas" script, which creates a fully scripted AI tanker - that could be easily extended to create dozens of tankers, and obviously you could also change the 3D model if you wanted to. In fact, we have a separate addon, named "bombable" that adds "AI bots" to the simulator, for dogfighting purposes - none of that required C++ changes, it's all done in scripting space. Another users implemented a fully scripted missile (fox2.nas) that tracks aircraft - and we also have a feature for "wingman" support, too. Actually, you could even create scripted AI pilots and scripted AI ATC that interact with eachother - it's all doable, and doesn't require rebuilding FlightGear from source. — Hooray (Wed Aug 28). Re: Suitability of this software to run a swarm simulation. (powered by Instant-Cquotes)

For starters, I'd suggest to read through these: What_is_Nasal Nasal_for_C++_programmers You'll find a few analogies in those articles - but basically, Nasal scripting works exactly like JavaScript in your browser: it's an embedded extension language, that is integrated into FlightGear as a conventional FlightGear subsystem - during each frame, the Nasal interpreter gets its time slice to process scripts - which is why badly written scripts may slow down the sim and affect frame rate/frame spacing - in addition, Nasal supports dozens of FG-specific extension functions to do various FG-related things - which allows callbacks to be registered in the form of property listeners (which get invoked whenever a property is written to) or via timers (that may expire and trigger a callback). In addition, there's a standard library of Nasal library functions and a plethora of FlightGear-specific modules in $FG_ROOT/Nasal that greatly simplify coding stuff from scratch. To learn more about timers, see: List_of_Nasal_extension_functions#settimer.28.29 List_of_Nasal_extension_functions#maketimer.28.29_.28v._2.11.2B.29 To learn more about listeners, see: Using_listeners_and_signals_with_Nasal You can start playing around with Nasal by using the so called "Nasal Console": Nasal_Console — Hooray (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?. (powered by Instant-Cquotes)

Scripted AI in FlightGear

Another example is the "tanker.nas" script in $FG_ROOT which implements a simple scripted AI tanker for AAR purposes: [1] http://www.mail-archive.com/search?q=ta ... eforge.net And then we have the fox2.nas script which implements a fox2 AI missile using Nasal: [2] The "bombable" addon is completely implemented in Nasal and created multiple virtual pilots for dogfighting purposes: Bombable <iframe width="420" height="315" src="http://www.youtube.com/embed/LL7bdHrR8uI" frameborder="0" allowfullscreen=""></iframe> — Hooray (Mon Feb 04). Re: Possibility to run a fully automatized mission ?. (powered by Instant-Cquotes)

The simplest solution is probably using scripted AI traffic nodes. Note however that AI traffic cannot currently make use of any FDMs (JSBSim/YaSim), instead you need to come up with your own "pseudo FDM" in scripting space. You might be able to circumvent this restriction by coming up with a separate FDM and communicating with FG using sockets. We have a number of more or less complex examples for this. $FG_ROOT/Nasal/tanker.nas is the simplest test case you'll find, which basically spawns an "AI tanker" that can be used for refueling purposes. It would be possible to generalize the script some more in order to spawn an arbitrary number of aircraft. Also, you could equip them with a scripted control loop, so that each node can be controlled individually, i.e. by either setting a bunch of properties, or even by issuing ATC instructions. Curt has recently provided a more complex example. The most complex example for this technique is certainly the "bombable addon" which implements "AI bots" entirely in scripting space to provide "dog fighting" support. I would suggest to search the archives (wiki, forum, mailing list) and look into the aforementioned examples. Also, you'll inevitably need to look into the Nasal documentation, too: Nasal_scripting_language — Hooray (Tue Jan 03). Re: Multiple intelligent flyers. (powered by Instant-Cquotes)

It really doesn't take any longer than say 2-3 minutes to open the tanker.nas script, change the model file name to point to the 3D model of a bird, what you end up with is a "funny bird" flying at 330+ kts ground speed at 17000 ft AMSL (I took the first freely available bird model that I could find...): (see the linked image) As a next step, one could change the heuristics that move the bird (assuming that you don't want it to keep flying refueling patterns...), making it search actual thermals (local weather) would also not seem too complicated - it would just involve calls into the local weather code. Probably, you'll want to add some collision detection code then. Once this is working, you may want to animate the whole thing and probably change its size, too. Like I said, it's all perfectly possible with the tanker.nas script. — Hooray (Wed Sep 22). Re: Bird strikes script. (powered by Instant-Cquotes)

Scripted AI Missiles

Note  Also see Scripted AI Missiles

xiii is the developer of the F14b's fox2 implementation, the original thread was: Missiles with seeking capabilities post on the forum . To find related threads, see: [3] Custom dialog, nasal console etc. to fire a missile? post on the forum <iframe width="420" height="315" src="http://www.youtube.com/embed/UL7jQkl1qe4" frameborder="0" allowfullscreen=""></iframe> — Hooray (Sun May 05). Re: F-14B's Weapon System . (powered by Instant-Cquotes)

WRT generalizing things, you would first of all want to extract the part that interacts with the AI system and encapsulate that, so that the logic can be separately re-used and maintained. Scriptable AI and scripted FDMs are very popular and we still need to come up with good tutorials/howtos for those: [4] the next step would ideally involve coming up with an OO framework for modeling different types of missiles, possibly using subclasses for each missile type. And then, there's obviously also the FDM part, which would ideally be a separate class, too. — Hooray (Fri Dec 20). Re: F-14B's Weapon System. (powered by Instant-Cquotes)

a new Missile implementation would require people to implement the interface of the ScriptableFDM class and the MissileBase class. Preferably, such a generalization effort would be conducted "in the open", so that other people can have a look and provide constructive feedback, snippets or code - meanwhile, we do have enough people familiar with advanced Nasal concepts. Ultimately, xiii should have some say when it comes to reviewing and committing things - but this is something that should really be tackled by several people, to ensure that the component can be easily reused by other aircraft. A properly done design will support different aircraft, different FDMs, different missile types - but also use of these missiles in AI objects, such as in the bombable addon. — Hooray (Fri Dec 20). Re: F-14B's Weapon System. (powered by Instant-Cquotes)

AI ATC vs. AI Pilot Interactions

I cannot think of a single C++ modification necessary to come up with a pretty compelling prototype doing scripted ATC/AI interaction. Creating such a demo should be between 500-800 lines of code, e.g. by adapting existing sources - and you'd end up with two classes for creating AI pilots/controllers in scripting space. — Hooray (Tue Jan 13). Re: Anyone here play FSX?. (powered by Instant-Cquotes)

it seems this should already be possible to some extent without any significant changes to the C++ source code, i.e. it should theoretically be possible to drive AI traffic largely by using Nasal scripts (see for example tanker.nas in CVS). In other words, anybody interested in making AI traffic fully ATC aware (in the sense of properly responding aircraft), would mostly have to do something along the lines of: set up an instance of a Nasal driven AI aircraft (see tanker.nas in CVS) register a listener to the chat property in order to parse chat (ATC) messages inside the registered listener, look for matching callsign of the corresponding aircraft (to see if transmission is relevant) if callsign is correct, start parsing/validating the transmission (i.e. "HY77: Descend and maintain FL50") acknowledge reception of transmission to virtual ATC directly set the target-* properties under /ai/mod...li> This scheme could be extended to manage a whole number of Nasal driven AI aircraft, i.e. using an "ai-pilot.nas" script. Similarly, the same thing may work the other way around, i.e. for AI aircraft scripts to write to the chat property in order to talk to the AI traffic system to request a clearance or vectors. Most of this stuff is directly possible and requires few changes or additions to the C++ code. Just the possibility of using Nasal to script AI aircraft behavior patterns is extremely useful and powerful. (One could even implement the AI ATC backend using Nasal by using the same approach, but that isn't as interesting due to the performance issues involved) — Hooray (Wed Feb 24). Making AI traffic & ATC work together. (powered by Instant-Cquotes)

Learning AI

most everything is possible here. Just a little damper, Bombable is not really supported and imho wasn't conceived with software architecture in mind. I think it would be better to think on a robust and modular AI implementation so any other existing or future piece could use it without requiring Bombable. This doesn't say that Bombable couldn't use it. — xiii (Fri Jul 06). Re: Possibility of incorporating "learning" AI?. (powered by Instant-Cquotes)

It is certainly possible (like xiii said already), however it will require a solid background in AI and coding. It could definitely be implemented without touching any C++ though (i.e. using scripted Nasal code). I am disagreeing a little with xiii regarding the feasibility of using the bombability package for this, it's actually pretty well-written and well-commented source code. However, it is obviously a huge and complex piece of software. Just understanding how everything works, will take weeks or even months. In other words, it might be simpler to start out with something standalone - i.e. based on the tanker.nas example, so that you could first create an AI bot using NN which controls the tanker (or some other aircraft) and then consider integrating this with the bombable package later on. — Hooray (Sun Jul 08). Re: Possibility of incorporating "learning" AI?. (powered by Instant-Cquotes)

Bombable is definitely large & complex and though I'm interested in continuing to develop it I am also very limited in my spare time available right now. Flip side is, it could written (in fact probably SHOULD be written) as a completely stand alone module that just reads the location & other info from the property tree for the main AC and the AI AC of interest, and gets the general geographical and other information it needs to navigate the through the regular FG functions and the property tree variables for that sort of thing. Then you could develop some kind of API type thing to communicate with Bombable where the AI pilot module puts the current piloting info into the property tree (or just a nasal data structure, probably better for speed), including info like: which direction/how much to turn/turn rate which direction/how much to climb or dive/climb or dive rate whether to speed up, slow down and by how much, and rate Also right now Bombable implements loops as a special/separate routine - but they are easy enough to trigger with the same API type of approach, just send the data along via the API to say 'start loop' and a few parameters to define what the loop will do. — flug (Thu Aug 02). Re: Possibility of incorporating "learning" AI?. (powered by Instant-Cquotes)

Bombable could then read these nasal variables and/or the property tree or however the module-to-module communications API is worked out, and take the appropriate action. This would be pretty simple to implement just because Bombable is already doing something very similar to this, but it uses its own internal logic to make those decisions about turning, climbing, diving, looping, etc. It could just as easily take those cues from an outside module. The only other things that Bombable is currently using for AI aircraft decision-making are (1) weapons hits and near hits on the AI/AC, (2) overall AI/AC damage level, and (3) in the last version I implemented some code to simulate the AI/AC's fuel situation (with good fuel reserves the AC will attack aggressively, when fuel gets low it turns tail and slows down to conserve fuel). Those things could easily be implemented via the AI module as well, with info passed back & forth via the property tree or a nasal data structure. There are only a few simple parameters for all of those items. So--I think this *could* be done with Bombable as a completely separate module that only interfaces with Bombable via an API type interface and furthermore, the API would be pretty simple. I think. (Famous last words, I know!) — flug (Thu Aug 02). Re: Possibility of incorporating "learning" AI?. (powered by Instant-Cquotes)

The other flip side is, even if this is the long term plan it might still be smarter to start by implementing this same kind of an AI system (including the idea of an API-type interface that would allow the new AI piloting module to get needed info from other modules as needed and transmit the piloting instructions back to another different module that would do the actual piloting) but choosing a much simpler task for the first project. Then once the basic ideas have been worked out and are functional, tackle the much more complicated project of making a convincing AI fighter pilot module--which, really when you think about it, is what is needed for Bombable. Making an complete, realistic AI fighter pilot module is a pretty daunting project, really! The only thing that makes me think it is even possible at all is that the current Bombable pilot AI really only has a very, very few basic behaviors (attack in certain situations, evade in certain situations, do a loop in certain situations, retreat in certain situations--that's about it) and it really works much better than I ever imagined it would, given that absolute simplicity and complete unsophisticated-ness of the AI pilot model it's using. — flug (Thu Aug 02). Re: Possibility of incorporating "learning" AI?. (powered by Instant-Cquotes)

we should probably consider this a long-term goal, and then it would make sense to extract the AI control code from bombable into some separate "ai.nas" module, i.e. splitting up bombable into separate files. So that some of these could eventually be moved to the Nasal standard library directory in $FG_ROOT/Nasal, this is where we could then have a separate "ai.nas" module that allows controlling AI objects via the property tree. And another "pilot.nas" module which uses the ai.nas module. It should definitely be simpler to do this with some standalone aircraft, or maybe just the tanker.nas module. So that we could tackle this task separately, reuse as much of the bombable code as possible, and re-integrate the results later on via some sort of API, like you say. — Hooray (Thu Aug 02). Re: Possibility of incorporating "learning" AI?. (powered by Instant-Cquotes)

Custom "pilot" implementations could then be provided for different purposes, i.e. by reimplementing an abstract "pilot" base class and overriding functionality as required. Currently, the major showstopper is probably the complexity of the whole system, and having to understand it in its entirety, if bombable could be split up into separate modules, that should be made easier - also, adding the bombable package as a Nasal subsystem (sub module) to the base package should be easier then. Also it's worth mentioning that there have been discussions on exposing the autopilot/route manager system and the FDM system to Nasal space via the property tree and/or new Nasal extension functions, that could also help to make some old code obsolete, i.e. because a real autopilot or FDM could be used for scripted AI traffic eventually. — Hooray (Thu Aug 02). Re: Possibility of incorporating "learning" AI?. (powered by Instant-Cquotes)

Neural Networks

the AI in its current form is fortunately still hard coded and not based on neural networks, otherwise they may even predict your actions/evasive maneuvers — Hooray (Thu Jul 08). Re: AI & MP Dogfighting now working! Bombable ships, aircraft.... (powered by Instant-Cquotes)

If you know Nasal, you could certainly teach bombable to become a bit smarter, i.e. by adding support for standard combat maneuvers (like you mentioned). In its simplest form you could code a state machine that responds to standard situations with a randomly chosen standard response (and maybe some dynamic variation). It would be a matter of coming up with a state machine implementation in Nasal so that the AI can match up situations against suitable responses. It is definitely possible. I was in fact talking to flug a while ago about adding neural network-based AI to bombable. If there are enough people interested in this aspect of making bombable even smarter, then we could certainly come up with some more challenging AI bots. — Hooray (Tue Oct 11). Re: AI & MP Dogfighting now working! Bombable ships, aircraf. (powered by Instant-Cquotes)

I just looked into bombable's Nasal code, and it seems really not only well commented but also pretty well structured and generalized already, and I think another possibility to balance the whole experience would be to provide an option for setting up AI bots (or wingmen) to help you fight the bad boys. Pretty much like AI bots that help you defend/protect an objective - while helping fight other AI bots. One possible method would be to set up an option to spawn friendly forces on demand. To come and help you. Either using a hotkey or a GUI dialog. They could either be spawned at a configurable fixed position (i.e. KSFO) or within a configurable range of your current position (say 20 miles). There is also some good information available on creating autonomous dogfight agents: CREATING A DOGFIGHT AGENT: The design and implementation of a fully autonomous agent that can fly an airplane during a one-to-one dogfight. — Hooray (Fri Jul 09). Re: AI & MP Dogfighting now working! Bombable ships, aircraft.... (powered by Instant-Cquotes)

Basically, the technique is now called "adaptive control systems", which resulted in "self-reconfiguring bots" that could really learn things like controlling a simulated aircraft. This "learning" was based on a "punish/reward" system, and these agents were actually able to cooperate to a certain degree, to achieve their goals. In fact, these "Norns" were even so good at doing their job in the simulated world, that they were immediately used to fly real aircraft, namely UAVs — Hooray (Fri Jul 09). Re: AI & MP Dogfighting now working! Bombable ships, aircraft.... (powered by Instant-Cquotes)

We talked about this a number of times, and the bombable developer (flug) repeatedly indicated an interest in adding this — Hooray (Sat Jul 07). Re: Possibility of incorporating "learning" AI?. (powered by Instant-Cquotes)

I like this idea a lot. One basic problem is that Bombable is basically sitting on top of the FG AI flight system, which is indeed designed to make aircraft fly "like airliners". But, especially if there is interest to make like a neural net type intelligent/learning system for AI fighter aircraft I think both the Bombable and Flightgear problems could rather easily be solved. The changes that would be required in FlightGear's C code are not that difficult, I believe. — flug (Fri Oct 14). Re: AI & MP Dogfighting now working! Bombable ships, aircraf. (powered by Instant-Cquotes)

Right now, the Bombable aircraft only do three things: 1. Steer directly towards you if you are within their detection range (and steering towards you means, both in heading and altitude) 2. Wait until they have passed you by a certain distance to steer back towards you 3. Dodge if you shoot close to them or hit them They also try to avoid crashing into the ground a few other basic things like that. Considering the very, very basic nature of their behavior programming, they actually engage in some pretty complex behavior. — flug (Fri Oct 14). Re: AI & MP Dogfighting now working! Bombable ships, aircraf. (powered by Instant-Cquotes)

However it is only (and is only intended to be) a proof of concept--that we can control the AI aircraft within FG, using fairly simple nasal scripting and pretty simple behavior patterns, and make some pretty interesting behavior out of it. I think if we were to implement an idea like Hooray's we could have some very interesting AI aircraft flying indeed, and it probably wouldn't need to be that hard or complicated. As I've mentioned in a few other messages, Bombable is always limited by FG's native AI flight system, which is very sedate both as far as turning and (even more so) climbing & diving. It's really designed to model airliners flying sedately from there to there & it will take just a few changes to the underlying C code to make more complex & aggressive maneuvers possible. — flug (Fri Oct 14). Re: AI & MP Dogfighting now working! Bombable ships, aircraf. (powered by Instant-Cquotes)

Controlling the main Airplane

I'd suggest to get started by looking at the tanker.nas script instead - fox2.nas, the f14b demo and the bombable script are much more sophisticated, while tanker.nas is really pretty simple and straightforward: https://gitorious.org/fg/fgdata?p=fg:fgdata.git;a=blob;f=Nasal/tanker.nas;hb=01781f83715d90b6bf2df5c6210f766d0090083d — Hooray (Thu Sep 19). Re: How would I go about controlling an airplane with nasal?. (powered by Instant-Cquotes)

That would be great - but you'll probably want to look at tanker.nas for now, and look up the various APIs used there (see the wiki). The other examples are a little more involved. Also, it will be important if you are going to control the main aircraft, or some form of AI aircraft - because properties may differ then ... — Hooray (Thu Sep 19). Re: How would I go about controlling an airplane with nasal?. (powered by Instant-Cquotes)

If this is all about "bots" controlling aircraft, then you can do this already. Take for example a look at another discussion a couple of days ago: [5] (should probably also be moved to the new AI sub forum), where I roughly sketched out how to use Nasal to control an aircraft. So this could then be used to create such "bots" (scripted pilots) for aircraft by using Nasal. — Hooray (Sat Mar 20). Re: AI development (bots) / AI engine. (powered by Instant-Cquotes)

you can simply look at the autopilot dialog of your aircraft (e.g. c172p, b1900d or 777) - sometimes, looking at the cockpit panel may also make sense (MCP) - otherwise, you can then simply use the autopilot system to control the aircraft, which also includes support for flying complete routes via the built-in route manager, for details, see: Autopilot These are just XML files (GUI dialogs in $FG_ROOT/gui/dialogs or somewhere in $FG_AIRCRAFT - if customized) - so you can simply open those files and look up the properties for the various autopilot modes that you want to use (heading hold, wings level, altitude hold etc). Equally, the route manager is well-documented: Route_Manager Route_manager_internals So, basically, you really only need to set properties via setprop/prop.nas to control the route manager and/or autopilot, which will in turn allow you to control the main aircraft - this is much more straightforward than controlling AI traffic, because all these hooks aren't currently exposed yet. — Hooray (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?. (powered by Instant-Cquotes)

you will mainly use the autopilot to control the aircraft (since it has a real FDM it's kinda hard to control), and we would definitely recommend one with a developed autopilot (the 777s are really excellent with everything and has a good autopilot with all features you want). I don't fly in aircraft a lot, and like only three times with an autopilot, so I can't recommend any other aircraft with good autopilots. But one option with the 777 is that you could potentially use Nasal to dynamically edit routes that the aircraft just flies – not much work there. Another approach would be manually adjusting the autopilot parameters (like heading hold, bank angle, and stuff like that) through Nasal feedback algorithms for aircraft that don't have a.route manager. You could also couple this with the XML autopilot (now called "property rule") system to have real PIDs, easy lowpass, etc. — Philosopher (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?. (powered by Instant-Cquotes)

there are two aspects to Nasal: that of interaction with itself and with the property tree. For your purposes, the property tree is going to be your communication with the wider FlightGear code. Nasal also can use its own mechanisms to interact with different things (file system, route manager, fgcommands, ...). In interest of the web browser analogy, XML in FlightGear is like HTML. Specifically it is responsible for setting up much of the property tree that FlightGear's subsystems act off of. David Megginson (creator of FG's property tree) once said that "XML should provide the nouns, Nasal should be the verbs" (or something, that isn't a direct quote) – so PropertyList XML is really good at providing data that Nasal can work off of. For like the fox2.nas script, this means that ideally all of the specific data about the missile would be taken from Nasal and stored in an XML file (which would be loaded by the Nasal file and the data would be copied over). — Philosopher (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?. (powered by Instant-Cquotes)

Curt posted on his blog this article about circle holding which will be of interest: http://gallinazo.flightgear.org/uas/spi ... r-control/. If he isn't too busy, you could ask him about some more of the details or ask where to learn about the algorithms he used. I don't have time to reread it, but I think he used like the rascal or other small aircraft and a Nasal algorithm consisting of (I'm just guessing here) bank hold (to set up an approximate radius and to turn in a circle) and bank angle correction (to get the right radius, to stay on track and correct errors, etc.). He also mentions a lot of control mixing in the article required to maintain the fine balance of throttle/speed, bank angle/turn radius, and pitching/altitude, so it was probably more sophisticated than that. — Philosopher (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?. (powered by Instant-Cquotes)

he algorithmic side of things should be fairly straightforward in this case, because it's all hidden in the depths of the AP/RM systems, so from a high-level standpoint, it's really nothing else than using setprop() to switch between AP/RM modes and then setting the corresponding parameters (altitude, speeds, heading, course etc). You could even fly a holding pattern automatically like this, without ever having to do any fancy maths. — Hooray (Fri Sep 20). Re: How would I go about controlling an airplane with nasal?. (powered by Instant-Cquotes)

Fully Automatized Missions

Yes, it is possible "to make" such a mission - but you will literally have to MAKE it by writing a script to outline all required steps for your aircraft. Curt did that a while back for the f14b, which did a fully automated carrier approach using just Nasal scripting: http://diydrones.com/profiles/blogs/uas ... simulation http://www.mail-archive.com/flightgear- ... 33987.html [6] <iframe width="420" height="315" src="http://www.youtube.com/embed/cvbtSG9cy20" frameborder="0" allowfullscreen=""></iframe> — Hooray (Mon Feb 04). Re: Possibility to run a fully automatized mission ?. (powered by Instant-Cquotes)

C++ Issues

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. — Hooray (Wed Aug 31). Re: New ATC / AI interactions. (powered by Instant-Cquotes)

Note that I won't oppose other ideas, and if you have nasal code that would require certain components of the AI system to be shutdown, or need specific hooks to interface certain C++ components with nasal bindings, than I would certainly be willing to support that. — durk (Wed Aug 31). Re: New ATC / AI interactions. (powered by Instant-Cquotes)

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? — Hooray (Wed Aug 31). Re: New ATC / AI interactions. (powered by Instant-Cquotes)

James and I have plans to unify our approaches. One of the reasons why I have put my plans to implement SIDs and STARs, as well as more complicated airway following in flight flightplans on the back burner is to give James some time to finish is work on the route manager. This way we can work towards a common format that is shared between the route manager and the AI system. — durk (Wed Aug 31). Re: New ATC / AI interactions. (powered by Instant-Cquotes)

I guess, it might be a good idea to eventually start collecting a list of things that would need to be changed, i.e. like what Thorsten did for prioritizing core-changes to improve his local weather system using the wiki. — Hooray (Sat Oct 15). Re: AI & MP Dogfighting now working! Bombable ships, aircraf. (powered by Instant-Cquotes)

I was looking into the code, and I think this is a "problem" that can be easily solved by disabling some of durk's AI traffic code, basically it is simply "too smart" and making too many assumptions about the type of aircraft/flights it is controlling, at the moment. Disabling code should be merely a matter of introducing a bunch of new properties to make such assumptions optional. Sort of like a more pure, or a "raw" controlling mode where everything related to "airliner assumptions" is simply disabled. I think, durk won't mind that at all, because it's not really introducing new code or touching existing code, it would by default keep everything "as is", but only introduce a bunch of control properties to disable some of these defaults. For your Nasal code, that would basically mean to set those new properties and handle those things in Nasal space instead. Maybe, you could come up with a list of "airliner-characteristics" that you would like to disable/control yourself eventually? — Hooray (Sat Oct 15). Re: AI & MP Dogfighting now working! Bombable ships, aircraf. (powered by Instant-Cquotes)

this is helpful. I've never managed to get the target-hdg or target pitch methods to work. However, the solution to most of the problems I've outlined above would be to create 1. a new heading/directional mode that disables target roll and target hdg and 2. a new altitude control mode that disables target altitude and target pitch. Then, using Nasal, we can just input our roll and vertical speed directly and not have the AI system try to change them. — flug (Sat Oct 22). Re: AI & MP Dogfighting now working! Bombable ships, aircraf. (powered by Instant-Cquotes)

The AI System btw. has it's drawbacks regarding non-aircraft Entities. Also it is hard to pass specific Properties to an AI Model. It will always try to bank and pitch, which needs to be corrected per Model. This all can be solved by using animations and Nasal, but creates a lot overhead. — DFaber (Wed Apr 23). Re: Tutorials/Missions/Adventures: requests for features. (powered by Instant-Cquotes)

lug mentioned a while ago that he ran into the same issue with regard to his bombable/combat addon — Hooray (Fri Apr 25). AI support. (powered by Instant-Cquotes)

If you can provide a list of problematic behavior patterns, I can check the C++ code to see if/how things can be made more configurable there, i.e. with a focus on non-aircraft, but also aircraft that may not fly like airliners — Hooray (Fri Apr 25). AI support. (powered by Instant-Cquotes)

OK, here's my wishlist part 1: Disable the banking when turning with Ground Vehicles. There are Ground vehicles in FG, but mainly Trains, which I haven't been able to utilize for Cars. Also Cars need to lookup Ground elevation which AI Aircraft don't do too. FG determines submodel hits on AI/MP Objects by square Boxes around the Aircrafts Origin. These are too wide to be useful with Ground Vehicles and small Aircraft. Some more Size opions would be useful. When a new Target Heading is selected AI Aircraft don't turn harder than 30 degrees. It would be good to be able to configure this per Aircraft. I'd like to specify Model specific Properties like Livery, Type in the AI Scenario file. Right now I need to create and set them within the nasal section. These are some from the top of my head. More to come ... — DFaber (Fri Apr 25). Re: AI support. (powered by Instant-Cquotes)