Local variables filtering down

[dmarkwick 261]

So local variables are visible from the point of their declaration down... fair enough.

How about called scripts? If one script calls another script, does that second "thread" of code have access to the local variables declared in the first script?

I ask because I'm setting up a situation where a script will kick off another script, which in turn will execute copies of the same script, and so on. I need a local variable declared in the initial script to keep control of how many instances of the second script are executed.

To give context to the problem, it's for a forest fire. A burning object will "spawn" a fire, and this fire can in turn spawn other fires around it. I want the initial script to have a variable that limits the number of spawned fires so it doesn't truly get out of control

[.kju 3245]

http://community.bistudio.com/wiki/Variables

In functions you should additionally mark variables as local using

the command private. Otherwise you may modify local variables of

the calling script that are visible in the function.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">private "_myLocalVariable";

_myLocalVariable = 0;

[dmarkwick 261]

Thanks for the reply Q. I guess that in the case I described the local variables would NOT filter down. However if I preprocess the scripts into functions then they will.

[Doolittle 0]

Keep it simple. Make it global.

[dmarkwick 261]

Keep it simple. Make it global.

Can't do that I need variables from the original fire to trickle down to the related spawns, but not across to unrelated fires

[UNN 0]

Quote[/b] ]To give context to the problem, it's for a forest fire. A burning object will "spawn" a fire, and this fire can in turn spawn other fires around it. I want the initial script to have a variable that limits the number of spawned fires so it doesn't truly get out of control

Theres a simple way, where you just pass everything when each script is called?

Say you start your fire with an exploding oil drum using:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[This,0,100] Spawn DMW_BurnObject

Then DMW_BurnObject has this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Object=_This Select 0;

_BurnCount=_This Select 1;

_BurnMax=_This Select 2;

//Get the next lot of combustables using whatever method

_NearestObjects=...blah...blah...

{

_BurnCount=_BurnCount+1;

If (_BurnCount<_BurnMax) Then

       {

       [_x,_BurnCount,_BurnMax] Spawn DMW_BurnObject;

       };

} ForEach _NearestObjects;

But that method is not very dynamic. Another way would be to use a global array, with each array element holding a counter for a separate "patch" of fire.

Init.sqf:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">DMW_BURNARRAY=[];

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[This,-1,100] Spawn DMW_BurnObject

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Object=_This Select 0;

_PatchIndex=_This Select 1;

_BurnMax=_This Select 2;

//Initialise local variable

_BurnCount=-1;

//See if it's a new script started by something other than a previous copy DMW_BurnObject

If (_PatchIndex==-1) Then

       {

       _PatchIndex=(Count DMW_BURNARRAY);

       If (_PatchIndex>0) Then

               {

               _PatchIndex=_PatchIndex-1;

               };

       _BurnCount=1;

       }

       Else

       {

       //Increment the counter for the current patch

       _BurnCount=(DMW_BURNARRAY Select _PatchIndex)+1;

       };

//Update the counter in the array

DMW_BURNARRAY Set [_PatchIndex,_BurnCount];

//Get the next lot of combustables using whatever method

_NearestObjects=...blah...blah...

{

//Increment the counter for the next object

_BurnCount=_BurnCount+1;

If (_BurnCount<_BurnMax) Then

       {

       //Update the count for a specific patch

       DMW_BURNARRAY Set [_PatchIndex,_BurnCount];

       //Launch another script

       [_x,_PatchIndex,_BurnMax] Spawn DMW_BurnObject;

       };

} ForEach _NearestObjects;

Obviously there is more to it than just that, but with global arrays you can decrease the counter when old fires die out. Allowing you to wait for old fires to die out, if you reached the maximum, before spawning new ones. Also it will allow you to keep track of how many fires you have running across the entire map, simply by totalling up the count for the entire array.

There are other ways that avoid global variables. But I think that’s just making it way to complicated.

[Maddmatt 1]

Keep it simple. Make it global.

You don't know about the savegame issue? It's best to keep global vars to a minimum. First of all because of the save problem, and it's good not to have so many variables around hogging memory even when they are not needed.

[sbsmac 0]

Quote[/b] ]How about called scripts? If one script calls another script, does that second "thread" of code have access to the local variables declared in the first script?

Private variables belong to a single thread and are in scope for any called functions that do not overide the variable with their own copy.

Ie, if you use _call_ f2 from f1, f2 will have access to any private variables declared in f1. However, if you spawn or execVM f2, it will not have access to private variables since it is executing in a separate context (thread).

[vova _fox 0]

scope using in scripts too:

_a=1;

if (true) then {private ["_a"]; _a=50};

...

result: _a=1

...

_a=1;

for [{private["_a"]; _a=0},{_a>= 10},{_a=_a+1}] do

{

..

};

result: _a=1

and also in

while , switch, try catch...edc

but in

for "_i" from 0 to 10 do

{

...

};

_i will be allways private

[dmarkwick 261]

Obviously there is more to it than just that, but with global arrays you can decrease the counter when old fires die out. Allowing you to wait for old fires to die out, if you reached the maximum, before spawning new ones. Also it will allow you to keep track of how many fires you have running across the entire map, simply by totalling up the count for the entire array.

There are other ways that avoid global variables. But I think that’s just making it way to complicated.

UNN, what happens to these global variables between missions? Do they retain their last value? If so how do I reset them? I'm trying to make this mission-independent so it works from the addon.

[UNN 0]

Quote[/b] ]UNN, what happens to these global variables between missions? Do they retain their last value?

No, at least you can't access them from new missions, so there as good as gone. They won't interfere with other missions.

[dmarkwick 261]