Scripted AI Objects

Note: While this article is based on considerable community feedback, there's nobody working on this currently. So if you'd like to help in one way or another, please get in touch or just help improve the article in the meantime! Useful Skills: PropertyList XML File, Property Tree, Nasal scripting, fgcommands, AI traffic People: Mentors: xiii, 5H1N0B1,Hooray Philosopher (get in touch to learn more) It's possible that this article hasn't been updated in a while, so to catch up with the latest developments, you are advised not to start working on anything directly related to this without first coordinating your ideas with fellow FlightGear contributors using the FlightGear developers mailing list or the FlightGear forums. See also the talk page.

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

Bombable & Fox2

Flug's bombable script implements "dog fighting" support on top of FlightGear, without ANY changes to the C++ side of the code, just by using some fairly advanced scripted code (implemented in the built-in Nasal programming language). You can basically imagine it like a "MOD" of FlightGear.

In other words, the bombable script creates a completely new mode in FlightGear. So it is well worth looking into this script to see how flug has managed to do what he has accomplished. While the script is certainly far from trivial, it is an excellent example for what can be achieved by plugging together distinct FG components in creative ways to create completely new behavior and systems.

Also, there is another related effort - by the forum user "xii": xiii created an implementation of a "seeking missile" for the f14b aircraft, IIRC the file is called "fox2.nas". While these two systems are not yet integrated as far as I know, it should be fairly straight forward to do - you would then have a "dog fighting" system with f14 aircraft that can actually shoot seeking missiles.

Integrating these two systems (Nasal scripts in fact!) would probably be an excellent exercise to get to know FlightGear's internal architecture, its built-in extension language (Nasal) and related systems such as the AI traffic system etc.

Fox2 Implementation

You can check $FGDATA/Aircraft/f-14b/Nasal/fox2.nas (in Git) which models a tiny part of a complex weapons system.

• It checks for available weapons with respect of the pylon position.
• checks for missile readiness (all switchs on right position and time to temperature of the IR seeker).
• activates one missile search function.
• search for a possible target.
• locks on the target and check if any lock out condition. Calculate HUD symbology (diamond displayed over the target position in the HUD)
• checks for fire order
• calculates exact position/orientation/velocity when fire order so we can spawn a new AI object in the proper place.
• releases the missile and guides it with a crude FDM
• if available activates a new searching missile and drives both fired and searching objects (we can guide several fired missile (flying and tracking) and have an additional one in searching state (on its pylon and searching or tracking). Each object can have its own target.
• checks for (near) impact or lock out condition
• if impact, creates the properties used by bombable.nas so the target is actually damaged, and some other properties for the explosion graphical animation. Also it displays the distance from the target on the player screen when the missile explode.

There is a menu item in "Tomcat Controls" with a switch which allows those informations to be displayed as messages over MP.

The script works with Git version. If you are interested in how the impact handled on the target side, you'll have to checkout a modified version of bombable.nas available here The weapons system manual is available on the wiki

Sorry, it's all but a simple script but if it can help...

About the trajectory and proximity detection: There is plenty of room to improve the trajectory algorithm. But this would drive us toward a 100% collision chance and this would oblige us to add adverse conditions to downside the success rate and keep a reasonable scoring. Users experience may also be unchanged after adding lot of computations. Anyway,I agree with you about the poor more or less 75% score on the level flying tanker. I'll try to think about how to test your idea, but if you can stand my code, you are welcome to play with the algos!

I wonder if building a controler loop wouldn't worth the pain, as for now, functions call themselves in an awful gordian knot... Now if the freeze happens without the weapons system running, even if it is much less often, then will have to search somewhere else.

Well in any case a controler loop might help the reuse of the code, frankly ATM it looks like crap.

I also noticed that the freeze occurs mostly after a cockpit sound play.

About guidance, the steering of a missile is not the most complex thing, at least from a simulation point of view. Now, it is nearly impossible to match exactly a direct hit with the framerates we have, so there is a need of some tricks here and there to give the missile a chance (some kind of funny "post prediction"). The complex thing is rather locking one from several target, assign it to a missile, fire, steer, and while doing this, repeat the operation with a possible other target and another missile. Be able to cancel the operation in case of a lock loss is part of the game. For this part you will have to handle a lot of logic. Now doing a crude FDM, checking how to spawn a new AI missile and apply the FDM is not woodoo science, the hard work is already done and may not need all the radar stuff and weapon system. Same for making it work with bombable.

Fox2 Generalization

We already talked about this in the "AI guided missiles" thread a couple of weks ago: Basically, xiii has illustrated that this is perfectly possible, and there are plans in place to generalize the existing code to turn it into a reusable Nasal module for the $FG_ROOT/Nasal directory eventually, so that all users can easily create new AI objects that can be controlled from Nasal, just by subclassing an existing Nasal class: viewtopic.php?f=23&t=7791&start=45#p84834

This will all depend on solid background knowledge of Nasal, and the AI system (its properties) however - so the best thing you can do right now, is reading more about Nasal to see how it works. Even if the approach had already been fully documented, and if the module would be available right now - you would still need to know Nasal.

Code reuse is actually a very good idea, especially because there are now three different scripts doing basically the same thing: controlling AI objects and because there were meanwhile so many people also asking how to control AI objects using Nasal, and I haven't yet had the time to write a howto, so a reusable Nasal module might be a good idea.

So I am wondering, if we should take a look at the three addons (your's, Thorsten's local-weather and flug's bombable) and come up with a new generic Nasal module for controlling AI objects? Normally, this would be a task for the Nasal library maintainers. But just looking at the three scripts, it should be possible to come up with an API. This would make it easier for other people to reuse your code and create similar addons.

So here is what I can add to the discussion:

• About people involved: Anders (AndersG) is actually the official Nasal library maintainer, though hopefully Melchior (cptf) isn't far and always have a look at this part of FG he knows better than nobody else.
• Bombable: I still didn't have time to dive into it (though it is running on my working copy of the data). Now I'm interested into it and I'll be happy to provide what's needed so Flug can re-use my stuff. Also I think an effort should be done to move bombable from an addon to an integrated part of FG. Being an add-on makes working with it more difficult for people working on official data (Git merges on locally modified files, different mp_broadcast module...)
• My own stuff: I already look forward generic modules even if they may be difficult to implement in a new aircraft (case of the radar screen). ATM the f16 use a generic version of the f-14b radar. I plan to rework the guided missile to make it generic before adding it to the f16, I'd also like to separate it from the radar stuff. Now, sticking to RL systems with accuracy is a nightmare, but how funny. I wouldn't like to see these things used as toys with no care of what could be a real system.
• AI API: this would be a nice start as being very reusable. I think there is also a possibility to do that in C++ as most of it is already written mostly by Vivian, and know he isn't against some of these ideas. Nevertheless a Nasal prototype is also a good start.
• What can I do: well during summer time I won't be able to really focus on serious things, I'll have more time during winter. Now I can follow, adapt my own stuff to a future API, test, and commit.

So it is probably a good idea to base such an "ai.nas" module on xiii's code, i.e. simply take a look at the code, generalize and abstract it and put it into a new Nasal module. Once the original fox2 script can use that module, we can still look at the other addons (bombable ) to see how the ai module needs to be modified to be fully usable by the other scripts.

That in itself should help reduce duplicate code and improve code reuse among Nasal scripts.

Once we have a working ai.nas module, we could start work on porting all existing addons to start using this module then.

I am really convinced that this is the right thing to do, because it is generally better to look at any large portions of code and see how it can be refactored into distinct reusable components. This is something that has been done rather well with the Nasal standard library in $FG_ROOT/Nasal.

Starting this effort right now would help us combine all related projects and unifying the code.

Supporting other missile types

A Phoenix isn't just a Sidewinder with a different range and callsign - it has a completely different guidance system, a different acceleration, different aerodynamics, is targeted in a different way,...

The maintainer of the F-14b knows these things (and cares for them) and so far no attempt at a realistic modelling of the other missiles has been made - an unrealistic attempt has no real chance of being committed.

FlightGear is not a combat simulator. Thus, I would not mind if there were shortcuts in the weapon-system. Though the AIM 7 and AIM 54 use radar, they could be modeled/coded exactly as the AIM 9, the only difference is range and callsign. Missile aerodynamics in my opinion, is not that important in FlightGear---perhaps something to be worked to in the long, long run.

Cruise Missiles

A cruise missile is more than a simple AA passive guidance missile, it's rather a one way UAV, in other terms a jet aircraft without landing gear, so it worth something better than the very crude fox2 nasal FDM. Fox2.nas is good at managing several submodels, engaging one or more AI/MP target, managing weapons on different pylons and it only uses a proportional pursuit guidance algorythm which simply change the velocity vector inside a given flight envelope (basicly a G limiter). There is no phisical effect but thrust, gravity and drag. I would say that's less than a FDM :-/

AFAIK, please correct me if I'm wrong, there isn't the possiblity to run 2 real FDMs at the same time in FG but to use 2 instances of FG. Now it's perfectly possible to run a very basic FDM with nasal scripting.

Brainstorming

This part is a draft On the 2000, we could start some kind of generic missile. So first lets split this into different parts:

I) The missile itself

Should be an object. The FDM has to be separated from the missile object itself. The loop should loook like : detection->load management->firing order->release missile->update position->update guidance with missile capabilities->proximity detection->update position

There is a few sorts of missiles: We can class them with their FDM:

1. Engine: Solid rocket, ramjet, turbojet...
2. Orientation control: vectored thrust, moving wings, both
3. Flying : just falling (dropped bombs), flight with the engine thrust, wings (cruise missiles)
4. Kind of flight: Straight line, High alt cruise and dive, follow a low alt (sea missile), terrain following (SCALP), dropped bomb (kind of curve)...
5. Terminal manoeuvre: Straight in, climb and dive (top attack)...
6. Detection: Laser, Heat, Missile internal radar (active homing), lighted with shooter radar (semi active homing), "target radar" (anti-radiation missile), "shared data with shooter" (datalink), GPS/INS, Hybrids (Like Aim54 : lighted for the first part of the flight and then ue its own radar/ Or datalink for the first part and intern radar/heat for last part)
7. Launch: rail, dropped, ejected (from the pylons, about 5–25 ft/s)
8. Physics: Size, weight, warhead weight, fuel weight, max g over load etc...

II) Missile detection

The way that an aircraft detect a missile. This is independent of the missile itself, but you can't fire the missile without it

III) Missile.nas

What is done in "missile.nas" "missile.nas" is an improved code of "fox2.nas". The new things are : - Added generic missile firing. Each different missile class have their property in "loading_Missiles.nas"<-this is not optimal, perhaps an xml file would do the job... - Added rail or dropped capacity (not ejected yet) - Added High Alt Cruise mod. For high Altitude, the cruise mode go up to its cruise alt, stay there until the angle between the missile and the target < 45° - Added low alt sea cruise mod. Same as High Alt mod : low Alt just above the sea. - Added a low alt ground cruise missile. Here the Alt is given not at sea level but ground level. And to have a better behavior, the script calculate What the ground Alt will be in 2 frame/loop, in order to anticipate, and not crash. This is not optimal and can be improved. - Added anticipation of the next target position. With a return of experience of the first code (Dogfight test), if missile just follow the "actual" position of an aircraft, it's just a following things, and there is a lot of miss. When your target getting closer, you can't just "follow" the target. Real missile react in really short time and can update their trajectory in a micro second. In FG we have to calculate the next target position in a "relative" time, which depend on when the next loop will be executed (could be slow down by terrain loading, High texture aircraft etc).

This feature could be improved in a more dynamic way. Older missile had low update rate, and new missile high rate and some have even anticipation stuff themself)

- Improve proximity detection. "fox2.nas" calculate the distance with the target in the actual frame and compare it to the precedent frame. If the precedent frame is closer to the target than the actual, it means that the missile get away from the target. So the script take the precedent distance and compare it to the "minimal distance for explosion". (And if the missile get away and minimum distance isn't reach -> missile go in "missed mode") The problem with this calculation is when your missile fly at very high speed (like mach 4 ou 5) it travel at more than 1 km/sec. So more than 100 or 200 meter between each frame. It mean the "minimal distance for explosion" could be reach between frame1 and frame2, but nor frame1 neither frame2 had reach the "minimal distance for explosion". So in that case, "fox2.nas" will not trigger explosion and it should do. "missile.nas" calculate the distance between the missile and the target in frame1 and frame to but also "on the line" between frame 1 and 2. So it's more accurate to trigger the explosion...

- Max G limitation. In "fox2.nas" when the missile's maxG is reached, the script compute the missile in "missed mode"). "missile.nas" recalculate the max angle the missile can turn without exceed maxG (Perhaps more things, but I have to look the code again)

- "fox2.nas" compute in "missed mode" when the missile go out circle of the HUD (to simulate, when the target go out the radar lightening). this function was directly link to the aircraft. In missile.nas this function is erased. This thing should be important to put this function again, in order to simulate correctly all the passive missile... (like aim-7)

IV) Object needed

missile

  |-->FDM
  |-->3D stuff : loading missile with smoke, without when out of fuel, and explosion. In the m2000's "missile.nas", the missile smoke and the explosion is generic. But 3 different 3D model are loaded at each step -> Not the best way, but couldn't find another that could stay generic)
  |-->Guidance. The guidance 

Related

• How would I go about controlling an airplane with nasal?
• Looping Flight Path
• F-14B's Weapon System
• Mirage 2000-5

External links

• Cobham Weapons Carriage and Release equipment Data sheets on some pylons, rails, racks and ejectors.
• Missile guidance at English Wikipedia.