call vs spawn

[CarlGustaffa 4]

Hi

I have on and off for about a year tried to get the enamy AI in my Domination version to drop visible flares and sometimes evade missiles when we shoot at them. The flares are the mado flares. But I have constantly, both in single and multiplayer testing, ended up with serious problems regarding this missile handler. Until yesteday that is.

It starts out as usual with:

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

_vehicle = _this select 0;

_ammo = _this select 1;

_who = _this select 2;

_missile = nearestObject [_who,_ammo];

server globalChat format ["nearest = %1, _missile = %2", nearestObject[_who,_ammo],_missile];

etc...

But this had a weird problem. nearest = %1 would return the actual missile. But _missile would always return <null> (yes, declared in private statement). Wtf was going on here? I always claimed ArmA by be the buggy culprit on this one. So I checked the players eventhandler which works, and they're pretty much the same, except this _missile returns what it should. So I copied the code that starts it, and it stuck me: The player version is using 'spawn', while my old AI attempt has always been using 'call' command.

Now, the question: Why on earth heaven and below doesn't the _missile = thingy work using call, but works fine when using spawn? It just doesn't make sense to me.

Btw, made a test run last night, and it finally looks awesome in multiplayer (PVEHs)

Edit: Spelling

[General Barron 0]

Is this run from an event handler?

If so, I suspect that the event handler gets fired just *before* the actual fire event takes place. So, when using call, (which runs all its code in that very frame), you don't have the missile created yet. When you use spawn, the code is run on the *next* frame, at which point the missile has been created.

Just a guess, but this kind of frame-by-frame stuff definitely happens when you are scripting with dialogs.

[Maddmatt 1]

I suppose you are using Mando's missiles?

When you use call, the game stops everything else and runs the script code. When you use spawn the game tries to do both at once so the script code isn't run immediately.

What's probably happening here when you use call is that the fired missile is being picked up by the script, then this fired missile is deleted by Mando's scripts and replaced with a scripted missile.

When you use spawn, Mando's code is run first and your code picks up the new missile created by Mando's code.

[Rommel 2]

Spawn creates another instance outside of its scope., while Call stops all code within its and outside scope to run the code.

[CarlGustaffa 4]

Hi and thanks for answering. No, Mando Missiles was not used, although I used his codes for creating and moving flares.

I can only assume that General Barron's answer seems logical now. Maybe if I've had a couple of lines of code before setting the _missile = variable, it would work (since it works in the line below). But I'll stay with spawn which seems like the better way of doing this anyway.

I've been going at this one on and off for about a year not figuring out what was wrong

[mandoble 1]

then this fired missile is deleted by Mando's scripts and replaced with a scripted missile.

When you use spawn, Mando's code is run first and your code picks up the new missile created by Mando's code.

Yes and no, mando missile countermeasures dont use any event hander. And mando missiles are not deviated by any external script, the missile itself decides which one to track in each situation (depending on angles, distance and missile resistance to countermeasures), the real target or the flares. And after crossing the flares cloud the missile might pretty well keep pursuing the original target if it is still inside its detection cone.

[VictorFarbau 0]

I wonder, is there any difference in behaviour when calling SQF from SQS scripts?

I am calling some new SQF scripts from SQS scripts and I don't see that the SQS script is waiting for the SQF to finish. It just carries on and quits correctly.

VictorFarbau

[General Barron 0]

I wonder, is there any difference in behaviour when calling SQF from SQS scripts?

I am calling some new SQF scripts from SQS scripts and I don't see that the SQS script is waiting for the SQF to finish. It just carries on and quits correctly.

VictorFarbau

How are you "calling" the sqf script?

call -> calling script waits for script to finish, passes return value to where you called the script from

spawn / execVM -> calling script does not wait for script to finish, handle to the script is returned (instead of a return value)