Triggers VS Spawn

[circassian 1]

Hi guys,

What is it with spawn and triggers? I've made a mission where a spawn airstrike across a trigger them the trigger should activate the alarm, or any action can a trigger do.. but it seems like the trigger can't see a spawn units.. What to do?

[zulu1 145]

Can you post snippets of what you're doing?

A trigger by itself can not spawn anything. You need to use scripting commands like createUnit or createVehicle.

Typically a "spawn" script will be run from a trigger or from the init.sqs.

If you are using a simulated bombardment script then only an exploding shell is spawned at random or selected points. A shell is not a unit and dosen't have a side, so it can not activate a trigger. Maybe you can use an EventHandler in the trigger.

Edited June 14, 2013 by Zulu1

[circassian 1]

Hi Zulu1

I'm not trying to make a trigger spawn any thing, the case is: I have a pilot, and when I call an airstrike he will be spawn in an A10 and hit the target area by onmapsingleclick coordinates. But before he reaches the enemy base, there is a trigger activate by west it should launch the alarm.. and that what is not happens.. is it because the spawn air craft not really a unit so the trigger cannot sees it or what?

[*zeewolf* 4]

Please post the activation parameters of the trigger.

Bear in mind that you can bind a triggers activation to a single group by using the editor's group mode to drag a connection between a unit and the trigger. You should be able to link the trigger to the A-10 pilot's group, since you need to have an editor placed unit to provide a group to spawn the pilot into.

Alternatively just set the trigger to "Anybody Present" and monitor the units in the trigger zone using a script.

So normally, I would just place a soldier down in the editor with "A10Group = group this; deletevehicle this" in the unit's initialisation field. This gets you a reference to an empty group for spawning units into. Put down two waypoints for the unit, a move and a cycle to provide simple scripted navigation. Then a trigger set to "Anybody Present" called Trigger1 with no other parameters. The spawning and trigger script would then be:

; spawn A10
_pilot = "SoldierWPilot" createunit [_pos, A10Group]
_vehicle = "A10" createvehicle _pos
_unit moveindriver _vehicle
; "winch" the plane for instant takeoff
_vehicle setpos [getpos _vehicle select 0, getpos _vehicle select 1, 500]
; fly the A10 to the position
[A10Group,0] setwppos (getpos Trigger1)
[A10Group,1] setwppos (getpos Trigger1)
; wait for A10 to be in trigger zone
#lp
~0.5
?!(alive _pilot): exit
?!((vehicle _pilot) in list Trigger1): goto "lp"
hint "The A10 is in the trigger area!"

This has an added advantage that no complicated code is required in the trigger itself, which is desirable since triggers are checked every frame of the simulation, putting lots of code in a trigger's condition field is inefficient. With a script you can choose how often the condition code is run by adjusting the loop period, the loop's list will still be recalculated every frame by the engine, but it will be considerably quicker with no trigger condition code to parse.

Edited June 23, 2013 by *Zeewolf*
Changed loop period to match update frequency of trigger's list

[Pulverizer 1]

Triggers only check their condition every 0.5 seconds. You can verify this with a condition like:

call{player globalchat format["%1",time];false}

[DanAK47 1]

Change your OnMapSingleClick so that it checks whether or not the coordinates fall within the area of your trigger (a simple distance check would be sufficient, assuming a round trigger and not rectangular) and activate the alarm if so.

[*zeewolf* 4]

Triggers only check their condition every 0.5 seconds. You can verify this with a condition like:

call{player globalchat format["%1",time];false}

OK, yes, you're right. Here's the thread with the nuts and bolts of OFP loop performance. I must have been thinking of the performance hit incurred by using @'s in scripts. Isn't another advantage of scripts that you have more control over the locality of MP variables they control than triggers since they can implicitly synchronise them?

I also checked and found that a trigger's list is only updated twice a second, it's not just the evaluation of the scripted condition (which makes sense from an engine perspective). So that means having scripted loops that check the contents of a trigger area more than twice a second are wasting CPU cycles.

Edited June 17, 2013 by *Zeewolf*

[Pulverizer 1]

Isn't another advantage of scripts that you have more control over the locality of MP variables they control than triggers since they can implicitly synchronise them?

Not really, a trigger can also have a condition to only activate locally (eg, condition: local serverLogic && this, onActivation: obj1done=true; publicVariable "obj1done"). I would rather say that in some cases it's a waste of resources to make a trigger for a condition that only one client or the server needs to check.

[circassian 1]

Dear All,

Thanks a lot for your efforts, but I'm still having the problem.. kindly have a look at the demo mission below.

http://www.mediafire.com/download/m4l7qmu154zzfh9/test.rar

One more thing, the shilka doesn't see the plane too in addition to the trigger.

[Pulverizer 1]

Try using createVehicle instead of camCreate. I think camCreate is intended for creating special fx, so the planes might not have all the necessary properties that "real" planes do for the trigger to activate.

[circassian 1]

Thanks Pulverizer, It is working perfectly with createVehicle :)