Secondary Ops Manager Module Discussion

Sorry if this has been asked before, but is there a way to change the units to anything besides always spawning Russians? I'd like to use this module on Reshmaan, however its not very realistic to be fighting Russians on that map. Thanks

Humblest of apologies to all for digging up a very old thread, but I figure this is the most deserving place to post this, since so many asked for this for so long and it was never answered.

It was pretty difficult to figure out, but here is how you introduce custom content into SOM missions.

For these examples:
1. Place a player unit (soldier1) synched with SOM.
2. Place an enemy soldier (enemySoldier1).
3. Save mission.
4. Place copies of SOM scripts (see below) in your mission folder.
5. Call these by radio trigger or by a script:

Aerial Recon:

//---- Replacing an entire set of phase scripts with custom copies in the mission file:
[
	// Here is what people commonly use the call BIS_SOM_requestSecOpFunc function for. Adding an immediate secop:
	"aerial_reconnaissance",
	true,
	soldier1 getVariable "mainscope",

 	//--- This is an optional parameter passed to the secops mission - must be an array, which may contain an array
	//--- Params look for specific things. Refer to the mission phase scripts to know which params will be sought.
	//--- Aerial Recon looks for a target position array. The position is an array, placed inside of the params array:
	[getPos soldier1],

	//--- These are optional script paths which will replace the SOM's core phase scripts. Must be scripts in
	//--- your mission folder. Copy these from the SOM aerial recon phase scripts and test. (I used sidechats,
	//--- they appeared on screen.)  Observe that this is a set of arrays inside an array.
	//--- The Script Title first... ...then script path in mission folder.
	[
		["create_briefing_assets", "01_create_briefing_assets.sqf"],
		["briefing", "02_briefing.sqf"],
		["delete_briefing_assets", "03_delete_briefing_assets.sqf"],
		["briefing_timeout", "04_briefing_timeout.sqf"],
		["not_accepted", "05_not_accepted.sqf"],
		["accepted", "06_accepted.sqf"],
		["create_secop_assets", "07_create_secop_assets.sqf"],
		["secop", "08_secop.sqf"],
		["delete_secop_assets", "09_delete_secop_assets.sqf"],
		["debriefing", "10_debriefing.sqf"]
	]
] call BIS_SOM_requestSecOpFunc;

How it looks in a trigger:

["aerial_reconnaissance",true,soldier1 getVariable "mainscope",[getPos soldier1],[["create_briefing_assets","01_create_briefing_assets.sqf"],["briefing","02_briefing.sqf"],["delete_briefing_assets","03_delete_briefing_assets.sqf"],["briefing_timeout","04_briefing_timeout.sqf"],["not_accepted","05_not_accepted.sqf"],["accepted","06_accepted.sqf"],["create_secop_assets","07_create_secop_assets.sqf"],["secop","08_secop.sqf"],["delete_secop_assets","09_delete_secop_assets.sqf"],["debriefing","10_debriefing.sqf"]]] call BIS_SOM_requestSecOpFunc;

Tactical Airstrike:

//---- Replacing a single phase script with a custom copy in a subfolder of the mission file:
[
	"tactical_airstrike", // mission name
	false, // priority mission, true or false
	soldier1 getVariable "mainscope", // "mainscope" is the SOM object synched to the player
	[getPos enemySoldier1], // params looks for airstrike coordinates array. Can be empty [[]] for no param given.

	// Copy this one from the SOM tactical airstrike phase scripts and test. (I used sidechats - they appeared on
	// screen.)  This particular script contains the aircraft arrays:
	// script title first.... ....then script path in mission folder
	[
		["create_secop_assets", "tactical_airstrike\07_create_secop_assets.sqf"]
	]
] call BIS_SOM_requestSecOpFunc;

How it looks in a trigger:

["tactical_airstrike",false,soldier1 getVariable "mainscope",[getPos enemySoldier1],[["create_secop_assets","tactical_airstrike\07_create_secop_assets.sqf"]]] call BIS_SOM_requestSecOpFunc;

The phase scripts are found in the SOM's "data\scripts\secops\<mission name>" folders.

All of the posts I've found regarding the BIS_SOM_requestSecOpFunc, including on the SOM's wiki page, only show three parameters passed in. But it will accept five. The last two are optional, and used to introduce a params array and custom phase scripts into the SOM. The custom phase scripts can be used to change the unit types generated by the mission.

Just a word of caution for the overly-ambitious.... I found the phase scripts are dependant on the secOps.fsm which runs them as well as its own code. What you do in a custom phase script could affect a core phase script, or could come into conflict with the fsm. Just something to keep in mind, but replacing a soldier type or aircraft seems simple enough. Sometimes simple is better.

Sorry if this has been asked before, but is there a way to change the units to anything besides always spawning Russians? I'd like to use this module on Reshmaan, however its not very realistic to be fighting Russians on that map. Thanks

I second that. I want CHDKZ Insurgents instead of the russians. How to do that?

@OpusFmSPol

Man i have no idea what are you talking about, but i somehow feel that you are talking about making your own side missions for SOM module. I would really like to have my own custom side missions in SOM module, so can you please explain it for us dummies more dummiefriendly?

i somehow feel that you are talking about making your own side missions for SOM module.

In a very real way, yes. Not recreating the SOM as a new addon (because I lack that skill), but modifying what it does from outside the module, by copying scripts to the mission folder and using them instead of the core scripts. It's not adding new missions (I haven't found a way to amend a config into what the cfgSecops.hpp lays out), but it will take the current mission scripts and allow you to change the content to what you want. There are some limitations I've run into thus far:

a.) The SOM is limited to the cfgVehicles of A2 and OA. My understanding is it won't use content from DLC or mods;

b.) The scripts and the fsm's are integrated, they work hand-in-hand, thus my word of caution above; and,

c.) Haven't figured out how to add new missions into the cfgSecOps. It's limited to redefining the current missions to something new.

I want CHDKZ Insurgents instead of the russians. How to do that?

Usually the phase scripts named "07_create_secop_assets.sqf" dictate which units are generated, so those would be the first place to go. Look in the SOM\data\scripts\secops\<mission name>" folders. Each folder has a set of phase scripts, all having the same names. Don't bother with the ones in the secops folder, those are base templates to use for custom missions after it's found how to amend the cfgSecOps. The ones in the mission name folders are the ones to review.

I'll follow up with some info, but it is very late in my time zone right now.

--- Edit --

An example, I play my mission as side West in Chernarus on OA. When I call an airstrike, the aircraft is ALWAYS an A-10; but an A-10 doesn't fit with my scenario, the F35B is the aircraft my mission uses.

Each SOM mission has 10 to 11 "phase scripts" that run the code for each phase of the Secop. Generally the phases are: briefing markers, communication, decision, spawn units, conduct mission, debrief or abort, and cleanup. I want to modify the phase script that spawns units for the tactical airstrike.

Going through the phase scripts in the SOM secops\tactical_airstrike folder, I find this for West aircraft in "07_create_secop_assets.sqf":

if (BIS_SOM_a2Avail) then
{
if ((faction _leader) == "CDF") then
{
_types = ["Su25_CDF"];
_bombTypes = ["AirBombLauncher"]
}
else
{
_types = ["AV8B", "A10", "F35B"];
_bombTypes = ["BombLauncher", "BombLauncherA10", "BombLauncherF35"];
};
};

if (BIS_SOM_ahAvail) then
{
_types = ["A10_US_EP1"];
_bombTypes = ["BombLauncherA10"];
};

........

private ["_type", "_bombType"];
_type = _types call BIS_fnc_selectRandom;
_bombType = _bombTypes call BIS_fnc_selectRandom;

So by the core phase scripts, if you play West, in A2 you'll get a Frogfoot for CDF, or randomly get a Harrier, Warthog or Lightning II for USMC; but in OA you'll only get a Warthog. There lies my problem.

To fix this, I copy that phase script into my mission file. Then I change this:

if (BIS_SOM_ahAvail) then
{
_types = ["A10_US_EP1"];
_bombTypes = ["BombLauncherA10"];
};

To read this:

if (BIS_SOM_ahAvail) then
{
_types = ["F35B"];
_bombTypes = ["BombLauncherF35"];
};

Now when it goes to select random for OA, only an F35B will be chosen.

In the mission when time comes for the airstike to be called in, I have "TeamLeader2" (synched to a SOM) activate a radio trigger containing:

["tactical_airstrike",true,teamLeader2 getVariable "mainscope",[getPos targetZone_1],[["create_secop_assets","07_create_secop_assets.sqf"]]] call BIS_SOM_requestSecOpFunc;

In the array, the fifth element: [["create_secop_assets","07_create_secop_assets.sqf"]] tells the SOM (for TeamLeader2) that when it reaches the "create_secop_assets" phase, to use the script "07_create_secop_assets.sqf" in my mission folder instead of the core script.

When the planes show up, I have two Lightning II's instead of two Warthogs.

I found this is one way to make changes. There is another:

In this post, Tupolov pointed out that by recreating the SOM's folder structure in your mission file, you can copy SOM scripts over to your mission and modify them there. SOM will run them as long as the folder path the script resides in remains the same that SOM uses.

http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=2057322&viewfull=1#post2057322

It works because SOM scripts are called using soft path ("ca\missions\som\") rather than hard path ("\ca\missions\som\") .... Whereas the "\" in front of "ca" forces core scripts to run (hard path), when not having "\" before "ca" the game engine first searches the mission folder before searching core (soft path). I was already using that to clear the functions error many complain about. Functions also uses "ca" instead of "\ca".

scenario:

Lets say something fails and you want a value dumped to the .rpt so you can find what's going wrong. You believe the value is being passed to the processEvent.sqf (BIS_SOM_processEventFunc) where it fails. You want to know what's being passed into it.

The processEvent.sqf resides in folder ca\missions\som\data\script\functions. So the first thing you do is recreate the file path in your own mission by adding the SOM folder path. Now the mission folder structure shows:

My_Laser_Strike_Mission\ca\missions\som\data\scripts\functions

You copy the processEvent.sqf and place it in the functions folder. Then you open the script, and where it says:

_event = BIS_SOM_clientEvent select 0;
_params = BIS_SOM_clientEvent select 1;
_mainScope = BIS_SOM_clientEvent select 2;

you change it to read:

_event = BIS_SOM_clientEvent select 0;
diag_log _event;
_params = BIS_SOM_clientEvent select 1;
diag_log _params;
_mainScope = BIS_SOM_clientEvent select 2;

When you run the mission, every time SOM calls the function "BIS_SOM_processEventFunc", the processEvent.sqf will run from your mission folder instead of core and you'll get the diag_log values dumped to your .rpt file.

I found you can move ANY or ALL of the SOM scripts to the mission file and modify them. That includes the SOM's init.sqf, main.sqf, the functions and the phase scripts.

--- Edit note: -- When using the "Corepatch" addon to clear v1.63 errors, the request SecOps method should be relied on to run modified phase scripts. The "ca" folder method won't work for certain scripts. To clear errors, script paths have to be diverted by the Corepatch, but phase scripts can still be replaced with custom ones using the request SecOps method.

Corepatch addon by Goliath86: http://forums.bistudio.com/showthread.php?184371-WIP-CorePatch-config-patch-for-ArmA-2-OA

When DnA posted that there was a lot you could do with the SOM, he wasn't joking.

Thank you Bohemia! Thank you Joris-Jan van 't Land! Nothin' but love right now!

--- Final edit --

@ Tupolov:

thanks for pointing out the folders option.

Not sure if this is allowed by BIS, but it certainly helps get around some of the issues with the modules (and MP play).

I believe they permit it so long as it's done within the terms and conditions of the APL-SA License which covers the missions.pbo, available in the Arma License Data Pack.

http://www.bistudio.com/community/licenses/arma-public-license-share-alike

@OpusFmSPol You my dear sir, are my hero now.

Just one question. What are theese

select 1
select 2

thingyes? its not the first time i see them in code for arma but what they do is somehow eluding me.

They're for choosing an element out of an array. It's starts at zero, so first element in an array is "select 0", second element is "select 1".

passedArray = ["thisIsSelect0","thisIsSelect1","thisIsSelect2"];

A great guide is here, helped me out a lot.

http://forums.bistudio.com/showthread.php?100559-Beginners-guide-Arrays

They're for choosing an element out of an array. It's starts at zero, so first element in an array is "select 0", second element is "select 1".

passedArray = ["thisIsSelect0","thisIsSelect1","thisIsSelect2"];

A great guide is here, helped me out a lot.

http://forums.bistudio.com/showthread.php?100559-Beginners-guide-Arrays

OK thanks :-)

I haven't been able to find this posted anywhere else, so I'd like to contribute it here. Here is how you can get SOM supports added to a simple, basic editor Warfare mission without doing any file scripts:

1.) Lay down some West units, and some East units. Don't group them, they will each be a leader.
(Note: For this scenario, make the first placed unit side WEST as well as the PLAYER. It's for a trigger call below.)

2.) Place a Warfare module.

3.) Synchronize each of the units to the Warfare module.

4.) Place the units where you want their base to be at start.
(In a bare-bones Warfare mission, no markers or scripts, they start where you place them.)

5.) Place a Secops Manager (SOM) module on the map and synchronize it to the player unit.

Now, this is where the SOM supports come in:

6.) In the Warfare module Init field, put this:

BIS_WF_OldSupportLevel = 1;

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

WestPlayer1Funds = 20000;

Transport: 3000
Supply Drop: 5000
Aerial Reconnaissance: 5000
Artillery Barrage: 6000
Tactical Airstrike: 6000

// ---Adding all supports:
[["artillery_barrageWF","aerial_reconnaissanceWF","tactical_airstrikeWF","transportWF","supply_dropWF"],player,[],[true,true,true,true,true]] call BIS_SOM_addSupportRequestFunc;

// ---Adding a few supports:
[["aerial_reconnaissanceWF","tactical_airstrikeWF","transportWF",],player,[],[true,true,true]] call BIS_SOM_addSupportRequestFunc;

// ---Adding one support:
[["aerial_reconnaissanceWF"],player,[],[true]] call BIS_SOM_addSupportRequestFunc;

This is for CarlGustaffa, a666, and Stegman, who all asked in this thread, but never got answered. Hopefully others will find this useful as well.
http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=1296331&viewfull=1#post1296331
http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=1711061&viewfull=1#post1711061
http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=1737798&viewfull=1#post1737798

In the editor, by default SOM missions don't work in Warfare. Place players, synch a Warfare module, synch some SOMS, and the SOM's missions come over the radio but there's just no way to respond. When you go to comms menu 0-8, there's a Support option listed but no SecOps option to respond with.

Generally one could say there's a menu conflict; SOM uses the comms menu 0-8-2 for the Secops missions, but Warfare uses comms menu 0-8-2 to "Enable AI" in High Command. It's a conflict that Warfare wins.

But the SecOps menu can be reassigned to a different channel in the Warfare comms menu, using a custom Init Client script. The same script is used to fix Warfare's respawn failure in v1.63, as I posted elsewhere:
http://forums.bistudio.com/showthread.php?180972-How-to-Fix-Respawn-Failure-in-Warfare2-Editor-Missions&p=2738413&viewfull=1#post2738413

Warfare already reassigns the SOM's Support menu; it shows under menu 0-8-7 instead of 0-8-3. It's just a matter of adding the Secops Menu to a channel Warfare doesn't use. (I'll use 0-8-8, which is reserved for "Dismiss" request, as I don't think the Dismiss Player function was completed(?))

As the respawn post says, a custom Init Client is used to modify the Client setup in Warfare. It can customize client aspects of your mission's init, which includes the comms menu. A .pbo extractor is used to obtain the core script, and the modified copy is run from your mission folder instead of core.

To add the SecOps communications to an editor Warfare mission:

1). Place player and playable units; two sides or three. Don't group them, each will be a leader.

2). Place a Warfare module. Synchronize the module to each playable unit.

3). Place a Secops Manager (SOM) module for each playable unit and synchronize them. Each playable unit must have a SOM of its own synchronized to it.

4). In the warfare module, enter this in the Init field:

BIS_WF_Common SetVariable ["customInitMissionScript","Init_Mission.sqf"];

5. Save the mission.

6). Add the custom Init_Mission.sqf and Init_Client.sqf scripts to your mission folder following the Warfare respawn fix instructions, parts (4) and (7). (the link above)

7). Then go into your mission folder's custom Init Client and find the section that sets up the comms menu. Modify this portion:

if (_supportMenu != "") then
{
	BIS_WF_TeamCommunicationMenu = BIS_WF_TeamCommunicationMenu + 
	[
		["", [], "", -1, [], "0", "0", -1],
		[Localize "STR_SOM_REQUEST_SUPPORT",[8],_supportMenu,-5,[["expression", ""]],"1","1",-1]
	];

	BIS_WF_CommanderCommunicationMenu = BIS_WF_CommanderCommunicationMenu +
	[
		["", [], "", -1, [], "0", "0", -1],
		[Localize "STR_SOM_REQUEST_SUPPORT",[8],_supportMenu,-5,[["expression", ""]],"1","1",-1]
	];
};

to read this:

if (_supportMenu != "") then
{
	BIS_WF_TeamCommunicationMenu = BIS_WF_TeamCommunicationMenu +
	[
		["", [], "", -1, [], "0", "0", -1],
		[Localize "STR_SOM_REQUEST_SUPPORT",[8],_supportMenu,-5,[["expression", ""]],"1","1",-1],
		[localize "STR_SOM_SECOPS",[9],"#USER:BIS_MENU_SOM_SecOps",-5,[["expression", ""]],"1","1",-1]
	];

	BIS_WF_CommanderCommunicationMenu = BIS_WF_CommanderCommunicationMenu +
	[
		["", [], "", -1, [], "0", "0", -1],
		[Localize "STR_SOM_REQUEST_SUPPORT",[8],_supportMenu,-5,[["expression", ""]],"1","1",-1],
		[localize "STR_SOM_SECOPS",[9],"#USER:BIS_MENU_SOM_SecOps",-5,[["expression", ""]],"1","1",-1]
	];
};

(Please note the comma added following each original Support menu line. It's important. For some time it had me guessing what I had missing.)

8. Save and run the mission.

Shortly after mission start, HQ should give you a SecOps tasking. When you hit menu 0-8, the SecOps comms will be listed as number 8. When selected, you're given the option to accept or decline the mission. Accept, and the Secop will commence. And while this is going on, Warfare does its thing in the background. And the completed SecOps get listed among the Warfare completed missions.

Hope this is found helpful to some.

Apologies to all for the multiple posts. I know it's frowned upon, but I hope these contributions are found to be something worthwhile being added to the thread. :rolleyes:

A while back I posted how customized phase scripts in your mission file can be used by SOM, called by BIS_SOM_requestSecOpFunc:
http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=2784950&viewfull=1#post2784950

But the "Request SecOp" function is for calling a support or SecOp immediately. I found that customized phase scripts can also be used for SecOps stored in the pool, or for SOM supports available to the player in the action menu under 0-8. Again, you can swap out one script, a few scripts, or all of them if needed.

The "Add Phase Code" Function:
To use customized phase scripts for the pool SecOps or added support requests, a block of code gets added to the SOM after the secop is added to the pool or the support request is made available, using the BIS_SOM_addPhaseCodeFunc. It can be added using a trigger or a script. The code runs prior to the "phase" designated by the third element in its array.

An example borrowed from Warfare which, prior to phase 6, calls a function to subtract player funds for using a support:

//add callback from SOM to warfare into 6th phase of support
[ 						// Beginning of the array
	_leader getVariable "mainScope", 	// The SOM synchronized to the calling player
	_supReqName, 				// Name of the support being called (i.e., "transportWF")
	6, 					// The phase the code will precede

	// The block of code to be run:
	{
		private ["_scope", "_mainScope","_name", "_price","_title"];
		_mainScope = (_this select 1);
		_scope = [(_this select 0), _mainScope] call BIS_SOM_returnSecOpScopeFunc;
		_name = _scope getVariable "name";
		_price = [_name, "price"] call BIS_SOM_returnCfgSecOpsEntryFunc;
		_title = _scope getVariable "title";

		// Warfare function that subtracts the funds
		[_mainScope getVariable "leader", _price, _name, _scope] call BIS_WF_OldSupportUsed;
	}
] call BIS_SOM_addPhaseCodeFunc;

The "Add Phase Code" function is great for running additional functions, getting and setting up variables, etc.; however it does have limited effect on the phase scripts that follow it. For example, it can be used to change a target position from one point to another by setting the Scope's "params", or it can spawn extra groups by calling BIS_fnc_spawnGroup; but it can't be used for changing the vehicles, aircraft or soldiers of the SecOp or support from one type to another when created. The customized phase scripts have to do that.

The "Add Phase Code" function can be used to change the script path. Instead of running the phase script from the default SOM path, the path can be changed to run a phase script from the mission file. This can be done for each individual phase, or if using various phase scripts, to change the Scope's "scriptPath", which would affect the remaining phases for the current SecOp or support call.
 

NOTE: If a phase fails to find a script in the path, the SecOp/support call will fail. Changing the Scope's "scriptPath" at the onset of a secop/support call means all of the phase scripts for that particular SecOp/support should be in your mission folder... unless you add another Phase Code to set it back to default midstream.

I would also suggest that the "Add Phase Code" function should be relied on whenever possible to run custom code, and customized phase scripts should be reserved for those things the "Add Phase Code" function can't do.

Running Customized Phase Scripts:

1) Create a subfolder in your mission file. This is for designating the file path.

For my example, I'll create two subfolders, one titled "scripts", then another inside titled "supports".
Now my mission folder reflects: "My_Laser_Strike_Mission\scripts\supports"

2) Create another subfolder inside the one you just created, for holding the customized phase script(s).

This subfolder must have the same name as the SecOp or support being called, i.e.:

for a normal mission: 		for a Warfare mission:
-------------------- 		---------------------
"ambush" 			"ambush" // The SecOps use the same names,
"patrol" 			"patrol"
"search" 			"search"
"trap" 				"trap"
"aerial_reconnaissance" 	"aerial_reconnaissanceWF" // but in Warfare the SOM supports have "WF" at the end
"artillery_barrage" 		"artillery_barrageWF"
"supply_drop" 			"supply_dropWF"
"tactical_airstrike" 		"tactical_airstrikeWF"
"transport" 			"transportWF"

For my example, I'll use the airstrike support for Warfare, "tactical_airstrikeWF".
Now my mission folder reflects: "My_Laser_Strike_Mission\scripts\supports\tactical_airstrikeWF"

3) Copy the phase scripts you will use from the SOM's SecOps folder to your mission's subfolder. Make the custom changes.

I want to change the aircraft, which can't be done using phase code alone. The aircraft is assigned in the "07_create_secop_assets.sqf", so that's the one I copy over. I change the available aircraft and bomb-type selections to an F-35 only (West) and SU-34 only (East), and save.
Called from the mission folder, the script's path is: "scripts\supports\tactical_airstrikeWF\07_create_secop_assets.sqf"

4) Add the Secop or support request. This is done at mission start, or during the mission using a trigger or script.

- For a SecOp, it can be added either to the SOM's pool in the editor init field, or during the mission using BIS_SOM_manageSecOpPoolFunc.
- For a support, it can be added any time using BIS_SOM_addSupportRequestFunc.
- Warfare without parameters adds the supports automatically if BIS_WF_OldSupportLevel = 1, but a player must have enough funds for it to show.
- Warfare with parameters must also have the "Support" param: "Mission Default" selected for them to be added automatically.

5) Add the Phase Code that will change the script path. This is done after the SecOp or support has been added. It can be done by trigger or script.

There are two approaches: a phase script individually, or the "scriptPath" for the entire scope.

One script path individually:

[
	_leader getVariable "mainScope", 	// Player SOM
	"tactical_airstrikeWF", 		// Name of the Scope, also the script folder name
	7, 					// Phase this code runs before
	{ 	// The code:
		_mainScope = (_this select 1);
		_scope = [(_this select 0), _mainScope] call BIS_SOM_returnSecOpScopeFunc;
		_name = _scope getVariable "name";

	// This code uses values from the underlying function calling it, so certain values don't need to be defined.
	// They are defined and carried in from the function calling the script: BIS_SOM_processSecOpPhaseFunc.
 
	// _path = "scripts\supports\tactical_airstrikeWF\"
		_path = "scripts\supports\" + _name + "\";

	// _script = "scripts\supports\tactical_airstrikeWF\07_create_secop_assets.sqf"
		_script = _path + _phaseIndex + "_" + _phase + ".sqf";
	}
] call BIS_SOM_addPhaseCodeFunc;

Script Path for an entire Scope:

[
	_leader getVariable "mainScope",
	"ambush",
	1, 		// Before Phase 1 - code runs at the onset of the SecOp
	{
		_mainScope = (_this select 1);
		_scope = [(_this select 0), _mainScope] call BIS_SOM_returnSecOpScopeFunc;
		_name = _scope getVariable "name";

		// The first phase script already has its path set to default. Change that first.
		_path = "scripts\support\" + _name + "\";
		_script = _path + _phaseIndex + "_" + _phase + ".sqf";

		// Then change the Scope's "scriptPath". It will affect all of the phase scripts that follow.
		// Be sure to have all of the phase scripts in the mission folder!!!
		_scope setVariable ["scriptPath","scripts\support\" + _name + "\",true];
	}
] call BIS_SOM_addPhaseCodeFunc;

In my own mission I've used customized phase scripts with the Air Recon support, to extend the UAV's flight time and add a UAV logic, synchronized with the SOM's UAV, the player, and the base UAV terminal, so the UAV's camera is accessable from the Terminal. I've also used it to specify exactly which aircraft get used in the Tactical Airstrike and Transport supports.

I continue to be amazed and feeling very appreciative to BIS and Joris-Jan van 't Land for how flexible the SOM actually is. - THANK YOU.

And I'm a huge Warfare fan, I have to extend the same for Warfare, Mike Melvin and those who worked on it as well I'm a latecomer and wish I'd been in on the Arma series since OFP. THANK YOU so much again!

And again, I hope this is found helpful to some in creating some great missions.

http://dev-heaven.net/issues/26368

Please support!

-- 17 Nov 2011

Yes, a very old post to respond to, sorry for that, but good findings for people to know.

I'm working on a SOM-Warfare mission and have gotten things to work together very well thus far.

---------

It would appear the SOM Transport and Supply Drop support requests don't work on dedi because they rely on the transportService.fsm in Functions. First defined variable in the FSM is "_clicker = player;".

The clicker is passed in as select 0, I don't know why it's not used; but I'm only starting to work with the FSM so maybe I'll discover why. Clicker is relied on pretty much in the FSM, so clicker being player would lead to failure on a dedi.

// edit: found the FSM was designed to be run by the calling client.

---------

The communication menus fail in multiplayer because SOM server queries and builds a leader's menu and then PV's the menu, and all players reflect the menu of whichever leader the server was querying at the moment. The result is fluctuating menus. From one moment to the next everyone's menu reflects a different leader's menu, and in an adversarial mission it might not even reflect menu pertaining to side.

I found a workable solution by removing the public variable from the comms menu update and having the SOM server send codebursts to clients instructing them to build their own menus.

// edit: resolved in beta

---------

The same "hover" bug affecting the transport support also affects the supply drop, which drops cargo before ever reaching the drop zone. Another issue related to the transport FSM, however the transport FSM itself is not actually at fault. The "unitReady" command is at fault. The FSM uses the unitReady command as condition to determine when the transport helo should land, and the supply drop aircraft should drop cargo.

I found the unitReady command only gives an accurate return if run by the client to whom the object belongs. Anyone else running unitReady on an object will always return "true", even if the unit is not ready. The FSM is run by the calling player, but the support vehicle is created by the server. The calling player is running a unitReady command on an object that does not belong to them, and it will ALWAYS return true, which causes the FSM to advance before the aircraft have reached their destinations. This is also why the supports work for host, but not for joined players.

I found a workable solution by modifying the phase scripts so that the server sends codeburst to calling client instructing them to create the vehicle, and return it as a public mainscope variable so that the server could continue to run scripts with it.

// edit: resolved in beta.

----------------

I hope these are found useful.

using secop manager cause to have a section in briefings called "secops" is there any way to hide it? thanks

There's no simple switch on or off for the 'SecOps' diary. You'd have to script it away.

The diary entries get initialized in the "hints" portion of the secopmanager.fsm. It's run using soft path "ca\", so you could copy the FSM to your mission file and then comment away the initial diary setup. To run, the FSM would have to be in a folder that follows it's path in SOM. Then you could use custom phase scripts and comment away the diary entries for each SecOp. Phase Script "02_Briefing.sqf" seems to be where they're usually run at.

The above will work in beta or in current stable version without Corepatch. But if running stable version with Corepatch addon, the FSM part won't work. The Corepatch sets a hard path "\ca" for the fixes to take effect, so only the Corepatch FSM will run. But the custom phase scripts can still be done.

There's no simple switch on or off for the 'SecOps' diary. You'd have to script it away.

The diary entries get initialized in the "hints" portion of the secopmanager.fsm. It's run using soft path "ca\", so you could copy the FSM to your mission file and then comment away the initial diary setup. To run, the FSM would have to be in a folder that follows it's path in SOM. Then you could use custom phase scripts and comment away the diary entries for each SecOp. Phase Script "02_Briefing.sqf" seems to be where they're usually run at.

The above will work in beta or in current stable version without Corepatch. But if running stable version with Corepatch addon, the FSM part won't work. The Corepatch sets a hard path "\ca" for the fixes to take effect, so only the Corepatch FSM will run. But the custom phase scripts can still be done.

thanks for reply, I'm using 1.62 version as it's more compatible with mods, so there is no any way to hide that diary?

It's part of the SOM initialization and there's no "hide the diary" option.