Disclaimer: You generally don't want to do this kind of thing - primarily because the main loop needs to be fast and "fixed" - vs. Nasal is a dynamic programming language with a so called garbage collector that may be triggered rather "randomly", which in turn makes the main loop less deterministic - this is important to keep in mind in general, but especially when dealing with systems (Nasal code) that is intended to be "FDM coupled" (run at FDM rate).
For starters, the square brackets in your settimer() call are almost certainly not doing what you expect them to do - that is because the call you are using will pass a Nasal vector (an array) to the API, and I don't think it accepts one at all - as a matter of fact, if the docs are using this syntax, it is primarily to denote optional arguments, which is in line with EBNF (see wikipedia) to specify optional arguments and how/where to use those.
Besides, you probably want to stop using settimer() in favor of maketimer() - in general, it is not a good idea to keep on using APIs like settimer() or setlistener() - instead, they should be wrapped by higher level helpers that may automatically help with resource management (cleaning timers/listeners) - not using those APIs properly is the the single most problematic reason for Nasal code running unnecessarily in the FlightGear main loop without people (aircraft developers and end users) being aware of that - in fact, there is no good way to actually tell what is going on here, unless you are intimately familiar with SG/FG and Nasal internals.
For the gory details, refer to:
viewtopic.php?f=46&t=17069For details on timers and listeners and how/why they can be "leaking", see James and Torsten's comments quoted below:
Subject: Listener objectszakalawe wrote:Dumb question of the day. Someone recently pointed out that the setlistener() / removelistener() API makes it easy to leak resources. So I wondered about making an alternate API where the return value from setlistener must be kept, or the listener is removed. I can imagine this with a helper object
var myL = setlistener2("some/prop", func { ... }} )
myL.addprop("some/other/prop");
myL.addprop("yet/another/prop");
Now you need to retain a ref to myL or the listeners on all the props are removed. I don't think we can retro-fit this to the existing API, because I suspect many places just ignore the return value and would break with this change.
(Or even pass a vec of property names to setlistener2, to avoid all the discrete calls to 'addprop', that's a seperate detail really)
It seems like this would work, and be easy enough to implement - question is if it gives enough benefit to be worth the confusion.
To learn more about tracking Nasal callbacks invoked via timers and listeners, refer to:
Subject: Nasal Callback tracking (timers & listeners)Hooray wrote:http://sourceforge.net/p/flightgear/mailman/message/34810857/
Thorsten wrote:it's relatively easy to do bad things
unintentionally. Like tie a bit of code to an FDM property and run updates
of a display 120 times per second rather than the 30 times you actually
need. Like start a loop multiple times so that you update the same
property 30 times per frame rather than the one time you actually need.
It's actually pretty hard to catch these things, because the code is
formally okay, does the right thing and just eats more performance than
necessary, and there's no simple output telling you that you're running 30
loops rather than the one you expect. The only way I've found is to clock
down loops and print to console inside them - when you clock them per
second and see 30 messages printed each second, you know that something is
afoot...
So it's really not impossible to come up with aircraft Nasal that ends up
using a hundred times more performance than it has to. Unfortunately,
better CPU utilization is not really the way to attack these problems
though....
given that this obviously a recurring problem, I was wondering what we could do abot this - so I started prototyping a Nasal/Canvas-based UI to for displaying active Nasal callbacks (i.e. timers & listeners).
And I think it would be a good idea to gather some feedback to determine what kind of data would be useful and how it should be ideally represented - obviously, the screenshot below is not much more than a mockup (well, it is working Nasal code, just the data that is shown is arbitrary) - but otherwise, exposing the SGEventMgr logic at the Nasal level to provide a list of active events, including their callbacks (and location in Nasal code, i.e. filename and line number) is relatively straightforward.
So what else do we need to come up with an intuitive "task monitor" that shows Nasal callbacks registered in the form of timers and callbacks ?
Should we differentiate between aircraft and scenery code, between different sub-modules ? Technically, that would be possible to do, because we will need to patch some C++ code anyway - i.e. roughly 50-100 lines of code in both SG and FG will need to be touched to expose the SGEventMgr queues to scripting space (or even just in the form of live properties that are updated each frame)
http://wiki.flightgear.org/Howto:Troubl ... _Callbacks