Talk:Scripted AI Objects: Difference between revisions

== Target / Source handling ==

As Hooray said, this is the talk started here : http://wiki.flightgear.org/User_talk:Red_Leader

We agree on the general way of doing it, and the goal we want.

== Generalizing the existing code ==

:: You'll find that most of these requirements will basically evolve automatically once you start refactoring the existing code into separate classes and files, while still supporting additional aircraft/use-cases. That is basically what we did with Gijs' [[NavDisplay]] code - and it can now be used on arbitrary aircraft, while also supporting an arbitrary number of instances per aircraft. We are even supporting an "AI aircraft" mode-which means that you can get a ND view for an arbitrary AI aircraft (including even AI nodes like a Bombable bot or AI missile). To make things sufficiently flexible and configurable we're using "behavior hashes" that can override default behavior (fields/methods). With efforts like these, over-engineering is a very real danger - it will probably get you farther to just refactor the existing code and incrementally make it support additional use-cases/aircraft, and extend the code over time. Currently, the main issue still is that the module is aircraft specific-once this restriction is removed, you'll see other aircraft developers join the effort over time, especially those without any stakes in the m2000-5, but still interested in combat feature.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:04, 28 October 2014 (UTC)

== Functional separation into guidance, autopilot and FDM ==

: From a functional standpoint, I would suggest to look at the way FlightGear's subsystems are divided into distinct components and then simply model this code accordingly by introducing helper classes for components like 1) the FDM, 2) the autopilot, 3) the "route managerh". That way, a guidance system would simply implement the route manager system's interface. As I stated elsewhere, it would make a lot of sense to maintain parity with the property tree-level FDM/AP and RM systems. Primarily, this will ensure consistency - secondly, it will ensure that future updates would provide a sane migration path, i.e. for using C++ level hooks that are currently not exposed to scripting space - we do have a number of contributors who tinkered with supporting multiple instances of the FDM/AP and RM subsystems - in fact, the AP system already supports multiple instances (see the property-rules system). And multiple FDM instances can also be supported for JSBSim FDMs - the route manager (RM) seems to be not sufficiently generic, but Durk and Zakalawe have repeatedly stated being interested in generalizing this part, too[http://forum.flightgear.org/viewtopic.php?p=134970#p134970]. Which basically means that there will be less repetitive/integration work necessary if/once those changes should materialize at some point. Thus, it would be a good idea not to re-invent the wheel entirely in scripting space - there's useful existing C++ code for these things (FDM, AP, RM), and exposing things to scripting space using [[Nasal/CppBind]] also has never been so easy. The other benefit is obviously that people will intuitively know how to deal with scripted AI objects because the property tree interfaces would be closely modeled after existing conventions.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:36, 29 October 2014 (UTC)

== Modified tanker.nas version using ai.nas ==

Like I said, before you told me you were interested in exploring this, I already started some work related to this - I'd suggest you wait until I have committed those changes so that you can take a look - it's mainly structural stuff ensuring that the existing GUI dialog can be used to instantiate a new tanker using ai.nas - everything else is "as is" and still needs to be adapted, but I thought this could help lower the barrier to entry. It's up to you obviously to decide if you want to use or discard those changes. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 2 November 2014 (UTC)

== missile.nas feedback ==

I've started refactoring some of its code to implement the FDM base class - so here's some initial feedback. The main things preventing us from using the file/class "as is" are:

* there's the hard-coded assumptions that missiles are started by the main aircraft, i.e. no support for AI aircraft firing missiles  

All the if/getprop logic  in missile.nas and Load_Missiles.nas can then be removed, and you can add arbitrary other state there, too.

--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:35, 5 November 2014 (UTC)