Ah! I knew there was a simple answer, I need only to ask.
Thanks
Harald JOHNSEN wrote:
> Check
> http://wiki.flightgear.org/flightgear_wiki/index.php?title=Nasal_scripting_language.
>
> You'll want to have a listener on the reset signal
>
> setlistener("/sim/signals/reinit", func {
>
> s
Stewart Andreason wrote:
>I see that after a File.RESET, the global variables (at nodes) get
>reinitialized to the values they are set to in the nasal file, but the nasal
>(pseudo-global-to-the-one-file) variables do not.
>
>I would like to know how to reset the nasal variables.
>I have rounded t
Andy Ross wrote:
Hi Andy,
Ah, that did look like a lot of extra code to handle node-based variables.
> That said, you really don't want to be designing your scripts around
> raw, low-level performance issues. Write your code to be readable,
> not blazingly fast. In general "altitude" is more r
Stewart Andreason wrote:
> If accessing temp1 _is_ faster than .getValue, then at 2 or 3
> accesses, I imagine it becomes faster to do the above?
Yes, it's definitely faster, because there's less work to do.
Evaluating the expression "temp1" requires pushing the symbol value (a
string) onto the st
Andy Ross wrote:
> Stewart Andreason wrote:
>
>> Is there a preference for how variables are declared and used in nasal?
>> between the global type:
>> var some_name = 0;
>> which can be accessed and changed from any function,
>>
>
> That's a Nasal variable. It's not "global" in the sens
Stewart Andreason wrote:
> Is there a preference for how variables are declared and used in nasal?
> between the global type:
> var some_name = 0;
> which can be accessed and changed from any function,
That's a Nasal variable. It's not "global" in the sense that all
users will see the same valu
6 matches
Mail list logo
