opusfmspol

"hideObject", "knowsAbout" and "reveal" is what comes to mind, but I think knowsAbout would be difficult to assess what kind of return to trigger from. I mean, if the enemy is standing over the hidden soldier, how much is knowsAbout going to return? https://community.bistudio.com/wiki/hideObject https://community.bistudio.com/wiki/hideObjectGlobal https://community.bistudio.com/wiki/knowsAbout https://community.bistudio.com/wiki/reveal

Do you mean you can't activate them because they don't show, or they show but you can't activate them?

ALICE allows custom code to run when a civilian initializes. The code is stored in an array defined under "ALICE_civilianinit". https://community.bistudio.com/wiki/Ambient_Civilians#Set_variables_to_BIS_alice_mainscope_with_desired_values The example given is: [i][color="#808080"][bIS_alice_mainscope,"ALICE_civilianinit",[{_this addweapon "Mk_48"}]] call bis_fnc_variablespaceadd;[/color][/i] Don't use that example. I spent A LOT of time, and had one hell of a time, getting it to work. It's dependent on Functions and becomes a pain since Functions may not initialize by the time ALICE initializes. Not only that, my attempts at adding new variable space code using triggers didn't work as I drove town to town. The codes got added, but just didn't run. I suspect ALICE initializes everything at start and doesn't query the variable later. Use this example instead - place in the ALICE init field: BIS_alice_mainscope setVariable ["ALICE_civilianinit",[[b]{_this addweapon "Mk_48"}[/b]]]; The civilian men will have machine guns. It works and is a lot easier. You'll notice it uses an array to store the code. That's because in the array you can define more than one block of code to run when each civilian spawns. When they spawn they run each set of code in the array. Note: Be sure to separate code blocks with commas "," BIS_alice_mainscope setVariable ["ALICE_civilianinit",[[b]{_this addweapon "Mk_48"[/b][color="#FF0000"]},{[/color][b]hint "hello"}[/b]]]; I suggest only placing your code in the ALICE module's init field if it is simple and short, like the example above. For more complex code, put it at beginning of your init.sqf. Don't let it be delayed by any "waitUntil" or "sleep". Tested on Utes, clean map with player and ALICE module; I got this to work, putting it in init.sqf: - Replace the code with anything you want. - Get rid of the first set of code and comma if you want everything in a single block of code. - If you wish to add a third block of code, insert a comma and another block before the final line: ]]; Final note: You'll notice the first block of code uses _this and the second block of code uses _unit. Both are referencing the civilian being initialized. You can use either one to reference the civilian running the code. For the 30% random chance, insert this in the code: _random = random 100; if (_random < 30) then {....do this....};

It would go in a script. For editor, give the truck a name and set it's status to locked. Place a trigger set to "anyone present". In the condition field: time > 500; In the activation field: MyTrucksName lock false; You could also have the trigger give a hint that the truck is now unlocked. MyTrucksName lock false; hint "Fuel Truck is now unlocked.";

// _vehicle is the fuel truck _vehicle lock true; \\ locked waitUntil {time > 300}; \\ wait 5 minutes _vehicle lock false; \\ unlocked

Warfare. Hesco barriers for base building, money for capturing/killing/accomplishing, and purchase of weapons, soldiers and vehicles.

Not as easily as setting a timeout number, but I would think a delay could be created. The module allows custom code to run at certain points. An example, in module init: missionNamespace setVariable ["BIS_SSM_Airstrike_VEHICLEINIT",{_pilot sidechat "I'm on my way!"}]; When the Airstrike support is called, the pilot sidechats that he's on his way. The custom code uses the variables set in the underlying scope of the function they're called from. In BIS_SSM_fnc_SpawnAircraft function, _pilot references the pilot and _vehicle references the aircraft. Those are used in the code. The caller is _this select 1. These variables could be passed into a script. I would try using such code to have Group _pilot follow cycling waypoints on a switch, and create a trigger that would hit the switch. Or set a timeout condition code for the request:

I don't know VBS or A3. The corpse params are all listed as A3. https://community.bistudio.com/wiki/description.ext#corpseManagerMode Bodies don't typically disappear on respawn in A2 or OA unless Garbage Collector (GC) is set up. Seems the Corpse Manager Mode is used to manage the corpse removals, is the option in VBS? --- Edit -- Because I was thinking if your param times worked, would the scripts still be needed?

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;