opusfmspol

Reflecting on my prior statement: "Nutty activist drive the news media, the news media drives the politicians, the politicians drive the police agencies, and the police agencies drive activists nutty." When you have an Activist as "Politician in Chief", like the US does, it turns this into a malicious looping script called "Corrupt_Political_Indulgences.sqf." The script is not local, mind you, it's global in effect. It can run on any country's political machine. Given the recent events in the Midwest leading to all the protesting, I wouldn't be surprised if it was later learned the guy had an 'activist' buddy who made the phone call for the reason of the response being filmed. But the guy truly has to be given the benefit of doubt because any dispatcher can tell you they do receive some loopy calls from time to time by people with the most honest intentions but who just are not the brightest bulbs in the chandelier.

High five to Germany for that, but in the US a lot of agency dispatchers aren't permitted to have that sort of discretion. Nutty activist drive the news media, the news media drives the politicians, the politicians drive the police agencies, and the police agencies drive activists nutty. It's just one big frickin ugly.

You also could have locality issues, for instance referencing "player" doesn't play nice on a dedicated server since there is no player. But KiloSwiss is correct, without useful information all anyone can do is stab in the dark and most people won't bother with that.

Not a problem at all, it was a suggestion and I like learning new and better methods. i.e., I just recently started learning the potential of {_x} count _value and have yet to fully grasp it. And I have yet to start embracing the "faster" methods as well, still working hard to obtain "functional" first. I appreciate the showing how it can be used. Constructive critique and some good ol' simplified Show-Me-How is always welcome here!

Following the while-do that deletes the crate, you can add code that will recreate _object as another crate when a player comes in range, and have it run the respawn script.

Yeah, it works for Arma 2. Since functions are automatic in A3, I suppose the line "waitUntil {!isNil ("BIS_fnc_init")};" in the Init.sqf might be unnecessary. I used 30 meters for the crate to respawn, and 250 meters for the crate to delete. I used attachTo to place the crate in a truck and then drove away, watching behind to see what happened. The new crate respawned at 30 meters, and when I reached 250 it deleted.

I haven't tried out A3 yet, so I can't comment as to how BIS_fnc_Arsenal works or might impact anything. I know it's an A3 command and won't work in A2. You're running it on the crates. I know if you deleteVehicle on an object still being accessed by a running script, you can get a CTD (crash to desktop). :butbut: So maybe someone else can chime in as to whether Arsenal will still be running when the crate deletes. https://community.bistudio.com/wiki/deleteVehicle CreateVehicle is a global command. When the vehicle is created by anyone it gets created for everyone. But what you don't want is everybody running the createVehicle code since that would create many crates. Everyone who runs the code on their machine would be creating a crate. Being an editor object, everyone runs the crate's init. Dunno how BIS_fnc_Arsenal responds to that either... but you should certainly limit crateRespawn to being run by server only. Start the crateRespawn.sqf with: if (!isServer) exitWith {}; Whereas everyone will run the crate's init, now only the server will run the crateRespawn code. My suggestion below is a looping function running separate from the crateRespawn script. Each loop would check to see if a player is in range. If not, delete the object. Try this, and add the arsenal function after you get it working - I tested with crate distance 30 and range 250 because I had to see the objects to know whether it worked, but I don't know how it will perform with crate distance 1000 and range 500: crate Init: crateRespawn.sqf: compile the "removeObjectUpdate" function in Init.sqf: removeObjectUpdate.sqf: functions module needed

The ShackTac mods. All are great, especially the HUD and Bunnyhop, and ACRE volume for MP using ACRE.

Hello again, Mirek I've been integrating SOM's with my Warfare mission, and got the Transport support working perfectly, using its map-click, radio calls and all... except for this same occasional nagging issue you encountered, and I recalled you mentioned it here earlier, seeking a solution. :confused: I found that the Support call doesn't complete until the SOM Leader disembarks and the chopper starts to fly off. Until then, the support remains active in the list, under "Transport (Active)". You can use that to get the chopper to land again. If the chopper does its annoying little tease by going into hover, have the person who called the chopper go into map and hover cursor nearby where you want it to land. Then have them go to the SOM support menu again and select "Transport (Active)". The chopper will land where they have the cursor positioned on the map. It will do this for pickup and unload. The call is also cursor "context sensitive" in game, so while making the call they can point their rifle exactly where they want it to land (because the map doesn't always show scattered bushes and trees). It has to be the player who made the support call doing this, it won't respond to others who might have SOM's linked. The chopper responds to the Scope for the specific SOM that called it. The others will just end up calling another transport, if they have it available. Some other lessons learned: - If you're looking at mountains in the distance when calling the support, that's where the chopper will go. It's because the call is cursor "context sensitive". Where you aim is where it goes. (That may be why your chopper occasionally fails to arrive - It was my problem a few times. I resolved it by forcing map and a map-click check.) - AI pilots are cautious. They won't land exactly where you tell them if there are objects near, they will instead move to a clear position, and may or may not land. So pick a large clear spot for landing. You can use the map method to redesignate the LZ or use the cursor "context sensitive" in game, pointing your rifle exactly where you want them. - AI pilots are also stupid. When taking off they fly a straight line to the designated LZ, without regard for trees or mountains surrounding the LZ. If there are trees or hills next to the departing chopper in the direction of the chosen destination, they will often crash into them because they're trying to move in the destination direction at the same time they're trying to climb. So again, make sure you choose a LARGE open area for an LZ. (I believe they fly straight line because they're set to combat mode "BLUE" and behavior "CARELESS" when spawned.) - IMPORTANT: The Group Leader who made the call MUST be "last on" and "last off" the bird. Check is made to see if the Leader synched with the active SOM has boarded or disembarked, then moves on to the next phase. It doesn't check for the leader's troops. So make sure the troops are on board before the Leader boards, and make sure the troops are disembarked before the Leader disembarks; otherwise the chopper will fly off, either leaving people behind, or taking away your troops. - You can designate paths for the chopper to follow using the map. This can be done for pickup, or for drop-off. Remember, they fly straight line to the designated LZ. But the support doesn't move to the next phase until the leader has embarked or disembarked. You can use the pickup and dropoff points as waypoints by the Leader not boarding or disembarking. EXAMPLE 1: You have a danger zone on one side, and a safe approach path you want them to use. Go to map and position the first LZ out from the safe approach path. When the chopper gets there, redesignate the LZ at your landing zone. The chopper will depart the original LZ, and come in through the safe approach path. You can do this as many times as needed to keep the transport safe. The support will not move into its next phase until the leader who called the support boards the chopper. (This can still be tricky however, in that the spawn location for the helo is random. You don't know which direction the chopper will spawn in.) (Disregard last, I see you refer to a TSS custom vehicle placed in editor, so you should know where it comes from - its base. I haven't used that in my Warfare mission yet.) EXAMPLE 2: If you have a danger zone directly in path between your pickup point and the dropoff point, you do not want the helo flying you over it. But it will if you simply mark the LZ. So first go to map and designate an LZ off to the side. When the chopper gets there, DO NOT disembark. go to map and designate another LZ that skirts around the danger zone. When the chopper gets there, don't disembark, designate a final LZ at the dropoff point. When the chopper arrives, then disembark. This way, the chopper makes a three-point arc around the danger zone. You can do this as many times as needed to stay safe in transport. The support will not go into its next phase until the leader who called the SOM disembarks the chopper. You also don't need to wait for the chopper to land before designating a next LZ. It can be approaching and will divert as soon as you designate the next waypoint LZ.

The default Warfare settings are 12 max for a player team, and 10 max for AI leader teams. Warfare missions with customized settings, like "Superpowers" or "Dogs of War" might have adjusted values, it depends what they were set for during mission design. The Warfare variables MAXPLAYERTEAMSIZE and MAXTEAMSIZE set the size for teams. The size can be changed using a custom Init Common as shown by Darren Brant. http://sandbox.darrenbrant.com/arma_ii/the-arma-ii-warfare-mission-setting-starting-money-and-supplies In the custom Init Common you change the values for these variables: //Max units that a player can own. BIS_WF_Constants SetVariable["MAXPLAYERTEAMSIZE",12]; //Max units that an AI team can own. BIS_WF_Constants SetVariable["MAXTEAMSIZE",10]; Change the number to what you want for a team size. --- Edit -- If you "Edit Post" and hit "Go Advanced" you can change the post title to something more appropriate.

I've run into something similar before; if you export an earlier version to multiplayer (making it a .pbo) and it still remains in your directory containing the same folder name as an editor mission, the engine reads one over the other when launching the mission. I had to delete the .pbo in the game directory (not documents directory) "MPMissions" before I could get my editor mission to launch right again. My understanding is the engine reads the folder name when launching, and the editor mission and .pbo (internally) are sharing the same mission folder name. So in short, the issue is likely to be the .pbo mission folder and one of your editor mission folders sharing the same name. Maybe rename the editor mission folder, or move the scripts to the new folder if saving under a different name in editor. I've done that before too when I wanted to keep the .pbo.

displays, dialogs and controls. I never really found a truly simple tutorial, but here's what I did find when I was looking for the same: https://community.bistudio.com/wiki/Display https://community.bistudio.com/wiki/Control https://community.bistudio.com/wiki/Category:Dialogs https://community.bistudio.com/wiki/Dialog_Control http://forums.bistudio.com/showthread.php?144954-Dialog-Tutorial-For-Noobs-By-A-Noob I found Iceman77's tutorial for noobs pretty understandable, but everything that goes into building them seems complex.

I implemented HALO jumping in my Warfare mission, and he's doing it right. But I seem to recall seeing messages in Steam from people not being able to call HALO, and IIRC it had to do with them running OA without A2. The Halo script being called is from A2. OA has a different Halo available, however if you're running CO you can still use the A2 Halo. I tested your script exactly as you posted it, using a clean map and an ammo box as the addAction object. Worked perfectly. I don't think the problem lies with the script. If you've got A2 included, I don't know what to tell you other than something external to the script must be bugging it.

I suspect only one sleep is needed after the ACM's initialize, to wait on functions before setting all of the variables, since BIS_ACM_addGroupClassesFunc uses functions. I would approach it like this: waitUntil {!isNil {myACM1 getVariable "initDone"}}; waitUntil {myACM1 getVariable "initDone"}; waitUntil {!isNil {myACM2 getVariable "initDone"}}; waitUntil {myACM2 getVariable "initDone"}; waitUntil {!isNil {myACM3 getVariable "initDone"}}; waitUntil {myACM3 getVariable "initDone"}; [color="#0000FF"][i]// Waiting on Functions last. Each ACM creates a new functions module. Until one functions fully initializes, // all other functions will also fully initialize. The first one completed will set init true, but the last one // initializing is actually the one to wait for.[/i][/color] waitUntil {!(isnil "BIS_fnc_init")}; [color="#0000FF"][i]// Since function init could be true even if another is initializing, the one sleep is needed to give the last functions time to // initialize. You do not want a delay beyond 50 seconds after "initDone" or ACM could start spawning with default groups.[/i][/color] sleep 5; [] spawn { [0.5, myACM1] call BIS_ACM_setIntensityFunc; [myACM1, 300, 500] call BIS_ACM_setSpawnDistanceFunc; [0, 0.25, myACM1] call BIS_ACM_setSkillFunc; [0.5, 1, myACM1] call BIS_ACM_setAmmoFunc; [["BIS_TK_GUE"], myACM1] call BIS_ACM_setFactionsFunc; ["ground_patrol", 1, myACM1] call BIS_ACM_setTypeChanceFunc; ["air_patrol", -1, myACM1] call BIS_ACM_setTypeChanceFunc; [myACM1, ["TK_GUE_ATTeam","TK_GUE_Patrol"]] call BIS_ACM_addGroupClassesFunc; }; [] spawn { waitUntil {!(isnil "BIS_fnc_init")}; [1, myACM2] call BIS_ACM_setIntensityFunc; [myACM2, 400, 700] call BIS_ACM_setSpawnDistanceFunc; [["BIS_TK_GUE"], myACM2] call BIS_ACM_setFactionsFunc; ["ground_patrol", 1, myACM2] call BIS_ACM_setTypeChanceFunc; ["air_patrol", -1, myACM2] call BIS_ACM_setTypeChanceFunc; [myACM2, ["TK_GUE_GroupWeapons"]] call BIS_ACM_addGroupClassesFunc; }; [] spawn { waitUntil {!(isnil "BIS_fnc_init")}; [1, myACM3] call BIS_ACM_setIntensityFunc; [myACM3, 400, 700] call BIS_ACM_setSpawnDistanceFunc; [["BIS_TK_GUE"], myACM3] call BIS_ACM_setFactionsFunc; ["ground_patrol", 1, myACM3] call BIS_ACM_setTypeChanceFunc; ["air_patrol", -1, myACM3] call BIS_ACM_setTypeChanceFunc; [myACM3, ["TK_GUE_Group","]] call BIS_ACM_addGroupClassesFunc; }; That's because ACM uses "Garbage Collector" and your intensity setting is maxed on two of them. The GC's collection time, once dynamic cleanup is called, is 30 seconds if alive or 60 seconds if dead. Once an ACM patrol goes past their "patrolLifetimes" setting (1-3 minutes for air, 2-5 minutes for ground), dynamic cleanup is called during the next spawn check. When the ACM "intensity" setting is high the spawn checks occur in a very short random time, and you're using the highest setting so it's not surprising they clean up quick.

It uses an if-then to add only the desired elements into the array. If-then is a true/false test ("boolean"), so whatever the (condition) is, it must return a boolean value: either TRUE or FALSE. An example scenario: [i][color="#808080"]// The group A1 belongs to is designated _rescue.[/color][/i] _rescue = group A1; [i][color="#808080"]// The empty array is declared.[/color][/i] _rescuePlayers = []; [i][color="#808080"]// A "forEach" check of group _rescue adds player units into the array, filtering out the AI.[/color][/i] { if ([color="#FF0000"]isPlayer _x[/color]) then {_rescuePlayers = _rescuePlayers + [[color="#FF0000"]_x[/color]]}; } forEach [color="#FF0000"]units _rescue[/color]; [i][color="#808080"]// "isPlayer" returns true or false. If true, the unit being tested is added into the array. // The resulting array: _rescuePlayers = [A1,A4,A6][/color][/i] [i][color="#808080"]// Distance check is made from the array of players.[/color][/i] {_x distance Hostage1 < 5} count _rescuePlayers > 0; tested, and this works in a trigger: rescue = group A1; rescuePlayers = []; {if (isPlayer _x) then {rescuePlayers = rescuePlayers + [_x]};} forEach units rescue; {_x distance Hostage1 < 5} count rescuePlayers > 0; No, because "Hostage" is an array of objects, and not an object. "Distance" checks the distance between two objects, locations or positions. The code would have to be reworked to cycle through the objects in the rescue and Hostage arrays, which can be done but you're looking at cycling two arrays to obtain a true return for the trigger. Might look at panther42's suggestion for an easier approach with that.

Yes. It sounds like you have two groups, one being the vehicle crew and the other being the cargo troops. The vehicle is given a "Transport Unload" waypoint on the beach. The squad in cargo is also given a "Get Out" waypoint on the beach, synchronized to the "Transport Unload" of the vehicle. For a shoreline landing, both waypoints need to have about a five or ten meter completion radius to account for the tide (the default radius is too exact for a shifting shoreline). The two waypoints are placed on top of each other. After the "Get Out" waypoint the disembarking squad is given a "Move" waypoint to send them charging inland. So the vehicle will move to the unload waypoint, and won't move further until all cargo troops have unloaded. The cargo troops are cargo in transport, and move with the vehicle. They won't disembark until they reach their get out waypoint. The getout waypoint won't complete until all its group members have gotten out of the vehicle. The unload waypoint won't complete until all the cargo troops have disembarked. Being synchronized, the two waypoints don't complete until both are satisfied. Then the vehicle crew and the troops will perform their next waypoints.

In this instance units group player returns an array of the entire player group, so it would be a matter of replacing it with an array of your own choice. You could simply assign it: _array = [A1,A2,A3,A4]; {_x distance Hostage1 < 5} count _array > 0; ... or declare the empty array first and build it depending on what you filter to add into it: _array = []; if ([i][color="#FF0000"]<return from unit is true>[/color][/i]) then {_array = _array + [[i][color="#FF0000"]<unit>[/color][/i]];}; {_x distance Hostage1 < 5} count _array > 0;

Disregard, found my own suggestion didn't work either, trying to find out why I thought Count command returned a number rather than an object - or will it return the represented object from the array as well? The distance command needs to determine distance between two objects. Does the _x return the object and the count return the number? --- Edit -- Disregard, tested and YES! Very nice to know, I can use that in my mission too, to find out if any group members are by a UAV terminal. Thanks AZCoder!

Waypoints are group commands. Check your grouping. My experience is that AI do that sort of thing when a group is split; they'll try to reconsolidate with lost members before moving on to waypoints. Don't know if it's happening in your mission, but check to see if groups are split up. Also if the vehicle driver is a different group than the cargo soldiers, the vehicle driver moves to his own waypoint. There needs to be synchronized waypoints for the boat driver and the cargo soldiers (Transport Unload for driver with Get Out for cargo troops), with the soldiers having another waypoint further inland. The driver's group could also be given a Get Out waypoint following the Transport Unload.

Needs to be : {_x action ["Eject",War_Thunder]; unassignVehicle; sleep 1}foreach units _group; Bracket begins the "forEach". If problem persists, try replacing War_Thunder with vehicle _x, and use unassignVehicle _x.

Having watched this video I have the impression the LEA addAction is given to players in proximity to a respawn marker or object. Players only see the addAction when in proximity. Running a server isn't in my experience range. On mission editor side, thoughts are an event handler added to units during init, or a repeating trigger encompassing the respawn zones. But the code being run would need some means of identifying and referencing the addaction ID assigned by the LEA. That may or may not be complicated. I'm sure it wouldn't be the best way of handling it as well. I would think server would have a better means of doing it, I just don't have that experience.

I don't use LEA so I don't know at what point in mission scripting the addAction is given to the unit. Generally, it would go in a block of code immediately following the addAction being added to the unit, so that the addAction is immediately removed if given to an EAST unit. The preventive approach would be to allow the addAction to be added only if not EAST: if (_side != EAST) then { ....run the code giving the addAction... };

_side = side _unit; if (_side == EAST) then {_unit removeAction _index};

createMarker is used to create a global marker visible to everyone. CreateMarkerLocal is used to place a marker only on the local player's machine, and not visible to everyone. It's a matter of whether everyone, including the enemy, should see a marker. CreateMarkerLocal is used to limit marker visibility to a side, team, single unit, or specific players. The command is scripted to run only on the targeted players' machines so that they will be the only ones who see it.

Classics never die, and A2/CO has certainly achieved Class status. Someday those who would sail away will hear the siren song and be lulled back to its rocks, seeking a little more "hurrah." --- Edit -- The developers create the Masterpiece. The gamers, modders and community make it the Masterpiece. Without the developers, there would be no Masterpiece. Thank you BIS!