Talk:Scripted AI Objects: Difference between revisions

Jump to navigation Jump to search
m (Hooray moved page Talk:Scripted AI Missiles to Talk:Scripted AI Objects: the scope is no longer specific to missiles, User:Red_Leader)
Line 150: Line 150:
* look at the guidance/autopilot logic and come up with corresponding base classes
* look at the guidance/autopilot logic and come up with corresponding base classes
--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:36, 2 November 2014 (UTC)
--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:36, 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
* mainly, this requires any uses of hard-coded properties referring to /orientation /position and /velocities - especially the release() and update() methods to be generalized
* missile specs management is unnecessarily verbose, and not yet entirely generic - simply because of the way specs are loaded - it would be much easier to simply use a hash for configuring each missile, instead of having the hack in Loading_Missiles.nas[https://gitorious.org/fg/fgdata/source/cac8cc4ed2a52b075f72b3e300843599335d40a7:Aircraft/Mirage-2000/Missiles/Loading_Missiles.nas]
* 3-4 methods are much too big - i.e. need to be decoupled and refactored, especially to separate the FDM vs. guidance logic and the proximity detection stuff
* making the code use ai.nas in its original form would be straightforward, but establishing the component separation is more work, and is currently preventing the code from being easily reused elsewhere
* also, as is usually the case whenever complex Nasal code is involved, state management is not encapsulated at all, and done in a pretty roundabout fashion using lots of nested conditionals, i.e. no generic mechanism (state machine) in place
* overall, missile.nas remains the best option for coming up with a generic framework, but there's quite some refactoring work to do still
* how to proceed from here depends on who's willing to collaborate - otherwise, I may simply rewrite large portions of it, which would obviously take longer than providing feedback on what to change...
--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:20, 4 November 2014 (UTC)

Navigation menu