sqf Activating a trigger through an SQF

[Captinlarry 0]

https://gyazo.com/641c0226cab80eac03d04a2c5fed444b
Above is an SS of my notepad. Trying to activate a trigger through my SQF with 
triggerActivated TurboBomb;

Below are the settings of that trigger. 
https://gyazo.com/ce586674451bc34a810bb59350bb9817

 

I tried triggering the E2 setDamage [1, true]; from the sqf itself but that didnt seem to work. 
 

[major-stiffy 279]

For one the trigger has no size on the x,y axis.

[Harzach 2517]

Yup. The current condition for the trigger to activate is for ANYBODY to be present inside the non-existent trigger area.

 

triggerActivated returns the trigger's activation status, it doesn't set it. 

 

To activate a trigger via sqf, you would need to set a variable to "false" somewhere during mission init ("myTrigVar = false" for example), change the condition field in your trigger from "this" to "myTrigVar," then set your variable to "true" in your sqf.

 

Or simply execute your code in the sqf, since that's essentially what you are doing only with unnecessary steps. 

[Captinlarry 0]

1 minute ago, Harzach said:

Yup. The current condition for the trigger to activate is for ANYBODY to be present inside the non-existent trigger area.

 

triggerActivated returns the trigger's activation status, it doesn't set it. 

 

To activate a trigger via sqf, you would need to set a variable to "false" somewhere during mission init ("myTrigVar = false" for example), change the condition field in your trigger from "this" to "myTrigVar," then set your variable to "true" in your sqf.

 

Or simply execute your code in the sqf, since that's essentially what you are doing only with unnecessary steps. 

 

26 minutes ago, major-stiffy said:

For one the trigger has no size on the x,y axis.

E2 and E3 were explosive charges. Solved the issue. Needed to add 
E2 hideObjectGlobal false;
E2 enableSimulation true; \\ This
E3 hideObjectGlobal false;
E3 enableSimulation true; \\ This

Both objects were hidden in the Init. so I forgot that hideObjectGlobal does not reenable simulation. 

[Captinlarry 0]

On 12/13/2021 at 8:14 PM, Harzach said:

Yup. The current condition for the trigger to activate is for ANYBODY to be present inside the non-existent trigger area.

 

triggerActivated returns the trigger's activation status, it doesn't set it. 

 

To activate a trigger via sqf, you would need to set a variable to "false" somewhere during mission init ("myTrigVar = false" for example), change the condition field in your trigger from "this" to "myTrigVar," then set your variable to "true" in your sqf.

 

Or simply execute your code in the sqf, since that's essentially what you are doing only with unnecessary steps. 

Sorry to rehash this but Im having a similar problem again. 

Current issue is Im trying to call an SQF from a trigger. Trigger is set in the water and when players cross into the area I need it to fire the SQF which has about 15 paths and music in it. 

I thought about calling directly from the trigger but IIRC "Sleep" does not work on triggers. 

The SQF
call{playsound "Eyes";};
sleep 5;
rec = [] spawn MyPath1;
rec = [] spawn Mypath2;
rec = [] spawn Mypath3;
rec = [] spawn Mypath4;
rec = [] spawn Mypath5;
sleep 5;
rec = [] spawn Mypath6;
rec = [] spawn Mypath7;
rec = [] spawn Mypath8;
rec = [] spawn Mypath9;
rec = [] spawn Mypath10;
sleep 5;
rec = [] spawn Mypath11;
rec = [] spawn Mypath12;
rec = [] spawn Mypath13;
rec = [] spawn Mypath14;
rec = [] spawn Mypath15;

[Harzach 2517]

Don't reuse your script handles like that. Make them unique, or use "nul" if your functions don't return a value.

[Captinlarry 0]

3 minutes ago, Harzach said:

Don't reuse your script handles like that. Make them unique, or use "nul" if you don't need to reference the running scripts later.

You mean the Path Names? 

[Harzach 2517]

Quote

rec = 

 

[Captinlarry 0]

2 hours ago, Harzach said:

 

You've lost me chief 😅

 

[Harzach 2517]

rec = [] spawn MyPath1;

"rec" is, in this context, what is referred to as a script handle. 

 

You are spawning 15 scripts/functions with the same handle. Depending on the content of those scripts/functions, it might be fine. It might also not be fine. We can't know as you haven't shared your code.

[pierremgi 4864]

 

On 12/14/2021 at 2:16 AM, Captinlarry said:

E2 and E3 were explosive charges. Solved the issue. Needed to add 
E2 hideObjectGlobal false;
E2 enableSimulation true; \\ This
E3 hideObjectGlobal false;
E3 enableSimulation true; \\ This

Both objects were hidden in the Init. so I forgot that hideObjectGlobal does not reenable simulation. 

 

First of all, in MP, keep in mind where the trigger fires. If you are using a "server only" trigger, you can (may) use global commands hideObjectGlobal AND enableSimulationGlobal

If your trigger is for server + clients (not server only), use hideObject and enableSimulation  commands (could be better, you don't broadcast something and the effects are same).

In SP, global commands are not necessary.

 

 

11 hours ago, Captinlarry said:

Current issue is Im trying to call an SQF from a trigger. Trigger is set in the water and when players cross into the area I need it to fire the SQF which has about 15 paths and music in it. 
I thought about calling directly from the trigger but IIRC "Sleep" does not work on triggers. 

The SQF
call{playsound "Eyes";};
sleep 5;
rec = [] spawn MyPath1;
rec = [] spawn Mypath2;
rec = [] spawn Mypath3;
rec = [] spawn Mypath4;
rec = [] spawn Mypath5;
sleep 5;
rec = [] spawn Mypath6;
rec = [] spawn Mypath7;
rec = [] spawn Mypath8;
rec = [] spawn Mypath9;
rec = [] spawn Mypath10;
sleep 5;
rec = [] spawn Mypath11;
rec = [] spawn Mypath12;
rec = [] spawn Mypath13;
rec = [] spawn Mypath14;
rec = [] spawn Mypath15;

 

The trigger activation is not scheduled by default: if you call a code, the code doesn't accept suspension like sleep.

A sqf is usually execVMed , i.e. [] execVM "yourSqf"  which is roughly same as [] spawn compile "yourStringedCode"

So, execVMing a sqf makes it scheduled and you can sleep/waitUntil into the code (inside the sqf).

 

You probably don't need multiple sqf form a trigger.

 

On the other hand, spawning or execVMing multiple codes just means your are running all these scripts in parallel. (the only delay is made by sleep in your case). Read the warning here.

NOTE : rec, here is a handle and that doesn't matter to reuse it as you do if you are not using this handle! It's just a "waste" of code and you could write:

[] spawn Mycode1; // without handle

[] spawn Mycode2; // without handle

as well (in debug console or a trigger activation,now, you don't need handles).

But the issue remains : you are still running your codes in parallel.

 

What are your paths? Waypoints? If so you don't need to spawn each of them. Just create a unique path (including  path1, path2... path5) then sleep then path6 + path7...+path10.
addWaypoint is fine for that.

I'm not sure why you are sleeping before starting some other "paths". Don't confuse about the delay between 2 codes and the completion for a unit to execute a path.

addWaypoint and waypoint commands can help if you want to stay (complete) in a position before starting to a new waypoint.

[Captinlarry 0]

3 minutes ago, pierremgi said:

 

 

First of all, in MP, keep in mind where the trigger fires. If you are using a "server only" trigger, you can (may) use global commands hideObjectGlobal AND enableSimulationGlobal

If your trigger is for server + clients (not server only), use hideObject and enableSimulation  commands (could be better, you don't broadcast something and the effects are same).

In SP, global commands are not necessary.

 

 

 

The trigger activation is not scheduled by default: if you call a code, the code doesn't accept suspension like sleep.

A sqf is usually execVMed , i.e. [] execVM "yourSqf"  which is roughly same as [] spawn compile "yourStringedCode"

So, execVMing a sqf makes it scheduled and you can sleep/waitUntil into the code (inside the sqf).

 

You probably don't need multiple sqf form a trigger.

 

On the other hand, spawning or execVMing multiple codes just means your are running all these scripts in parallel. (the only delay is made by sleep in your case). Read the warning here.

NOTE : rec, here is a handle and that doesn't matter to reuse it as you do if you are not using this handle! It's just a "waste" of code and you could write:

[] spawn Mycode1; // without handle

[] spawn Mycode2; // without handle

as well (in debug console or a trigger activation,now, you don't need handles).

But the issue remains : you are still running your codes in parallel.

 

What are your paths? Waypoints? If so you don't need to spawn each of them. Just create a unique path (including  path1, path2... path5) then sleep then path6 + path7...+path10.
addWaypoint is fine for that.

I'm not sure why you are sleeping before starting some other "paths". Don't confuse about the delay between 2 codes and the completion for a unit to execute a path.

addWaypoint and waypoint commands can help if you want to stay (complete) in a position before starting to a new waypoint.

 

4 hours ago, Harzach said:

rec = [] spawn MyPath1;

"rec" is, in this context, what is referred to as a script handle. 

 

You are spawning 15 scripts/functions with the same handle. Depending on the content of those scripts/functions, it might be fine. It might also not be fine. We can't know as you haven't shared your code.

The code is a UnitCapture log for 15 aircraft. Each aircraft has its own path, Flight one does its flyover first, 2 flight second and so on. I would post it but its 15 different SQFs which read as 
Path1=(data);
[B1,Path1] spawn BIS_fnc_unitPlay;
B1 engineOn true;

[] spawn MyPath1;
[] spawn Mypath2;
[] spawn Mypath3;
[] spawn Mypath4;
 [] spawn Mypath5;

Better?

[pierremgi 4864]

For your aim, if I'm right, you need to wait for starting a new path. For example B1 executes path1 then wait for 5 sec, then start path6.

If I read correctly, you wrote something like:

[] spawn {Path1 = [array1OfPositions]; [B1,Path1] spawn BIS_fnc_unitPlay};

[] spawn {Path2 = [array2OfPositions]; [B2,Path2] spawn BIS_fnc_unitPlay};

....

 

Waiting for 5 sec after reaching the end of path1, needs some extra code where the handle I skipped could be useful here:

 

 If  each aircraft has is own path but must start one after the other, you have 2 possibilities:

 

Define path arrays as usual then:

1 - for delayed starts each 5 sec, no matter the duration of the paths:

[] spawn {
  [B1,Path1] spawn BIS_fnc_unitPlay};
  sleep 5;
  [B2,Path2] spawn BIS_fnc_unitPlay};
  sleep 5;
  [B3,Path3] spawn BIS_fnc_unitPlay};
};

 

2- for start only when previous aircraft has completed its path:
 

[] spawn {
  _handle = [B1,Path1] spawn BIS_fnc_unitPlay};
  waitUntil {sleep 0.1; scriptDone _handle};
  sleep 5;
  _handle = [B2,Path2] spawn BIS_fnc_unitPlay};
  waitUntil {sleep 0.1; scriptDone _handle};
  sleep 5;
  _handle = [B3,Path3] spawn BIS_fnc_unitPlay};
  ...
};

 

 

EDITED