20,741
edits
Talk:Scripted AI Objects: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
Red Leader (talk | contribs) (Re Hooray) |
mNo edit summary |
||
| Line 49: | Line 49: | ||
:: Hi Hooray. Thanks for the suggestions. I think that, for now, we'll concentrate on keeping it in Nasal. At a later stage, we could look at implementing parts of the system in other parts of FG. | :: Hi Hooray. Thanks for the suggestions. I think that, for now, we'll concentrate on keeping it in Nasal. At a later stage, we could look at implementing parts of the system in other parts of FG. | ||
:: [[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 16:34, 29 October 2014 (UTC) | :: [[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 16:34, 29 October 2014 (UTC) | ||
right, but you misunderstood - I wasn't suggesting to move this out of Nasal anytime soon, but to just keep the design sufficiently generic so that components can be replaced at a later time, no matter if that involves other Nasal modules or really existing C++ code. The main problems that flug, xiii and others had when implementing these features was working around hard-coded design restrictions-those can be entirely prevented once a modular design is used like the one discussed above - without making things any more difficult. In fact, separation of concerns will be greatly simplified-and it does make sense to treat any entity like an airborne vehicle with a fdm, autopilot and route manager/guidance system. All this can be done entirely in scripting space using Nasal. The key is just the layered design using the property tree for I/O between systems--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:42, 29 October 2014 (UTC) | |||