next »

[Sick]

Didnt have time to check your script, but the _return is not used correctly there as scripts dont return anything. If that script was supposed to work as a function, then you cannot use any sleep or "long" whiles.

Why do you believe this Mandoble?
There is afaik no reason at all why you can not use sleep or long while's within a call.

There are places where you can not use sleep and that is:

• Directly from .... Lines in Editor (Init, onActivation, onDeActivation, Condition)
• Directly from eventHandlers

In these cases, you must use a spawn, exec or execVM if you wish to use sleeps (within call).
In any other case, functions called from a spawned, exec or execVM'ed script, all can include sleep.
However, sleep inside functions is not a common practice, as under usual circumstances one uses functions to make a calculation or for repeated code.

[Mandoble]

There is afaik no reason at all why you can not use sleep or long while's within a call.

As long as the following works for you (remember we were talking about functions):

Code:

// MyTest.sqf
while {true} do
{
   Sleep 1;
};

Code:

// init.sqf
MyTest = compile preprocessFileLineNumbers "MyTest.sqf";

[] call MyTest;

[Sick]

Works 100% without any doubt, as long as the [] call MyTest; (which could just as easily've been just: call MyTest) is located in init.sqf, or any other script that was either exec, execVM, or spawned.





#removed unnecessary quote of previous post

[Mandoble]

There is an important limitation, call will not return at all and any code following that call in that init.sqf will not be executed.

"Unlike scripts, functions halt all other game engine processes until the function has completed its instructions. This means functions run faster than scripts, and the result of functions is immediate and unambiguous. It can also mean that if a function takes too long to run it will have an adverse effect on game play - large functions or CPU intensive functions can cause the game to seize up until it completes. When creating a functions you want the function to be short and sweet to achieve the best results." This is what BIKI says about functions. May be the effect of intense and continuous loops in functions are not as adverse as the BIKI indicates, havent tested that.

[Sick]

Well, your statement was brute and simple: You can not use sleep or long while's inside call's
I claimed it was untrue

The fact that the script will halt in your example and not continue processing after the call MyTest is a natural and wanted feature in this case,
simply because you made MyTest a while loop that never ends.

It all comes down to what you want it to do.

At times I use conditions to pick the appropriate code, which get loaded in a variable, you just call the variable, and it doesn't matter if there is sleep, waitUntil, or long while's inside

I also use sleep for functions that take a long time to complete and are very intensive. We just give the engine some more breathing space by using sleeps, just as we would in scripts.


The danger of putting the engine on it's knees is always there with SQF, and depending on the script, also for SQS. Not just for functions.
It all comes down to properly dividing the load. Any SQF script or function can lock your game up completely, if the load is too heavy, or very quick loops without sleeps, and with a lot of commands can kill it easily.

[Mandoble]

This is a different matter. What I havent tested, and what BIKI claims (which might be wrong) is that the call stops the execution of anything else (halt all other game engine processes) until it returns, not only the execution of the calling script. If that claim is true then if I have 10 scripts running and I call a function which requires 4 seconds to return, the 10 scripts would be absolutely halted for 4 seconds, and not only these, but also anyother game engine processes. If I have a calling function with an infinite while, some process and sleep, then eveyother process would be halted forever in the game. If this is not the case, which would be great btw, then the BIKI would need some serious fixes.

[Sick]

Then we better steam up our wiki skills because I believe the wiki is wrong.

I think what they tried to explain is this:

Example 1, init.sqf

Code:

test = { player sideChat "wee"; sleep 10 };
spawn test;
player sideChat "wee2";

Example 2, init.sqf

Code:

test = { player sideChat "wee"; sleep 10 };
call test;
player sideChat "wee2";

In example 1, the player will read in sidechat "wee" and immediatly followed "wee2" (or possibly the other way around, because the spawned code has a slight delay)
In example 2, the player will read in sidechat "wee" and 10 seconds later "wee2"


In example1, the script continues processing immediatly after the spawn, because you spawn the test code in another "thread"
In example2, the calling script executes and waits for the call to complete, before it continues processing within the file, exactly the same as if there really was written in this script: player sideChat "wee"; sleep 10;

Basicly, the below is exactly the same as Example2, except that you don't use the test variable to store the code:

Code:

player sideChat "wee";
sleep 10;
player sideChat "wee2";

(except that in the original Example2, test { } block is another scope)

[Mandoble]

Sick, this is a quite interesting topic, while it is a bit offtopic into this particulat topic. To do not let it die, you might open an individual topic to discuse call, spawn and execVM advantages and disadvantages and risks, as well as possible corrections to the BIKI which might apply also to the current OFPEC Comref.

Now back on topic:

Sparticus, I understand _firer is the vehicle which is firing at the target, and it is armed with a single "M2".
Didnt check it, but the line of sight check added here should work.

Code:

private[....,....,...,...., "_los", "_losok", "_posasl", "_distance", "_wdir"];
.....
.....
While {alive _target} do
{
     _ammo = _firer ammo "M2";
     _burst = _ammo - 20;
     _los = "logic" createVehicleLocal [0,0,0];
     while {(_ammo > _burst) && (alive _target)} do
     {     
          _gunner dotarget _target;
          Sleep 1;
          WaitUntil{unitready _gunner};
          _distance = _firer distance _target;
          _losok = true;
          _posasl = [getPosASL _firer select 0, getPosASL _firer select 1, (getPosASL _firer select 2) + 2];
          _wdir = _firer weaponDirection "M2";
          for [{_i=0},{(_i < _distance) && (_losok)},{_i = _i + 10}] do
          {
             _los setPosASL [(_posasl select 0)+(_wdir select 0)*_i,(_posasl select 1)+(_wdir select 1)*_i,(_posasl select 2)+(_wdir select 2)*_i];
             if ((getPos _los select 2) < 0.1) then
             {
                _losok = false; 
             };
          };
         
          if (_losok) then
          {
             _firer action ["useWeapon", _firer, _gunner, 0];
             _ammo = _firer ammo "M2";
          };
          sleep 0.18;
     };
     deleteVehicle _los;
     sleep 1;
};

[Mr.Peanut]

[aside]There was a long thread about this on the BIS forums some time ago. I believe the conclusion was that sleep and waitUntil do work in functions that are themselves called from sqf scripts. I can not remember whether using spawn or execVM made any difference. In terms of good coding practice, if a function takes too long to exit then it is probably time to refactor your code.[/aside]

[Sick]

I will think about creating another thread. For now I just noticed some things that I disagreed on and wanted to share my opinion and view about

[aside2]I believe this is simply depending on situation and wishes of the coder. As call can be used to execute code, the executed code does not necessairly has to be a function.[/aside2]




#removed unnecessary quote of previous post