20,741
edits
Talk:Scripted AI Objects: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
No edit summary |
mNo edit summary |
||
| Line 228: | Line 228: | ||
—[[User:5H1N0B1|5H1N0B1]] ([[User_talk:5H1N0B1|Talk]] | [[Special:Contributions/5H1N0B1|contribs]]) 16:26, 30 October 2014 (UTC) | —[[User:5H1N0B1|5H1N0B1]] ([[User_talk:5H1N0B1|Talk]] | [[Special:Contributions/5H1N0B1|contribs]]) 16:26, 30 October 2014 (UTC) | ||
[[User:5H1N0B1|Every day, from everything and everybody, there is a truth to learn]] ([[User talk:5H1N0B1|talk]]) 15:29, 30 October 2014 (UTC) | [[User:5H1N0B1|Every day, from everything and everybody, there is a truth to learn]] ([[User talk:5H1N0B1|talk]]) 15:29, 30 October 2014 (UTC) | ||
: To me, this sounds all very do-able - but obviously, it is a matter of priorities in terms of manpower and time that can be dedicated to this - most of us have many other areas/projects that we're juggling already. Thus, to state my own priorities, and to clarify where I'd be interested in helping: | |||
:* I'd like to help extend the posted code such that tanker.nas and existing missile systems can be implemented using this code | |||
:* Specifically, I would like to support a handful of different aircraft/use-cases, including other missiles, and at some point hopefully also other types of "payloads" | |||
:* Primarily, I am interested in refactoring existing code to generalize the underlying concepts and to come up with an OO framework, where all the generic code lives in shared directory, instead of being copied&pasted into various places under $FG_AIRCRAFT | |||
:* I might also be able to hook this up to galvedro's failure management code, so that missiles or aircraft systems may suffer failures and respond properly | |||
:* in the really long-term, I'd also like to see flug's code reviewed and generalized accordingly, so that we can come up with a library/module for controlling AI objects in scripted fashion - without being specific to combat/missile use. | |||
:* I am personally not opposed to any combat functionality in FG, but I do understand that this is a controversial topic-thus, I'd prefer to come up with generic building blocks that are not specific to combat use only - e.g. by having a "uav" framework instead of a drone/missile framework. | |||
:* Structurally, I would suggest to come up with a new Nasal submodule under $FG_ROOT/Nasal/ai and add our ai.nas and missile.nas files there so that they can be independently developed, while being strictly optional | |||
:* specific instances I would like to instantiate explicitly by using io.include(), analogous to the failure management framework or MapStructure | |||
:* I do believe that it is very important to separate all components properly and to establish the property tree as the sole interfacing mechanism between guidance/autopilot and FDM-I am thinking in terms of having *.guidance, *.autopilot and *.fdm files that contain Nasal sub-classes implementing the corresponding lower-level interfaces (base classes) | |||
:* that way, aircraft developers may not necessarily have to touch any *.nas files but just work with a certain subset of Nasal, analogous to MapStructure implementation files | |||
:* I think there's really just 8-12 main base classes missing that can probably be prototyped by looking at existing use-cases (tanker.nas, fox2.nas. missile.nas) - once the code is sufficiently generic, I would hope to port those files to make them use the new framework, and then get aircraft developers involved to update their work accordingly. | |||
: --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:02, 30 October 2014 (UTC) | |||