opusfmspol

Try this and see if it works: _array = nearestLocations [player,["NameCity","NameVillage"],3000]; _count = 0; { //Get the position _loc = _array select _count; _pos = position _loc; //Set the trigger. _t = createTrigger ["EmptyDetector",_pos]; //Format the zone variable. missionNameSpace setVariable [format ["zone%1",_count],_t]; z = missionNameSpace getVariable format ["zone%1",_count]; //Format the trigger statement. _onAct = format ["null = [z,[%1,0,0],[3,1,50,50],[],[],[],[0,6,0,1]] spawn DAC_Zone;",_count]; //setTriggerArea and activation z setTriggerStatements ["time >1",_onAct,""]; // Index up for the next zone _count = _count +1; } forEach _array; An issue I ran into was the z variables causing this error to be thrown in .rpt: Error in expression <null = [17523: <no shape>,[0,0,0],[3,1,50,50],[],[],[],> Error position: <<no shape>,[0,0,0],[3,1,50,50],[],[],[],> Error Invalid number in expression Error in expression <null = [17524: <no shape>,[1,0,0],[3,1,50,50],[],[],[],> Error position: <<no shape>,[1,0,0],[3,1,50,50],[],[],[],> Error Invalid number in expression debugger didn't like the <no shape> in the zone ID. Don't know if DAC will reject it since 'z' identifies the zone by variable name.

--- edit -- mmm, I made a post but had to rethink it because using the Format command will be difficult used in conjunction with setTriggerStatements. I would think yes, but not certain. Putting it in a loop of it's own could work as well. I know it can be done, just need to think it through. May have to put a loop inside a loop to keep Format from having a fit. It needs special attention when encountering strings inside the format.

Unless I'm missing something, z isn't referring to each, it's referring to the last one created. It's outside the cycle and doesn't have a cycle of its own.

Thanks! Never seen them before and learning new things I hadn't realized. Kudos to Baz for putting them together, and your time and effort to repost them is greatly appreciated.

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.

Thanx, much appreciated; I took a look at the "Crimson Lance" mission to get a sense of what was going on, and the DLC content gets pulled from a custom Init Common running configs which contain the units. The files are contained in the mission folder. I realized my instructions told people to create a new Init Mission whereas the missions in game will already be using one if they run custom configs. The problem lies in which Init Common is being run (you're clearly running the one from Warfare core). When you created a new Init Mission to tell Warfare to run a custom Init Client, the mission already had a custom Init Mission of its own. In this case, instead of creating a new file "Init_Mission.sqf", you should let the Warfare logic run the "InitMission.sqf" it already points to, and use that file to add the Init Client file. Example from "Crimson Lance" mission - it runs a custom InitCommon to apply the BAF configs. Before applying the fix: BIS_WF_Common SetVariable ["sidePlacement",[true,-1,-1]]; BIS_WF_Common SetVariable ["customInitClientScript",""]; BIS_WF_Common SetVariable ["customInitCommonScript","InitCommon.sqf"]; BIS_WF_Common SetVariable ["customInitServerScript",""]; BIS_WF_Common SetVariable ["customInitBasesScript",""]; BIS_WF_Common SetVariable ["customBaseLayoutsScript",""]; BIS_WF_Common SetVariable ["customTownsScript",""]; Applying the respawn fix: BIS_WF_Common SetVariable ["sidePlacement",[true,-1,-1]]; BIS_WF_Common SetVariable ["customInitClientScript","Init_Client.sqf"]; BIS_WF_Common SetVariable ["customInitCommonScript","InitCommon.sqf"]; BIS_WF_Common SetVariable ["customInitServerScript",""]; BIS_WF_Common SetVariable ["customInitBasesScript",""]; BIS_WF_Common SetVariable ["customBaseLayoutsScript",""]; BIS_WF_Common SetVariable ["customTownsScript",""]; Sorry, at the time I did the original writeup I didn't have the fix for missions, only the editor fix. I didn't tell people to use a custom Init Mission already in place if one was there.

I think you mean "forEach", there is no "eachOf" command (that I'm aware of anyway). https://community.bistudio.com/wiki/Category:Scripting_Commands_Arma_3 Set the trigger to "Side Present" for x1, x2 and x3, whichever side they are; trigger condition: x1 in thisList || x2 in thisList || x3 in thisList; trigger activation: {_x setPos (getPos xflag2)} forEach [x1,x2,x3];

I persistently have that as well, and haven't had it affect gameplay (yet) so I think it's likely a common nuisance error. I suspect whatever the problem is would be somehow related to whatever generates the exe timestamp, but I just don't know what it would be. Sorry I couldn't be more helpful. ---- Edit -- Just looked at my own .rpt and it generates "Exe timestamp: 2014/07/16". That was around the time I purchased 1.63 on Steam. I opt out on betas but have the game automatically update.

What I notice is the exe timestamp is consistently 09/19 (Friday) when you say the trouble started. Perhaps a bad update occurred on an exe? I don't know where that exe timestamp originates from. Is it the game engine exe, or some other thing....? Maybe try moving the game engine exe to another folder and verifying cache/ redownloading. If it works you know it was bad game engine. If it doesn't work, put the old one back. It's just an observation, like I said I don't know where the exe timestamp is being pulled from.

The trigger should be synchronized with the very first waypoint of the HUMVEE; and that waypoint should be placed at or near the HUMVEE itself. At game start the Humvee will have a waypoint right at it's nose and nudges to it, however the waypoint won't complete until the Trigger fires, so the HUMVEE sits there until that happens.

It would appear to be a function script in CarlosTex's mission, instructing his spawned aircraft to go do something (hunt for things, I presume). It wouldn't seem pertinent to the respawn itself. (Though it could indicate waypoints for the vehicle are helpful?)

Attempt 1): Don't use an object's Init field, the code only runs at mission start. When you approach it won't run again. Stick with the trigger. Attempt 2): It looks like the code you have returns nothing. You need a condition code that returns "true." Try using: LostSoldier1 distance Myself < 5;

I ran your mission and found the "05: Superpowers" is being pulled from the description.ext file, where it has: onLoadMission = $STR_Description.ext0_14; I don't know where the stringtable is found that it pulls from, but when I replaced $STR_Description.ext0_14 with a simple string "Superpowers Test", it replaced the "05: Superpowers". Sorry I can't help with a dedi server test, I only have a local hosting setup myself. Hopefully changing the OnLoadMission will help with it. ----Edit-- oops... too slow, I see you found your problem source. The foldername issue is good to know too.

In your editor City location's Init field, give the city a name: this setVariable ["name","NW Airport"]; In Warfare module Init field, tell it to run a custom Init_Mission: BIS_WF_Common SetVariable ["customInitMissionScript","Init_Mission.sqf"]; In your mission folder create a script file, Init_Mission.sqf. In there you tell Warfare to run a custom Towns script: BIS_WF_Common SetVariable ["customTownsScript","Config_MapTowns.sqf"]; The custom Town script is a copy of the Warfare Config_Maptowns script, which you place in your mission folder. When Warfare reads from the Init_Mission that there is a "customTownsScript", it will run that script from your mission file instead of the core Towns script. The core Towns script already sets higher SV values for Cherno, Elektro and Berezino, than the defaults used for all other towns. All you have to do is add your own city to it and set the min/max SV you want it to have. _n = _n + ["NW Airport"]; // Name matches the editor name. _scripts = ["DefaultTown"]; // Use DefaultTown if you don't use a custom town path to custom configure town defense units. _range = 450; // Range at which defense units will spawn when an enemy approaches. _side = ObjNull; // Side which owns the town at game start (East, West, Resistance). Default is objNull. _minSV = 65; // Starting SV. -1 uses value from script, and 0 calculates SV based on town size. _maxSV = 180; // Maximum SV. -1 uses value from script, and 0 calculates SV based on town size. _l = _l + [[_scripts,_range,_side,_minSV,_maxSV]]; ----edit--- to change the amount a supply truck delivers, create a custom Init_Common as Darren Brant describes and put this in it: //Max amount a location can increase in value from supply trucks. BIS_WF_Constants SetVariable["SUPPLYINCREASE",15]; // You set the amount

http://sandbox.darrenbrant.com/arma_ii/the-arma-ii-warfare-mission-setting-starting-money-and-supplies Darren Brant's sandbox has quite a bit of good info on customizing Warfare in editor. http://sandbox.darrenbrant.com/category/arma_ii

The relevant portion is borrowed from Warfare's GetPositionFrom script: while {true} do { _position = getPos object1; _distance = 3; _dir = getDir object1; _direction = _dir + 180; "MARKERNAME" setMarkerPos [(_position Select 0)+((sin _direction)*_distance),(_position Select 1)+((cos _direction)*_distance)]; "MARKERNAME" setMarkerDir _dir; sleep 2; }; I noticed you were using 3d position, but markers use 2d position format.

No, that won't work because "&&" is a boolean (true/false) test and counting switchable units returns a number. "&&" is for running code only if the test before and after returns true on both; example: if (true && true) then {true:code is run} if (true && false) then {false: code not run} if (false && true) then {false: code not run} It only tests for true/false. It does not compile arrays or add numbers. You should drop the "&&" if you're not doing a boolean true/false test. Use plus "+" instead. Whether you want to obtain a number (count) or compile an array (player and switchable units in a group), you should declare them separately, and then add them together. example: _playerUnits = <this>; // <this> returns 1 _switchableUnits = <that>; // <that> returns 3 _allUnitsPlayer = _playerUnits + _switchableUnits; // 4 = 1 + 3 But I believe your seeking an array. As to arrays, they should always be declared beforehand. They can be added to using "+" as well, but you want to avoid nesting or multi-dimensioning them if it's not what is desired: https://community.bistudio.com/wiki/Array _allUnitsPlayer = []; // declared: _allUnitsPlayer is an array _allUnitsPlayer = _allUnitsPlayer + _playerUnits; //_playerUnits is added into the array _allUnitsPlayer = _allUnitsPlayer + _switchableUnits; //_switchableUnits is added into the array behind _playerUnits However.... A switchable unit might be a player. You'll need a check in place to ensure that a player unit already in the array doesn't get added again as a switchable unit. "PlayableUnits" will return an array of every playable unit on the map, it won't be limited to the player's group. I don't know whether "switchableUnits" returns different results for a server versus client; the wiki doesn't indicate locality effect. But I suspect it would return only switchable units in the server's player group, since a dedicated server will return an empty array. https://community.bistudio.com/wiki/switchableUnits I know that switchable units is a subset of playable units. Switchable units are the playable units in a SP player's group. If it's playable, it may not be switchable depending on the group, but if it's switchable, it will be playable. I would say you should therefore check whether a unit in a group is contained in the "playableunits" array. If found, it will be a switchable unit, so then check if it's already in the _allUnitsPlayer array (already containing the player units). If not there, then add it to the _allUnitsPlayer array. That should add the SP switchable (AI playable in MP) units to the array of players. My god, brain thingy hurts trying to think about doing that.... good luck. "forEach" runs code on every item in an array. Whatever follows the "forEach" command has to be an array. I think you need to run either "forEach _allUnitsPlayer" or "forEach Units _grp", and run the true/false leader check inside the code being run. --edit--- Or you might run it on _switchableUnits if those are the only ones you want to cache. That array could be built separately, added to the _allUnitsPlayer array, or both.

1) _allunitsplayer = {isPlayer _x} count playableUnits && switchableUnits; The line fails because "&&" seeks boolean returns to compare, not number or array. "Count playableUnits" returns a number and "switchableUnits" returns an array. The compared values have to be boolean. 2) while (AICACHESTART) do { While-do uses code brackets in place of the condition brackets. --edit -- But apparently AICACHESTART has to be in condition brackets within the code brackets: https://community.bistudio.com/wiki/Talk:while 3) } foreach !leader _grp I think this fails because leader returns an object not a boolean. "!" (not) checks for a boolean return and reverses it.

I would suggest using while-do in place of a runner, that way the trigger only needs to be fired once. while {alive p1} do {sleep 60; <code to go to player pos>}; As long as the player's alive it would update every sixty seconds. What I don't know is if using the move command might stack waypoints doing this. Each time move command creates one it makes it the current waypoint, but wiki makes no mention whether the old ones are deleted or are moved down in the queue. -----------Edit------------------------- eegore - I used your original setup and got it to work using a trigger for each of the aa vehicles. The BTR moved to player pos each time an aa asset was destroyed, forcing the player to relocate each time before destroying the next aa asset. Game logic init: same array as yours code in the Condition for each of the six triggers: trigger 1: {alive _x} count aa < 6; trigger 2: {alive _x} count aa < 5; trigger 3: {alive _x} count aa < 4; trigger 4: {alive _x} count aa < 3; trigger 5: {alive _x} count aa < 2; trigger 6: {alive _x} count aa < 1; Activation in each trigger: same code as yours using the doMove command Keep testing with the waypoints for realism though. Placing a Search & Destroy waypoint at or near player pos would seem realistic enough IMO. Whenever BTR reached my player's prior position, it just sat there. Waypoints are a group function; but each single unit placed in editor, not being grouped, gets arrayed as a group of [1] under the Center for that side, which is why the group command does work to create waypoints for singular units. But if the unit is part of a group, the waypoint will be assigned to the entire group.

Could be a bad pbo in one of your addons. My impression, from the vertical white line that appears in the center of your screen when the crash kicks in, is that a display/dialog/control is associated with the crash. Check your rpt file and see what's going on when the crash kicks in. http://forums.dayzgame.com/ Also see if others there are experiencing the same issue.

Instead of a move waypoint, I would suggest using setWaypointType "GetOut" for the beach landing with setWaypointSpeed "FULL", plus setWaypointCompletionRadius 25 to cover a tide stretch, sand and water. I ran an editor test on that (not scripted) and under that circumstance they sped right to the beach, disembarked, and ran to the second waypoint ("Move") further inland. It worked quite well (in editor).

In Pw6, in the upper right click the "Options" button. Bottom of the list, click "Settings." It brings up a panel. Bottom left, click "Game Settings." Near the bottom is "Startup Parameters." See if you have -showScriptErrors listed there. Also, the parameters listed apply to the game selected on the main panel. You could have different params set up for A2 and OA. (I think CO launches both.)

Now you want to go here: https://community.bistudio.com/wiki/Tasks https://community.bistudio.com/wiki/briefing Scripts, triggers and waypoints can all be used to execute objectives code. Locations are set using markers. Any defined condition being satisfied can cause the code to run. Keep in mind locality is important in MP since tasks are object specific. There has to be public variable communication between server and clients with the same task. Scripting is necessary for MP. Waypoint and trigger code activations are fine for SP. There are a few videos on the web showing how to use triggers and waypoints for SP, just search videos for "Arma2 Objectives". MP setup gets more complex with the communications involved. But once you get familiar with how it works in SP setup, carrying that into MP comes with understanding how locality communications work - public variables, event handlers, server- and client-side scripts.

This might help: https://community.bistudio.com/wiki/Category:Scripting_Commands_by_Functionality Click on "Briefing." Has the commands used for doing the objectives.

Fix to the Original Post To those who have already used this fix, I made a correction in the fix listed in the original post. The problem line in the Client_Killed script needs the Warfare public variable "SideJoined", not "side player" as I had originally posted. Doing continued debugging on Warfare I found a new nuisance error was generated and it was associated with using the "side player." A little more research in the scripts found that SideJoined was the variable normally passed to the Base Structure function. Using SideJoined, it also means scope isn't a concern as was addressed originally. Also, as explained here: ... I found it is possible to use this to fix the original missions in your game. http://forums.bistudio.com/showthread.php?181276-Can-t-Respawn-On-When-Diplomacy-Fails&p=2765799&viewfull=1#post2765799