Talk:Scripted AI Objects: Difference between revisions

Jump to navigation Jump to search

Talk:Scripted AI Objects (view source)

Revision as of 19:53, 30 October 2014

90 bytes added ,  30 October 2014
m
→‎Using geo.Coord objects for dealing with source/targets: re-structuring - hoping to edit things and move them to the main article at some point
m (→‎Implementation: more structuring)
m (→‎Using geo.Coord objects for dealing with source/targets: re-structuring - hoping to edit things and move them to the main article at some point)
Line 42: Line 42:
: [[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 16:52, 28 October 2014 (UTC)
: [[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 16:52, 28 October 2014 (UTC)


:: Sure, but 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)
== 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)


I think that we should instead call this the "AI guided weapons system" or "AI guided munitions."  After all, we aren't just talking about missile, we're also talking about guided bombs.  The same system can and should be used for both.  That's what I think anyway.
I think that we should instead call this the "AI guided weapons system" or "AI guided munitions."  After all, we aren't just talking about missile, we're also talking about guided bombs.  The same system can and should be used for both.  That's what I think anyway.
[[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 19:56, 28 October 2014 (UTC)
[[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 19:56, 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)
: 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)
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/77509"

Navigation menu