20,741
edits
mNo edit summary |
m (→Implementation) |
||
| Line 54: | Line 54: | ||
: OK, so the way I understand it is that the code should generic enough so that, for example, in the future YASim supports multiple instances, we could take out the Nasal FDM and instead translate the missile through the sky according to properties generated by a YASim instance. | : OK, so the way I understand it is that the code should generic enough so that, for example, in the future YASim supports multiple instances, we could take out the Nasal FDM and instead translate the missile through the sky according to properties generated by a YASim instance. | ||
: [[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 17:01, 29 October 2014 (UTC) | : [[User:Red_Leader|Red Leader]] ([[User_talk:Red_Leader|Talk]] | [[Special:Contributions/Red_Leader|contribs]]) 17:01, 29 October 2014 (UTC) | ||
:: correct, but this is not specific to FDMs - all the autopilot/routing logic that people tend to reinvent in Nasal is significantly overlapping with existing, generic, C++ subsystems that are currently not yet exposed to Nasal. Thus, the main thing is using properties analogous to the actual C++ subsystems for interacting with the FDM/AP and RM components, which will ensure that a reusable and generic design is established, while preparing it for future updates. Otherwise, there will be more and more Nasal code doing what the C++ code is known to be very good at already.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:00, 29 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. | 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. | ||