pierremgi

Please, btw, make the handlers (return value) of addAction more specific and automatic! It's not a great idea to return a numeric value instead of alphanumeric one. For many reasons, you can remove the wrong action. What I suggest is to return the string of the title: _act = player addAction ["Exec the file", "somescript.sqf"] ; hint format ["%1",_act]; // returns "Exec the file"

If it's not a question of initialization order, for JIP and disabled ai in lobby, this could be a timeout problem for running scripts in due time (Arma's engine), regardless of traffic jam. So, perhaps, too heavy scripts not working within 3ms slots. Difficult to help deeper without any idea of your scripts.

Personally, i don't spawn with trigger, but in the nearest house(s) along with player's) positions. When a house is "treated", there is a timer to rearm the loot. I randomize the elected houses, the positions in houses and of course weapons/nbr of mags and/or items.

I don't like useless dependencies, but I'm just using the CBA patrol module for my COOP (blue link below). Lazy probably. But I have so much personal scripts, I can make this unique exception.

playableUnits works when the AIs stay enabled in lobby (Ai's slots available). If you disable them, playableUnits misses all unoccupied slots. So, even if you have named a playable slot civ1, this variable/object will not be "present" if you don't use the slot and disable AI in lobby. There is no workaround for that. It's a question of presence. allPlayers is always the actual players list, dead or not.

Hi Doc You can use the event handler "handleDamage" and forget the allowDamage false, as far as you can override the final result with a "damage" value. Read the explanations here and here. By the way, I'm no more on Armaholic.

You can place both "ends" on a same trigger, like opfor lose, blufor win. So ,the first trigger which meets its own condition will fire and mission ends regardless of the status of the second one. You can fire triggers on server only (not a problem) then call BIS_fnc_endMissionServer , and even customize the cfgDebriefing in the description.ext. The timeout for reds, can be initialized at start of the mission, in initServer.sqf, or on a trigger activation. Create a global variable on your server (initserver or in a "server only" trigger). Say myTimer = diag_tickTime; If you want a 20 min slot, just write in the cond field of your end mission trigger: (diag_tickTime > myTimer + 1200) && !alive vehicle1

Name your squad/group, say group1 name your helo: say chopper1 add a task state module completed and link it to your task module (where you can define the mission: pick up, blabla). Link it also to a simple non dimensional trigger with this condition: {alive _x && _x in chopper1} count units group1 == {alive _x} count units group1 the "getout" squad waypoint must be synced to a "TR Unload" helo waypoint. You don't need a trigger for that. On the other end, set a countdown for your trigger if you want to see the sqaud disembark before the end of the mission.

try a stealth behavior along with a waypoint. See also this command.

setGroupId? Simpler: name the group in the group icon variable attribute! (editor): You should try just one addWaypoint, "SAD" rather than "MOVE" type but it's not mandatory if you want to keep some "non alerted patrol" behavior. I guess you don't want to add waypoints over waypoints over waypoints. So, as far as we are in a loop (25sec one as you defined on deact), you can cope with the fact there is no previous "SAD" waypoint, then add a one-shot check on that. I hope this chronology will make it simpler: 1 your group is patrolling or guarding: no waypoints (type returns "") or some "MOVE"/"CYCLE" waypoints; 2 your group detects player(s); 3 if the current waypoint of the group isn't an "SAD" one, // try to make it true! (see 1) 3.1 disregard all previous waypoints (if any); 3.2 addwaypoint "SAD" type. 4 update the SAD position by the trigger loop. In other words, onAct becomes: 0 = thisList spawn { _target = _this select 0; if (waypointType [group1,currentWaypoint group1] != "SAD") then { while {count waypoints group1 > 0} do {deleteWaypoint ((waypoints group1) select 0)}; gr1Wp = group1 addWaypoint [getpos _target,0]; gr1Wp setWaypointType "SAD"; gr1Wp setWaypointSpeed "FULL"; }; if (!isnil "gr1Wp") then {gr1Wp setWaypointPosition [getpos _target,0]}; }; myVariable = true;

Animations are animations. You can find some BI trailers with weapons firing during an animation but there is no simple way to add a shot during it. forceWeaponFire perhaps, with no aim of course.

If you want some choices, you must define the cfgRoles, then apply the BI function as you tried. To select a respawn location, choose custom in editor then add all markers/respawn modules and name them respawn_west_whatYouWant... By this way, you can also respawn on player's/group unit's dynamic positions but that requires some event handlers scripts.

<blufor killed> && alive redVehicle >> opfor win blufor lose <timeOut for red> or !alive redVehicle >> opfor lose, blufor win.

Confirmed. I don't know why this currentMagazine returns the right magazine. But scope seems "private" or something like that. It finally works if you launch the mission twice. One of the weird behavior of some Arma's commands. For hunting the player, do the same thing: addWaypoint for your team, SAD type and setWaypointPosition in the loop (with mortar). An updated position every 10 seconds sounds fine.

There is also a minimu distance for any artillery fire. I think the mortar unit will not fire if the player is within 100 meters (approx). There is also a workaround for unlimited rounds: 0 = thislist spawn {while {alive mortar1} do {mortar1 doArtilleryFire [ getposatl (_this select 0) , mortar1 currentMagazineTurret [0],4]; mortar1 addMagazineTurret [mortar1 currentMagazineTurret [0], [0], 4]; sleep 15}};

Just consider BlacknighBK answer. You have two solutions: a local trigger (add false as 3rd argument for createTrigger command) and put the code into initPlayerLocal.sqf, or rearm your trigger: in cond: this && isNil "blabla" in onAct: your code; blabla = true; in ondeAct: 0 = [] spawn {sleep sometime; blabla = nil}; Why rearming on server? Just because your players are civilian/any. And, as always, thisList is a like a "photography" (short film in fact) of the first unit(s) who met the condition. that means not updated and generally limited to the event within 0.5 sec (time slot of the trigger's check). If 2 units satisfy the condition within this slot, thisList will have 2 objects. So, here, you are checking for "any". When a player dies, it stays "any" (civilian), and you don't deactivate your trigger as the condition stays met. On the other hand, with blufor units presence for example, you shouldn't have to "manually" rearm it, because the blufor presence fails for a dead man (civilian). If on server, the trigger must be global (it is by default), but as midnighters said, you don't want to have multiple triggers on each player joining. So wrap the entire code into if (isServer) then {...} or run it from initServer.sqf. (same).

First, disregard createCenter, createGroup, logic... Just use bis_fnc_spawnGroup. Then I don't clearly understand the "AI vision cone", as far as there is no cone in your script, but you don't need to "attach" anything. Just consider the distance between an AI and a player. If necessary, you can limit the intended behavior (captive false?) to an angle referring to AI's direction. Or, like you seemed to do, define a "spot" in front of the AI by an offset vector.

What about your description.ext cfgRoles ?

yes, you have to rearm the trigger. So, it must be deactivated then activated. Try this way: condition: this && isNil "myVariable" On act: arty1 commandArtilleryFire [getposatl (thislist select 0), "8Rnd_82mm_Mo_shells", 4]; myVariable = true On deact: 0 = [] spawn {sleep 5; myVariable = nil}

Ah OK, I understand. The script uses : _e=cursortarget; Then, effectively, cursortarget needs a "knowledge about" the target. On the other hand, if you replace it by cursorObject, you don't need any loop. see the differences between cursortarget and cursorObject in BIKI. Take time to read the remarks also.

Probably due to the sleep command. You need to spawn you code if you want some scheduled effect: 0 = thislist spawn {_target = _this select 0; ....};

I don't understand why / when you need the reveal command? Your script is something about adding actions like "drag"... So what is the link between all of that?

Just to help at little bit, all the screens are scaled by safeZone (more here) from 0 to 1, from upper left corner to lower right corner, regardless of dimension or ratio. so, a display (control) will start at the middle of the screen with _ctrl ctrlSetPosition [x, y, w, h] format. The coordinate system seems to be hard, but test the 4 and 5 samples in my link. If you want your variable updated with a whatever score, you need to make it "alive" by some script (for example, Gcredits= Gcredits + 1 for some condition). As you can see Gcredits here, is a global variable, not a local one as _Gcredits could be. Remark: the syntax: missionNamespace setVariable ["Gcredits", 0, true]; is the same as: Gcredit = 0, publicVariable "Gcredit"; missionNameSpace is the space (variable recipient/context) by default. It makes sense to precise it when called from another name space (like UI). So, the good question is: what is Gcredits? A personal score for a player >> you don't want to publicVariable it on each screens; or a global variable, common and readable for everyboby >> you have to publicVariable it (or add true as 3rd argument of setVariable).

Just use weaponHolderSimulated instead of groundWeaponHolder. Something like: _weaponholder = createVehicle ["WeaponHolderSimulated", _pos, [], 0, "CAN_COLLIDE"]; Here _pos is what ever position you want, "CAN_COLLIDE" is for spawning inside the building, at the exact defined positions (needed for my own script).

You could use also the CBA patrol module. It works fine (right now).