20,741
edits
Using listeners and signals with Nasal: Difference between revisions
Jump to navigation
Jump to search
Using listeners and signals with Nasal (view source)
Revision as of 19:46, 19 May 2013
, 19 May 2013→Nasal code coupled to the autopilot system: http://flightgear.org/forums/viewtopic.php?f=46&t=17069&hilit=nasal+fdm+autopilot&start=15#p165551
m (→Nasal code coupled to the autopilot system: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38173.html) |
(→Nasal code coupled to the autopilot system: http://flightgear.org/forums/viewtopic.php?f=46&t=17069&hilit=nasal+fdm+autopilot&start=15#p165551) |
||
| Line 223: | Line 223: | ||
Some benefits to such an approach include (IMHO) better testability, more predictability, and easier interface (someday) with a GUI tool, should one | Some benefits to such an approach include (IMHO) better testability, more predictability, and easier interface (someday) with a GUI tool, should one | ||
materialize. The downside is that XML can be verbose. | materialize. The downside is that XML can be verbose. | ||
All that being said, it is definitely possible to run Nasal in the FDM update loop, so to make up your own mind, you could try this: | |||
Alternatively, as a short-term solution that does not rely on editing C++ code, you could just trigger off an internal autopilot property. | |||
Which is a pretty clever workaround: trigger a boolean property for each iteration, so that the Nasal listener can pick it up, which will get invoked at FDM update rate that way. | |||
Perhaps we could set up a trigger that is fired by the Autopilot subsystem, immediately before the autopilot executes. However, someone more familiar with FG's code base than me can probably come up with a more elegant solution. I feel like adding a new events system and a parameter to settimer is cleaner than a signal -- and that if a signal is added, the Autopilot subsystem is probably not the place to add it. | |||
Also see: | Also see: | ||