pierremgi

Hello, I'm struggling with 2 remaining issues. Perhaps, i missed soluces: - the (bis_revive_ratioLethal setVariable [_x, _ratioLethal]) error , as dr death jm reported previously; - an Error position: <animate ["wingfold_left",0, _instant]; Error Type Bool, expected Number,Bool File uns_A6_c\functions\fn_wings.sqf [uns_a6_fnc_wings], line 18. Thanks for any help!

thislist has no sense for a waypoint. It works in trigger on act field only. The solution is not so far but there are some missing points for understanding. For example, is there any separate crew already in helo, or is your squad jumping in helo and driving? load/Tr unload have sense for a separate crew (when synced with getIn/getout for squad) . If the helo is empty, you have to assign/ unassign squad members to helo.

An event handler is "waiting" for an event (your object "killed", fully damaged here). Then, It fires the code inside.

in the same script you defined _fobaaf as a local variable. You can place that anywhere after, and forget your looping script.

Strange! name command applies on an object. So, at least, your "bugged" player is not an objnull. As far as you assigned a variable name in editor, there is no reason to loose this variable on server. You could find the question a little bit repetitive and basic, but are you sure all your players have a variable name in editor? I saw some weird behavior with that recently. Checked one after one?

As far as you're naming your playable units in editor, with global variable like Civ_1..., checked them, and let these slots available for AIs in the lobby (presence), there is no evident reason to fail when you want to "access" them. The good question is: how/when do you access them? A waitUntil {!isNull ...}; could help... in a script.

Just verify your local variables are define somewhere, prior to the loop, and mind the scopes. As you said, your in a loop... which one? the script itself? So, no chance your local variables will be defined one day. You could wait for a long time without any execution of your sqfs. A simple solution could be global variables for your objects.

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 ?