Talk:Scripted AI Objects: Difference between revisions

This is not only a quick way of doing it, this also something that can allow multiplayer firing : If (imagine a checkbox) the "MP firing property" is activated, it could reproduce a "AI model" on both side : On the SourceOfFiring's computer, but also a second "AI model" in the DestinationOfFiring's computer...(this a way of doing it...)

One thing we need to consider is how we coordinate code, i.e. use of version control etc..  [[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 12:59, 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)

: 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)

: I've taken your code and refactored it to add stubs for separating things like FDM, guidance and autopilot - I've also added a self-test routine that I am hoping to extend over time - it should be self-contained, i.e. not rely on any aircraft/scenery. But it would seem to make sense to also move away from the static model_path and instead introduce a ModelMgr class so that multiple models per stage can be easily supported according to the missile.nas discussion above. This class could then also manage effects/animations and so on. You will find my changes in the "scripted-ai-submodels' branch. HTH--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:02, 31 October 2014 (UTC)

A suggestion that I have is to expand geo.Coord to hold orientation values.  That would mean we could handle target and have their lat/lon/alt/pitch/roll/heading at our fingertips.

[[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 17:03, 29 October 2014 (UTC)

—[[User:5H1N0B1|5H1N0B1]] ([[User_talk:5H1N0B1|Talk]] | [[Special:Contributions/5H1N0B1|contribs]]) 14:46, 31 October 2014 (UTC)

@Red_Leader: you just reverted all the changes I added to your code in the meantime, you may want to review the last diff to see if you want to merge any of those or not (I've merged everything into the git topic branch now, see the infobox) .--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:28, 30 October 2014 (UTC)