opusfmspol

I would suggest try testing the conversation and marker blocks separate from all else. That's what I did when it worked. I had the named objects grouped to markers on map, "init.sqf" variables set up, and called the code from script "script.sqf" using a radio trigger. With the publicVariable it's a matter of identifying the string "IED_Array", "cache_Array" or "ZU_Array" for broadcast. I see format dumps in the array value instead of the variable name. The variable name is what needs to be broadcast.

_reply returns the value that was selected by BIS_fnc_selectRandom. If it randomly selects 0, it returns the string "one"; if it randomly selects 1 it returns the string "I have marked something on your map." == is a true/false Boolean test. It compares the value of _reply against the string "I have marked something on your map."; if they are exactly the same it returns true and the code runs; if not it returns false and the code does not run. As I said, it was a thought I hadn't tested. Check the .rpt log and it should show where it went fubar. Also running startup param -showScriptErrors will help by showing in game when the error occurs while it gets logged. --- Edit -- A quick test shows this part is working _reply = ["one","I have marked something on your map."] call BIS_fnc_selectRandom; [_reply, 0, 0.2, 10, 0, 0, 20] spawn bis_fnc_dynamictext; if (_reply == "I have marked something on your map.") then { _type = type_Array select 1; //Returns the Cache array _name = name_Array select 1; //Returns the name "Ammo Cache" for use in formatting marker name _object = _type call BIS_fnc_selectRandom; //Returns a random object from the selected _type array _objIndex = _type find _object; //Returns the object's index number in _type array _object = _type select _objIndex; //Selecting the chosen object (safeguard) _objPos = getPos _object; //Returns position of the chosen object _replyMarker = format ["%1marker",_object]; //Marker name will include the object's name to be unique _marker = CreateMarker [_replyMarker,_objPos]; //Creates the marker at the object's position _marker SetMarkerColor "ColorRed"; //Marker is Red _marker SetMarkerType "Destroy"; //"Destroy" marker ( + ) _marker SetMarkerAlpha 1; //Marker is fully visible _marker SetMarkerText Format ["%1 reported",_name]; //Marker text shows "Ammo Cache reported" //--- necessary to keep markers from having the same names _type = _type - [_object]; //Removing the object from it's array so it's not reported again PublicVariable format ["%1",_type]; //Updating the array for the other players. }; To test I called it with a trigger. --- Edit -- It may be the publicVariable returning content instead of variable name, stopping your block of code from completing. Remove this: PublicVariable format ["%1",_type]; //Updating the array for the other players. and see if it works

Would go here (example for a Cache reveal): _reply = ["one","I have marked something on your map."] call BIS_fnc_selectRandom; [_reply, 0, 0.2, 10, 0, 0, 20] spawn bis_fnc_dynamictext; [_civ, VOICES call BIS_fnc_selectRandom] call CBA_fnc_globalSay3d;//Good response if (_reply == "I have marked something on your map.") then { [color="#FF0000"] _type = type_Array select 1; //Returns the Cache array _name = name_Array select 1; //Returns the name "Ammo Cache" for use in formatting marker name[/color] _object = _type call BIS_fnc_selectRandom; //Returns a random object from the selected _type array _objIndex = _type find _object; //Returns the object's index number in _type array _object = _type select _objIndex; //Selecting the chosen object (safeguard) _objPos = getPos _object; //Returns position of the chosen object _replyMarker = format ["%1marker",_object]; //Marker name will include the object's name to be unique _marker = CreateMarker [_replyMarker,_objPos]; //Creates the marker at the object's position _marker SetMarkerColor "ColorRed"; //Marker is Red _marker SetMarkerType "Destroy"; //"Destroy" marker ( + ) _marker SetMarkerAlpha 1; //Marker is fully visible _marker SetMarkerText Format ["%1 reported",_name]; //Marker text shows "Ammo Cache reported" //--- necessary to keep markers from having the same names _type = _type - [_object]; //Removing the object from it's array so it's not reported again PublicVariable format ["%1",_type]; //Updating the array for the other players. };

BIS_fnc_selectRandom returns the selection's actual content, not its index, so it would be: if (_reply == "Here have a marker") then { [color="#808080"][i]....run the marker code....[/i][/color] }; Yeah. Darn it, no matter how many times I review, preview and post-review.... *headslap* (#:> --ow Good catch.

Here is a thought to start working with (not tested). Give names to each of the search objects grouped to the markers. in Init.sqf: [i]//--- Each player's machine will have the stored variables. //--- Arrays containing the object names segregated by their type. Must exactly match the object names.[/i] IED_Array = [iED1,IED2,IED3,IED4,IED5,IED6,IED7,IED8,IED9,IED10,IED11,IED12,IED13,IED14,IED15]; cache_Array = [cache1,cache2,cache3,cache4,cache5]; ZU_Array = [ZU1]; [i]//--- Store the type arrays.[/i] type_Array = [iEDArray,cacheArray,ZUArray]; [i]//--- Store the names for the array types.[/i] name_Array = ["IED","Ammo Cache","AA Gun"]; In QuestionCiv.sqf: Implement this depending upon the conversation - if they do know of IED, cache or AA: [i]//--- For an IED:[/i] _type = type_Array select 0; //Returns the IED array _name = name_Array select 0; //Returns the name "IED" for use in formatting marker name [i]//--- For a Cache:[/i] _type = type_Array select 1; //Returns the Cache array _name = name_Array select 1; //Returns the name "Ammo Cache" for use in formatting marker name [i]//--- For an AA Gun:[/i] _type = type_Array select 2; //Returns the AA Gun array _name = name_Array select 2; //Returns the name "AA Gun" for use in formatting marker name Generating the marker following the conversation after type and name are selected: _object = _type call BIS_fnc_selectRandom; //Returns a random object from the selected _type array _objIndex = _type find _object; //Returns the object's index number in _type array _object = _type select _objIndex; //[b][i]Selecting[/i][/b] the chosen object (safeguard to ensure select random doesn't occur // again by referencing variable _object) _objPos = getPos _object; //Returns position of the chosen object _replyMarker = format ["%1marker",_object]; //Marker name will include the object's name to be unique _marker = CreateMarker [_replyMarker,_objPos]; //Creates the marker at the object's position _marker SetMarkerColor "ColorRed"; //Marker is Red _marker SetMarkerType "Destroy"; //"Destroy" marker ( + ) _marker SetMarkerAlpha 1; //Marker is fully visible _marker SetMarkerText Format ["%1 reported",_name]; //Marker text shows "IED reported", "Ammo Cache reported" or "AA Gun reported" //--- necessary to keep markers from having the same names _type = _type - [_object]; //Removing the object from it's array so it's not reported again PublicVariable format ["%1",_type]; //Updating the array for the other players. As your script is, it looks like this will occur every time any player comes close and targets the person. You'll need to find a way to stop it from repeating once that particular person has divulged his information, or he'll just keep giving up new objects each time someone comes close and targets him.

is it single-player, MP coop mission against AI, or MP adversarial mission against players? In single player and coop, createMarker can be used, but in adversarial createMarkerLocal has to be used along with MP communication to have the markers appear only for the target players' machines, otherwise the enemy will see the markers too.

To clarify; are you trying to return the location of one of the randomly placed IED's, to reflect it's location on the map?

Command onMapSingleClick detects true/false whether the shift key is pressed, so try this: onMapSingleClick {if (_shift) then {... whatever you want to happen... };}; https://community.bistudio.com/wiki/onMapSingleClick

"setWaypoint ...." for waypoint settings is not the same sort of command as "Set" which is used for arrays. "Set" and "SetWaypoint..." are separate commands with different functions. "Set" is a command that affects an ARRAY. Notice in the wiki's "Syntax" portion that ARRAY is listed before the command: https://community.bistudio.com/wiki/set "setWaypoint ..." are commands that affect a WAYPOINT. Notice in the wiki's "Syntax" portion that WAYPOINT is listed before the commands: https://community.bistudio.com/wiki/setWaypointType https://community.bistudio.com/wiki/setWaypointFormation https://community.bistudio.com/wiki/setWaypointBehaviour Your commands don't work because you're running waypoint commands on arrays. You need to run them on the waypoints instead. _waypoint = _group1 addWaypoint [getmarkerpos "wp0",0]; _waypoint setWaypointType "MOVE"; _waypoint setWaypointFormation "STAG COLUMN"; _waypoint setWaypointBehaviour "SAFE"; _waypoint2 = _group1 addWaypoint [getmarkerpos "wp1",50]; _waypoint2 setWaypointType "SAD"; _waypoint2 setWaypointFormation "STAG COLUMN"; _waypoint2 setWaypointBehaviour "SAFE"; While the waypoint itself returns an array, the array method won't work unless it's exactly what the return should be from the referenced waypoint. Thus the waypoint variable itself is what should be used. It helps ensure the array that 'setWaypoint...' uses has the correct content.

Well, I'll try to keep this simple so as not to upset your neighbors. ;) 1). In your mission folder add the Silvie folder path, so the folder path is "<your_mission_name>\ca\modules\Silvie\data\scripts". 2). Copy the Silvie "main.sqf" from the .pbo and place a copy in the "scripts" folder. 3). In your copy of the main.sqf find the line that reads this: } foreach _twnlistTemp; }; //---Vehicle count Insert the following lines so it reads this: [color="#A9A9A9"] } foreach _twnlistTemp; };[/color] _count = count _twnList; for [{_i = 0}, {_i < _count}, {_i = _i + 1}] do { private ["_town","_name"]; _town = _twnlist select _i; _name = _town getVariable "Name"; diag_log format ["%1 :: %2 :: %3",_i,_town,_name]; }; [color="#A9A9A9"]//---Vehicle count[/color] 4). Start your mission. As soon as you enter world and game begins, exit the mission. When your mission initialized, the code you added had Silvie dump the _twnlist values and their names into your .rpt file. Look at your .rpt file and you'll see a list like this: 5). Select Balota: - At the left is the array select number, starting at 0 (because array selection is zero-based). - In the center is the _twnList variable for the location as listed in the _twnList array. - On the right is the name of the location. In this instance, Balota is second in the list and would be "select 1". Your select number might be different, especially if "City Center" location logics are added into your mission. 6). Go back into the main.sqf. Change the code you inserted to read this instead: [color="#A9A9A9"] } foreach _twnlistTemp; };[/color] _Balota = _twnList select 1; [color="#A52A2A"]// Note: Use your select count![/color] _twnList = _twnList - [_Balota]; [color="#A9A9A9"]//---Vehicle count[/color] 7). Save. Balota has been removed from the _twnList where vehicles will spawn. When I went into my mission I found no vehicles at all in Balota. When I went to Cherno and Kamarovo there were vehicles present there. Hope this helps.

If you are willing to remove vehicles from Balota Town as well as the airfield, another thing to consider is removing Balota from the Townlist, and that would remove the vehicles from the airfield as well. They only appear at the airfield because it falls within distance of Balota town. --- Edit -- Also, Silvie is one of the modules with external scripting capability. If you copy the folder path ca\Modules\Silvie\data\scripts to your mission file and copy the Silvie "main.sqf" or "SpawnVehicle.sqf" to the scripts file, you can work with the script settings. It might be possible to add some kind of area blacklist there. Would have to make sure it plays well with Silvie's FSM though.

I would think event handler HandleDamage would identify the source unit as "select 3". https://community.bistudio.com/wiki/ArmA_2:_Event_Handlers#HandleDamage

I don't see any medic modules at all listed in the TrueNam mission objects, not ACE or vanilla. That would be contributing to the problem you're experiencing. Strike that, I downloaded an older version, not the most recent. Finding the recent version I now see it does have ACE wounds in effect (Feeling like an idiot *headslap* (#:> -- ow ) I do see "ca_modules_pmc_simplefirstaid" listed in the addons. That could be a leftover from a deleted object since the module itself isn't among the mission objects. When a mission maker places an object and saves, the related addon gets added into the addons list, but it's hit or miss whether it gets removed from the list when the object is removed. But it also may not be a leftover; I don't know how the medical features of Unsung work. It could be a required addon for some of its objects. So I wouldn't necessarily say the line should be removed, but I would keep in mind the simple first aid module can be buggy. I suffered medics spinning circles and stuck in neverending animation loops when I tried using it in one mission. TrueNam is a User Mission, so I would think with author's permission (respect to the creator) you can edit it in editor. I would suggest asking Gfresco whether players swapping medic modules in his mission is permissible. If he says yes, you have your choice. players prefer some medic options over others for their gameplay.

One way is to place the code in a script and compile the script as a function. InitUnit.sqf: _this allowfleeing courage; //public variable courage must be defined somewhere or there will be an error _this enablefatigue false; _this addEventHandler ["HandleDamage", { _object = _this select 0; _damage = _this select 2; if((damage _object) + _damage > 0.9) then {0.9} else {_damage}; } ]; compiled in init.sqf: InitUnit = Compile PreprocessFile ("InitUnit.sqf"); Now it is a function called "InitUnit". When units get created in mission, you have each unit or vehicle crewmember call the function as part of its init. Example When a unit is created: _soldier = _team CreateUnit [_unit,_position,[],0.6,"FORM"]; [_soldier] Call InitUnit; Example when a vehicle is created: _vehicle = _team CreateUnit [_unit,_position,[],0.6,"FORM"]; _crewmen = crew _vehicle; {[_x] Call InitUnit} forEach _crewmen; Compiling it in init.sqf you still have to put the code in the editor object initialization fields, since the mission's init.sqf runs after the editor objects initialize. The function would be used for objects created during the mission.

I just tested, went into my mission on Chernarus and deactivated all mods. I had all three vanilla medic modules synched to player and AI leaders, and medic responded fine healing a wounded comrade. No errors thrown, no problem healing. But I then activated CBA and ACE only, and added an ACE: Enable Wounding System module. When medic was ordered to heal his wounded comrade he ran over and just stood there. he wouldn't heal the wounded man. Oddly I was wounded shortly thereafter and the AI who assumed leader ordered medic to heal me. The medic did begin to heal me (but got shot himself). These are the individual errors that went into the .rpt. Most were event focused but a couple were looping. Only two were ACE_wounding specific: Can't really say the ace_wounding errors were the culprit though. I saw the fn_findExtreme error thrown when the medic stalled, and it's an OA function. Maybe it has to do with what ACE or CBA pass to the function? In my full mission I use ACE "make everyone a medic" as a workaround to generally overcome the issue. --- Edit -- Using the Functions' external scripting ability, I moved the fn_findExtreme function to my mission file and added debug messages. The error is thrown when an empty array is sent to the function. It tries to find min or max from nonexistent elements in the empty array.

Chiming in with what Joe98 said, I'm pretty certain it is an ACE issue. I don't use Unsung yet (but will at some point, I think it's a great mod and love VN scenarios, but tied up with trying to build a different mission) but I do use ACE. For debugging vanilla issues I disable the ACE material periodically. With vanilla medic modules active I have no problem sending medic to an injured soldier and the medic does respond and heal; but with ACE active I run into the same issue OP has. Medic will respond but doesn't heal. I afterward find (v1.63) a number of medical related log errors which, sorry to say, I haven't really paid too much attention to since I can't do anything to fix them. As far as drag and carry, I would think that it would be the Battlefield Clearance module missing from the mission, wouldn't it? Or does ACE activate that by default? I never paid much attention to the ACE side of it.

When I obtained v1.63, the editor Warfare mission I worked on for many months in OA failed to respawn. Death camera, zoom up, respawn failure. Forced respawn caused the same thing to happened again, but at base. Always. But.... I was already using a custom Init Client script for the Warfare module, and after tracking down the problem I was able to use it to get respawn working again. The problem was an incorrect variable in one of the Warfare scripts that v1.62 and prior passed over, but affected v1.63. On Steam and here on the Forums I found threads appearing from others suffering the same respawn issue. I began responding to a few, but I think it's better to post here how people can fix their editor missions that use Warfare. This is being written from the very basics for the sake of those who are inexperienced at scripting, so please bear with me. And all, please comment where I get something wrong: How to Use a Custom Init Client in Warfare Missions: A custom Init Client is used to modify the Client setup in Warfare. It can bypass core scripts and use scripts from your mission file instead. It can also customize client aspects of your mission's init. The problem is an incorrect variable: _side in the Client_Killed script, which runs the death camera and the respawn map selection. The error is encountered before respawn occurs and stops the script with the camera overhead. The map doesn't appear, and the camera never terminates. Respawn occurs (under an event handler), but the player remains locked in the overhead camera view. Once the variable is correctly defined ("SideJoined", not "_side"), the camera will terminate and the player returns to their body - die, respawn, game on. The process: ----------------------------------------------------------- 1.) Read and understand the Arma Public License (APL) and the Arma Public License Share Alike (APL-SA) licenses posted by BI: http://www.bistudio.com/community/licenses/arma-public-license http://www.bistudio.com/community/licenses/arma-public-license-share-alike 2.) Obtain a copy of the Warfare2 module from the Arma Licensed Data Pack page: https://community.bistudio.com/wiki/Arma_Licensed_Data_Pack Select the "ALDP_A2_PBOs_APL-SA_part3.zip" file, it contains the Warfare2 module. DO NOT attempt to use the Warfare2 module from your game files, you risk accidentally messing up your game. Take the Data Pack copy of the Warfare2.pbo from the zip file and place it into a new folder of its own for you to work with. You don't want to mess up the module your game uses. 3.) Obtain the Warfare scripts from the pbo. For this you have to use a PBO extractor. Extract the file Warfare2.pbo. There are a few extractors listed on the Arma: Community Tools page: https://community.bistudio.com/wiki/ArmA:_Community_Tools Comment: Keep in mind, some extractors don't let you choose a file path and will only extract to the file the pbo is in; another reason I say put the module in a file of its own. 4.) Go into the extracted files and find "Client_Init.sqf". It's in the Scripts\Client\Init folder. Copy it into your mission file. You now have a custom Init Client you can modify. (--- Edit -- Adding some notes for fixing missions that come with the game: many of them will already have custom files. If the mission already uses a custom Client Init, modify that one instead of pulling a new copy. It will have changes you won't want to lose by pulling a new copy.) 5.) Go into the extracted files and find "Client_Killed.sqf". It's in the Scripts\Client\Functions folder. Copy it into your mission file. You now have a custom copy of the problem script which you can fix. 6.) Go into your mission in the mission editor. In the Warfare module Init field, type this: (--- Edit -- Note: skip this step if you're editing a mission that already has a Mission Init listed - let the module run the one it has.) http://forums.bistudio.com/showthread.php?180972-How-to-Fix-Respawn-Failure-in-Warfare2-Editor-Missions&p=2783030&viewfull=1#post2783030 BIS_WF_Common SetVariable ["customInitMissionScript","Init_Mission.sqf"]; Save. You have now told Warfare to run a custom mission init from your mission folder. 7.) Go into your mission folder and create a new text file called "Init_Mission.sqf". Watch the end extension; make sure it is sqf and not txt or some other. In this file type these two lines: (--- Edit -- Note: if editing a mission that already has a Mission Init, use the lines already in that file; but if absent then add these) BIS_WF_Common SetVariable ["customInitClientScript","Init_Client.sqf"]; BIS_WF_Common SetVariable ["customInitServerScript",""]; Save. You have now told Warfare to run the custom Init Client from your mission folder instead of core. Note: The custom Init Server needs no script; the line is only necessary to avoid a functions error and freeze on loading screen. 8.) Go into your mission folder's custom Init Client and find the line for "BIS_WF_ClientKilled." Modify this portion: (corePath + "Client\Functions\Client_Killed.sqf"); to read this: ("Client_Killed.sqf"); Save. You have now told Warfare to run the custom Client_Killed script from your mission folder instead of core. Now to fix the respawn... 9.) Go into the Client_Killed script in your mission folder. Find the line that says: _data = [_side,"Barracks"] Call BIS_WF_GetBaseStructureData; Change it to read: _data = [sideJoined,"Barracks"] Call BIS_WF_GetBaseStructureData; Save. The problem has been fixed. The variable is correctly defined. Save mission and launch the game. Warfare respawn should work. Hope this helps. P.S. - sorry I can't post a sample mission here, I'm a social media neanderthal and have no website for it. (:> Opus

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.