opusfmspol

I sent you a PM, if Warfare is included in your effort I have the over 50 errors and their fixes already identified. In my own mission I use Warfare's custom external script capability to clear them since I have no skill for modding.

Correct, the addAction is local in effect. When the addAction runs, it occurs on the machine of the player doing the action, and not on the machine of other players. The PVEH is used to run the same code for everyone else. (Note: Delete the addAction from the object, or other players might run it and you'll end up with duplicate tasks.) HOWEVER - deleteVehicle is a global command. When that line runs, the evidence object will be deleted on all machines. And VERY important to consider is this: "Deleting a vehicle, which is still being accessed by a running script, can result in a CTD." [crash to desktop] ...:butbut: https://community.bistudio.com/wiki/deleteVehicle So deleting the evidence object is the very LAST thing you do, and done separately from the tasks. In a scenario like yours, I would have the init.sqf run a single script which sets up all the public variable event handlers, and each event handler would execVM the various task scripts. The player actions and triggers would be set to run the task scripts and broadcast public variable. That way the broadcaster and receivers all run the one and same task scripts; and the code doesn't have to be duplicated in the event handler code. Then the evidence object can be deleted separately from the task script (but to be safe, only AFTER the broadcaster script has completed and addAction has been removed from the object - I would suggest a trigger with a few seconds delay). Putting together the task scripts would be part of the mission planning, where the tasks are laid out: tasks: ---------- Briefing task: "Collect Evidence" "Locate Evidence Folder at Ramon's Villa." task1: "Kill NSK" "The file shows NSK has taken over the Vatra airport and turned it into his military compound. Find and eliminate him." task2: "search NSK's Body" "Verify NSK's death by taking his dogtags, also search for any other items of interest." task3: ...etc. scripts: ---------- briefing.sqf task1.sqf task2.sqf task3.sqf ...etc. event handlers: ---------- "tsk_obj0" addPublicVariableEventHandler {if (tsk_obj0) then {task1 = player execVM "task1.sqf"};}; "tsk_obj1" addPublicVariableEventHandler {if (tsk_obj1) then {task2 = player execVM "task2.sqf"};}; "tsk_obj2" addPublicVariableEventHandler {if (tsk_obj2) then {task3 = player execVM "task3.sqf"};}; "tsk_obj3" addPublicVariableEventHandler {if (tsk_obj3) then {task4 = player execVM "task4.sqf"};}; ... etc. (Note: The "if (tsk_objx) then" is a filter to ensure the task script will only run if the variable being broadcast is true - it allows you flexibility to add alternative code using "else" for when the variable is broadcast false. A success scenario vs. failure scenario.) Briefing task is "tsk_obj0". When broadcast true, task1 script will run. example event code: task1 = player execVM "task1.sqf"; waitUntil {scriptDone task1}; tsk_obj0 = true; publicVariable "tsk_obj0"; The task script runs for the action player, then broadcasts the variable true so the task script will run for others.

Looks like a Windows user account issue. You may not have "read & execute" permission assigned. Did you check your permissions? Right-click the file, go to "properties" and "security", check the permissions. You'll have to be admin to change them.

Mmmm, I need to amend a previous statement I made above, now realizing it's an error; :16_6_8: The broadcast of the variable is what sets off the event handler, not the tskobj_3 being true. The value doesn't have to change at all. When the variable is broadcast the receiver event handler will run it's code, regardless whether the value changes. The purpose of declaring it true would be to filter what will happen when true as opposed to false. Yes; the tasks and addactions are also local in effect. Like hints, they too will only run on the machine of the player who triggers the code. They too have to be set up in public variable event handlers, in order to run the code on other player's machines. You could use the same handler as the hint if that would work for your mission. When you look up a command, keep in mind that when you see this box at the top: that means the command is local. https://community.bistudio.com/wiki/Category:Commands_with_local_effects Info in this thread might help a little if your mission is coop rather than adversarial; the task and addAction issues encountered were very much the same as yours: http://forums.bistudio.com/showthread.php?183977-CUSTOM-MISSION-SECOPS-ACE-TFAR-Chernarus Also, in your code is this is an accidental paste error?: Seems it should be: One other concern with the scripts: [objNull, ObjNull, tskEvidence1, "SUCCEEDED"]; setCurrentTask tskobj_test; should be player setCurrentTask tskobj_test;

The moniker; Opus is a penguin. He's from the South Pole. Hence - Opus: From South Pole. OpusFmSPol. In 1981 I was stationed in the Republic of Panama. I didn't know Spanish and struggled hard learning it. Some failures were annoying, some were humorous... others were not. Anyway, the Miami Herald printed "Bloom County", a political satire comic strip created by Berke Breathed, and I just fell in love with this little cartoon penguin that boy "Binkley" brought home to be his "pet puppy", when this penguin began learning how to speak: It illustrated perfectly the communication gap I was going through, and I have loved that penguin ever since. http://en.wikipedia.org/wiki/Opus_the_Penguin Around 1995, I came online, was looking for a moniker and chose Opus. But my e-mail provider already had an "Opus", and I didn't want numbers at the end so it had to be a phrase. At the time my e-mail provider only allowed ten digits for a username, so it had to be compressed. I thought about "OpusBdaMan", but then thought "no, he isn't a man, he's a penguin. He's from the South Pole." And from there came OpusFmSPol. The avatar; it's from the strip above and was done specifically for my A2/OA squad .xml (thinking of a supply truck rolling by with Opus on the side made me snort coffee out my nose), however it was left abandoned among my squad files since I'm a social media neanderthal and have no website for it. When registering for the BI forums it seemed like a good use for it.

Maybe this(?) PickupIDS = []; PickupIDS = PickupIDS + [player addAction["<img image='icons\money.paa' width='32' height='32'/> Pickup Money", "client\actions\pickup_money.sqf", [], 1, false, false, "", 'player distance (nearestobjects [player, ["Land_Money_F"], 5] select 0) < 5']]; https://community.bistudio.com/wiki/addAction In the 'title' it might be the XML syntax interpreting < >.

It could be if you're not aware of certain things, for instance: - Where the code has things like "call BIS_getPosInDistance" or "call BIS_targetIconUpdateText", it's likely referring to functions compiled elsewhere in the mission or script; - Where it has things like "_this call BIS_handler_SniperTargetHit2", it's likely referring to a handler compiled elsewhere in the mission or script; - Where it has things like "call BIS_fnc_dirTo", it is referring to Functions (meaning you need to have the functions module in your mission, and the code needs to wait until Functions initialize).... These type things are the "interdependencies" Kylania was mentioning when he posted the example code. Those interdependencies have to be included in your mission as well for the code to work. When you come across something not defined in the script itself, you may have to backtrack through the source from code to init, or track from init to code, to find where it was defined or compiled, determine what it is, what it does, and figure out a proper way of working that into your mission.

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: to read this: (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.

Sounds like something is preventing it from either loading or running on the Client machines. I would suggest checking the mission's path from init to code and make sure there is no "if (isServer)" or "if (isDedicated)" preventing the Clients from running it or running the script.

For a coop mission, replacing A1 with Player is okay - then any player can gather the rumor. The others will receive the rumor when their event handler goes off. But if you only want A1 to gather the rumor, the addaction has to be coded to only show for him. The Init.sqf is where the event handler goes. It will download onto each player's machine when they join the mission. Init.sqf: The task:"box" trigger will go off when it's detection occurs - use Player so it will occur for everyone: trigger onAct.: Now when a player approaches fizl, kecka or vnucka, the "Small_Talk" addAction menu appears. The player who runs the addaction will also run the rumor.sqf on their machine: rumor.sqf: When the player who makes "Small_Talk" broadcasts publicVariable "rumor", the event handler for the other players will fire off its code. As you can see, the event handler has the exact same code as rumor.sqf, but minus the public variable. On the sender's machine, the rumor.sqf assigns task and removes addactions, then broadcasts. On the receiver's machines, the eventhandler assigns task and removes addactions when the broadcast is received. The sender's event handler does not go off. ----------------------- Adding another observation: The Init.sqf is good for assigning the event handlers of simple coop missions; but when a mission uses many event handlers the Init.sqf can get pretty full. So the eventhandlers can all be put in a script executed by the Init.sqf, and they will still go on each player's machine when they join the mission - just be sure not to have "if (isServer)" blocking it from the player's machine: In Init.sqf: PV = [] execVM "PublicVariables.sqf"; In PublicVariables.sqf: "tskInitial" addPublicVariableEventHandler {Initial = [] execVM "task1.sqf";}; "tskConvoy" addPublicVariableEventHandler {Convoy = [] execVM "task2.sqf";}; "tskDisrupt" addPublicVariableEventHandler {Disrupt = [] execVM "task3.sqf";}; "tskGuard" addPublicVariableEventHandler {Guard = [] execVM "task4.sqf";}; "tskRespond" addPublicVariableEventHandler {Respond = [] execVM "task5.sqf";}; "tskSearch" addPublicVariableEventHandler {Search = [] execVM "task6.sqf";}; "tskIntel" addPublicVariableEventHandler {Intel = [] execVM "task7.sqf";}; "tskCompleted" addPublicVariableEventHandler {Completed = [] execVM "task8.sqf";}; true

Before answering (give a day or so, time zone difference), an important question: Is this a coop mission (players against AI), or an adversarial mission (players against other players)? I ask because in coop missions you can use "player", but in adversarial missions it is necessary to filter who will run the Event Handler scripts (East v. West v. Independent), and maybe which teams they are on.

Okay, so editor mode Not all is lost, I just posted this: http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=2790428&viewfull=1#post2790428 It's one way of having the supports show up. Also, buried in the 44 pages of the SecOps Module (SOM) thread are pieces of instruction on how to activate various SOM missions and supports, and how to make it a one-time deal or a persistent support. There's a "true" setting that can make it persistent. In a basic editor Warfare there is only artillery support unless you do the SOM support I posted. To activate the basic artillery support you must have the Warfare params in a description.ext folder, and there has to be AI manned artillery at base before it will show. And there is the Simple Support Module (SSM) that provides missions with supports as well. https://community.bistudio.com/wiki/Simple_Support_Module

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 tells Warfare that if it's regular artillery support is not found (no params in this instance), to use the SOM supports if a SOM is synched to the player. 7.) If SecOps are unwanted, put this in the SOM module's Init field: this setVariable ["settings", [[], true, nil, nil, false]]; (By default SecOps won't work in Warfare; but it can be done. If they are wanted, see the next post below. It takes a very small amount of scripting) 8.) Save. Launch the game, and wait a minute or two to let things get set up. By the time missions are assigned it will appear as though nothing special happened, but actually you have received your supports. You just don't have the funds to use them so they're not made available yet. If you wish, play the game a while and build up the funds. You'll see the supports appear as you start to gain several thousand in funds. They appear as icons on the right and under menu 0-8-7. - or-: 9: ) Go back to editor. Place a radio trigger. In the OnAct. field put this: WestPlayer1Funds = 20000; Launch the game again. In game, go to map and call the funds trigger. At the top, you'll see your funds increase. (If your funds don't change, you played the wrong unit.) After the funds increase and base is set up, you'll see the support icons appear as available on the right. And when you hit menu 0-8-7, you'll see the SOM supports listed: 1. Aerial Reconnaissance (UAV) 2. Tactical Airstrike (CAS) 3. Artillery Barrage 4. Transport 5. Supply Drop I've tested this in A2 and in OA. I had the supports. Still working with this to figure out other issues there might be. But it does work. - The support calls are cursor "context sensitive". They will grey out when looking at the sky. look at a target site when calling a support. - Sometimes Warfare's support update script runs slow. If they disappear, backspace and hit "7" again to see if they reappear. - You have the supports only if you have the funds. If they disappear, check your funds. Costs are: Transport: 3000 Supply Drop: 5000 Aerial Reconnaissance: 5000 Artillery Barrage: 6000 Tactical Airstrike: 6000Hope this helps someone along the way. --- Edit -- I originally posted that a trigger was needed to call the Supports. I found it wasn't necessary, the Supports become available anyway, they're just dependent on the funds being available before being shown. But in a scripted mission, where it's made so obtaining Supports is dependent on certain progress (like having an FOB, capturing an airport, or having a UAV terminal) the supports can be made available with the same type statements I had in the trigger: // ---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;The "true" setting makes it a persistent support; "false" makes it a one-time support. Persistent supports have a timeout where they are unavailable for a period of time after being used, then are made available again. END NOTE: When the Warfare Parameters are used (set up in description.ext), the normal settings are: 'Mission Default': Use SOM supports if a SOM is synched and BIS_WF_OldSupportLevel = 1 'None': No supports available. 'Free': Supports have no cost. 'Cheap': Supports cost half. 'Normal': Supports cost normal. 'Expensive': Supports cost triple. Free, Cheap, Normal and Expensive will apply the cost to the basic supports (those configured in Warfare). Artillery is the only basic support available (normal cost: $1000), unless the mission maker uses a custom Common Init to configure additional basic supports. SOM can be used if adding to basic supports. Adding a support into Warfare's support config will make it available, and the designated (custom) script that runs the support can call on a synched SOM to provide the support. If so, players must have a synched SOM to actually use the added support; those without SOM's will see the support listed as available but won't be able to use it. The support would be dependent upon a synched SOM. The scripted support could also be written to include alternatives (i.e., a "not available" message, or an alternative form of support like calling on SSM).

Are you seeking to remove AI that have strayed too far from the player group? The script is really confusing because you reference _dropunits as the array as well as the single element of the array selected as _x. As for the loop, the sleep 180 will work if you have a close }; for the while-do, and the script works. But I suspect it will error out. This is what I'm seeing: While {true} do { Sleep 180; { _dropunits = _x; if ((side _dropunits) == east) then { if (({(_dropunits distance _x) > 2000} count playableUnits) == ({isplayer _x} count playableUnits)) then { deletevehicle _dropunits; }; }; } forEach _dropunits; Sleep 10;

which game mode? campaign, scenarios, editor, MP connection to server? If campaign or scenarios, which missions? In editor, you have to set it up. Otherwise it depends on how the mission maker set it up.

Doubtful. I've seen some of your effort. Or we've all been there. You decide. [secret](Ssshhh... we all do that. But it's kept in "the vault.")[/secret]:padlock: ---------------------------------- For a small group like yours, you probably shouldn't use "if isServer" at all for tasks or addAction where everyone needs them. Using isServer, it's only available to the host. If AI could accidentally trigger something, you should replace it with "if (isPlayer)". Otherwise leave it open. But you still want to filter out other unwanted stuff. By filtering, I mean using the "if-then". If-then acts as a filter: if ((isPlayer && heIsSideIwant && heKilledTheBadGuy) || IwantThisAnyway) then {call thisIsWhatIwantHappening}; - it only happens when the filtered results are true. addPublicVariableEventHandler addPublicVariableEventHandler is how a lot of communication is done in MP. Building an MP mission, you'll really need to understand it. The function is pretty simple: - An event handler gets attached to a "certain Variable". - The variable has to be {global}, not {_local}, meaning no underline in front. - The event handler is given to those who would broadcast or receive the variable. For a small group like yours, probably everyone. (host and clients) - When a certain event is detected, the handler runs its code. - The event detected is the "certain Variable" being broadcast using the PublicVariable command; i.e.: broadcast = [1,2,3]; publicVariable "broadcast"; //Variable "broadcast" has now been transmitted. - the publicVariable can be broadcast by anyone. It will be received by everyone - EXCEPT the sender. - When the broadcast is received, the receiver's event handler fires off its code. - If the code is for assigning a task, the task is assigned; if it's for an addaction code to run, the code gets run. - It only occurs for those who have the event handler - but not the sender. - Note: The variable itself doesn't have to change value; it is the broadcast that triggers the code. So when laying out the code for the tasks and addAction, lay it out for the client whose machine will be running it, but include broadcasting the public variable so others in the group have the code run on their machine as well. It won't be running again for the client who broadcast it. command addPublicVariableEventHandler - the layout is: - <the variable> - <the command> - <the code or script to be run, when the variable gets broadcast> "my_Variable" addPublicVariableEventHandler { hint "my_Variable was broadcast"; player sidechat "The event handler has been triggered."; }; note: you can only test it in multiplayer, with a partner or a 2-PC LAN setup. example for a task: And in a trigger you put: A small group like yours, you probably want everyone having the event handlers. The init.sqf is received and run by everyone, so that could be a good place to put them.

Try this: if (!isDedicated) then { waitUntil {!isNull player && time > 0}; player addEventHandler ["HandleDamage",{if (side (_this select 0) == side (_this select 3)) then {false;};}]; }; tested it in SP editor with a radio trigger call. I think it had to do with the curly braces v. round braces v. no braces in certain places.

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

It's an Arma3 thread, and the function called is for Arma3. Won't work for A2 or OA. tasks and addAction are both Local in effect, though they can use global arguments. Since effect is local: a). Each client needs to have the script (not limited to server). b). Each client needs an event handler attached to a public variable so that when the variable is broadcast the script will run on their machine. https://community.bistudio.com/wiki/addPublicVariableEventHandler (can go in init.sqf or be run in mission by script or trigger) c). The trigger or addaction needs to broadcast the public variable. When it's broadcast the eventhandler will fire on the client machines and run the script code. d). The code being run needs a filter for the correct unit, team, faction or side, because every client will be running it. You could have a public variable, like "isTeamOnMission" and use that to determine that another mission can be assigned when false. You could have a script run code to select a random public variable from an array, and a trigger tied to each variable, to initiate that particular mission assignment when true. When the script broadcasts the selected variable as true, the trigger for that mission, detecting true, will initiate. When mission completed the variable gets reassigned false and the trigger runs deact code so it can be fired again. I updated the SOM discussion. http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=2788974&viewfull=1#post2788974

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. 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": 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: To read this: 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: 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: you change it to read: 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. 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

maybe try "this && isServer" in the trigger init? http://www.armaholic.com/forums.php?m=posts&q=22704 see Post #4

Try changing: "YourMarker" setMarkerText "NSK's Base"; to this: "NSK" setMarkerText "NSK's Base"; It may be detecting undefined variable on "YourMarker" and stopping the script. --- edit -- It also could be that setCurrentTask tskobj_3 is running before the trigger has opportunity to detect task 2 completed and create task 3. Move this: player setCurrentTask tskobj_3; tskobj_3 = true; publicVariable "tskobj_3"; to the end of the "taskcompleted tskobj_2" trigger's onAct code.

try these out:

Could be related to _this conflicting because it is one of the reserved variables, maybe? _this references what was passed into the script during the call/spawn/execvm. https://community.bistudio.com/wiki/this Might try replacing it with some other reference and see if that works. --- edit -- I copied it over into editor on chernarus, and things only spawned things once - is it possible your trigger is running it twice? I had no other mission stuff, just the script and trigger, so perhaps could still be _this being referenced.

The single zone could have to do with the range setting. You had 1500 originally; I used 3000 on Utes in order to have Strelka and Kamenyy detected. If you place hint str count _array under the first line, it'll tell you on screen how many town/villages were detected. --- edit-- Another possibility is this?: _onAct = format ["null = [""zone%1"",[%1,0,0],[3,1,50,50],[],[],[],[0,6,0,1]] spawn DAC_Zone;",_count];