20,741
edits
Nasal Events: Difference between revisions
Jump to navigation
Jump to search
m
→Summary
No edit summary |
m (→Summary) |
||
| Line 10: | Line 10: | ||
* end users and aircraft developers would prefer having some form of "process monitor" or watchdog for Nasal processes [https://code.google.com/p/flightgear-bugs/issues/detail?id=565] | * end users and aircraft developers would prefer having some form of "process monitor" or watchdog for Nasal processes [https://code.google.com/p/flightgear-bugs/issues/detail?id=565] | ||
* We have currently no way to directly instantiate "singleton callbacks" to make the API more fool-proof | * We have currently no way to directly instantiate "singleton callbacks" to make the API more fool-proof | ||
* Furthermore, it would make sense to automatically release/restart certain timers depending on their scope (aircraft-reset, GUI reset, I/O reset) | * Furthermore, it would make sense to automatically release/restart certain timers depending on their scope/lifetime (aircraft-reset, GUI reset, I/O reset)prefer having some | ||
* Basically, timers could be registered with a scope-specific context, so that timers for different purposes would be stored in categories, so that all timers in a group can be safely shut down, and restarted (imagine restarting the GUI, changing the position, resetting the whole sim or changing the active aircraft) - we would ideally want to be able to maintain callbacks for timers/listeners in corresponding groups, so that other callbacks are not affected | |||
* The recent maketimer() API could be extended accordingly | * The recent maketimer() API could be extended accordingly | ||