Activating SecOps Random missions by trigger

[Helmut_AUT 0]

Hi all

Currently I'm using

this setVariable ["settings", [[], true, nil, nil, false]];

to deactivate random mission in SecOps, I keep it only for support requests.

As I understand it, the empty brackets [] actually contain the pool of possible mission types, so setting them empty means SecOps will not generate missions.

However, I want to give the player a choice to activate SecOps by radio trigger. Which would likely mean I'd have to use

this setVariable ["settings", [["missiontype1", "missiontype2", "missiontype3"], true, nil, nil, false]];

But the only mission type I saw mentioned is "ambush". And even that doesn't quite seem to work. Anyone found a way to do this?

[DnA 5154]

To activate a specific SecOp, use the following:

["ambush", true, player] call BIS_SOM_requestSecOpFunc;

The first parameter is the name of the SecOp as String (examples: "ambush", "attack_location", "trap", "rescue", "patrol", "escort", "defend_location", "destroy", "search" ... basically the class names in CfgSecOps).

The second parameter determines the priority of the request as a Boolean. true starts the SecOp right away, false adds it to the queue for later.

The third parameter is a reference to the SOM as Object.

[Helmut_AUT 0]

Thanks. I have no clue where to get the class names in CfgSecOps (without de-pboing tons of files) so now I have at least a list of possible missions.

Do I have to activate them all separatly, or can I also write:

this setVariable ["settings", [[""ambush", "attack_location", "trap", "rescue", "patrol", "escort", "defend_location", "destroy", "search"], true, nil, nil, false]];

and basically set the mission pool from empty [] to full? Would SOM then start generating missions again, or is that disabled for good with the initial init on an empty mission pool?

To be precise, I don't want to force a mission on the player, just get the SOM module to start generating missions randomly, which had been disabled at mission start.

Edited June 24, 2009 by Helmut_AUT

[DnA 5154]

Thanks. I have no clue where to get the class names in CfgSecOps (without de-pboing tons of files) so now I have at least a list of possible missions.

The ones I listed are pretty much all of them for now :)

Would SOM then start generating missions again, or is that disabled for good with the initial init on an empty mission pool?

You cannot use the settings variable again after the start. However, try updating the pool variable manually:

(player getVariable "mainScope") setVariable ["pool", ["ambush", "destroy"]];

[icebreakr 3159]

DNA: on a similiar note, in A1 - how do you make a mission so only C/O (player name 'hq') can pick out mission from 8 objectives or select Random so script picks one randomly. Of course everything needs to be MP compatible. Thank you.

[Helmut_AUT 0]

Thanks for again answering, Dna. Didn't seem to work though. Normally the SecOps generates the first mission within 60 seconds after game launch - if I hit this script line, it still hasn't done anything 5 minutes later.

Seems like the only way to disable secondary random missions and re-enable them later would be to delete old and spawn a new sec ops module. Should that work? But might be messy in multiplayer.

[Helmut_AUT 0]

I'm still looking for a solution to this problem, does anyone have any ideas?

Summary again:

I want SecOps present and synched so the player can use the support functions, but I only want it to start generating random side missions when the player activates it with a radio trigger. Killing the side missions in the init field of the SecOps module works, but I haven't been able to reverse it yet.

[Jedo 10]

I'm still looking for a solution to this problem, does anyone have any ideas?

Summary again:

I want SecOps present and synched so the player can use the support functions, but I only want it to start generating random side missions when the player activates it with a radio trigger. Killing the side missions in the init field of the SecOps module works, but I haven't been able to reverse it yet.

I don't know if you're still having the problem, but the solutions put in this (and the main Secops) thread worked for me.

1. You create the module (and synchronize it to player of course) and in the Initialization put

this setVariable ["settings", [[], true, nil, nil, false]];

2. Now you create a trigger, group it to the player and in the on Activation field of the trigger choose either "Present" or "notPresent" depending on what you're trying to do. Tweak around with it.

Now you have two options for the on act field of the trigger:

2.1

["ambush", true, player] call BIS_SOM_requestSecOpFunc;

or replace "ambush" with an other mission type. This will make a one time mission

2.2

(player getVariable "mainScope") setVariable ["pool", ["ambush", "destroy"]]; 

This seems to manually enable the module back (with those two missions) - although how I can't figure out - the code doesn't mention bis_som anywhere.

You might want to use "Repeatedly" option in the trigger!

The 2.2 code, however, will keep giving you missions until you drop. So in order to turn the thing back off once you leave the trigger's territory and get back to your base or whatever, you have to add the following code in the onDeactivation field of the trigger.

(player getVariable "mainScope") setVariable ["pool", []]; 

With other words empty the pool of missions.

Edited July 19, 2009 by Jedo

[Helmut_AUT 0]

Jedo, thanks for the reply but for me variant 2.2 didn't work. After firing the trigger I had not recived a call for SecOps mission in 20 minutes wait time. It does work for you?

I think the reason it does work is that "mainscope" holds all variables for the game, and "pool" may be ACM specific enough as reference.

[Jedo 10]

Jedo, thanks for the reply but for me variant 2.2 didn't work. After firing the trigger I had not recived a call for SecOps mission in 20 minutes wait time. It does work for you?

I think the reason it does work is that "mainscope" holds all variables for the game, and "pool" may be ACM specific enough as reference.

Hmm that is strange, does work for me.

Did you try adding support actions to the same trigger, just to see if the SOM and the trigger work? Before that mainScope code add

[["transport", "aerial_reconnaissance", "supply_drop", "tactical_airstrike", "artillery_barrage"], player] call BIS_SOM_addSupportRequestFunc;

If that part gets activated (you should get a message when it gets triggered) then I would start looking for missing bits in the mainscope code - maybe a mistype or something.

Another thing to try would be change the activation of the trigger if that's an option for you. Instead of radio alpha make it the way I have it now: group the player to the trigger and use "present" condition on the group leader (the player) in order to activate the trigger when you enter its zone, i.e. the area of operations.

Edited July 19, 2009 by Jedo