st_dux

@OP: There are a couple of ways to do this easily. First is as tajin said: Group the trigger with the unit or group you want to check. In Eden, this is accomplished by right-clicking on the trigger and going to Connections > Set Trigger Owner; after that, you just click on your unit and the connection is established. Now the trigger detection criteria will have options like "Owner only" and "Any group member" instead of the usual filtering by side. Alternatively, you can change the condition code of your trigger to check for specific units by variable name. As long as the unit in question meets the general detection criteria of the trigger (e.g., a "BLUFOR -- Present" trigger would require that the unit in question be on the BLUFOR side), the unit will appear in the array represented by the special variable "thisList" within that trigger's code fields (condition, activation, deactivation). If you want to check for one unit specifically, then, you could change the trigger condition from the default "this" to "myUnit in thisList". Now the trigger will only fire if myUnit meets the trigger detection criteria; anyone else will be ignored.

From experience, I can tell you that with simple variables like this, it really doesn't. There is so much information being broadcast all the time just to keep the simulation running; the state of one object variable is nothing by comparison. I still recommend just broadcasting it globally using the optional third parameter of setVariable as this is definitely the most pragmatic solution. But if you really insist... You could use a public variable event handler to achieve your goal: init.sqf: if (isServer || (!hasInterface && !isDedicated)) then { var_serverCode = {}; // this variable will serve as a holder for code we want run only on the server and HC "var_serverCode" addPublicVariableEventHandler {call (_this select 1)}; }; Now, whenever you want to change your object variable, instead of doing it normally, do this: _codeToPass = compile format ["%1 setVariable ['respawnable',300]",_squad]; var_serverCode = _codeToPass; publicVariable "var_serverCode"; // send it to HC or server (whichever one this isn't) call _codeToPass; // execute code locally This is overly complicated and totally unnecessary, but there you go.

I don't understand what you mean by this. Are you asking if the AI is player-controlled or not? If the AI is player-controlled, it's no AI; you can check this with https://community.bistudio.com/wiki/isPlayer

What makes you say that? Are you going to be setting this variable every frame or something like that? If you are setting this value infrequently, the network traffic that you'd be introducing would be negligible.

createUnitLocal is a command that exists in the VBS world, but sadly, it does not exist in ArmA. You cannot make multiplayer phantoms, I'm afraid, as fun as that might be for some sort of psychological thriller scenario.

I'm not sure if it's possible for the AI to use action menu items like players do; however, I am sure that there is no need for them to. If you want the AI to perform some action that was added via addAction, meaning the result is either a script call or a block of code, simply call that script or block of code. The AI is under your control as the mission designer, so you can effectively get them to use the action whenever you call the script/code.

You want to know if a unit is not in a trigger area? The easiest way is to use the special variable "thisList", which is an array accessible in the trigger code fields (condition, activation, deactivation) that contains every unit presently meeting the trigger detection criteria. If you want this information accessible in an external script, you can either call the script from your trigger, passing thisList as an argument, or you can set thisList to a global variable. For example, you could make a repeatable trigger with the criteria "Any -- Present" and the following code in both the activation and deactivation fields: var_myTriggerList = thisList Now the global variable "var_myTriggerList" will contain a list of everyone in your trigger's area, updated each time a unit enters or leaves. In your script, you could check against this with the following code to determine that a unit is not in the area: if (isNil "var_myTriggerList") then {var_myTriggerList = []}; if (!myUnit in var_myTriggerList) then {code} (The first line accounts for a situation where no unit has yet entered or left the trigger area, in which case the variable would not yet be defined).

If the first waypoint is "attached to" (I am assuming this means synchronized with) a trigger, then this trigger will need to have fired for the waypoint to complete. Is this intentional? If not, the helo is probably getting stuck here. Also, there is no need to attach your second waypoint to the helipad. AI helicopter pilots will automatically land at any helipad, visible or not, that is nearby.

Thanks for the explanation. This does make sense for discontinuing the use of IDs, although it seems like attaching things to map objects could still be usable. Regardless, this is a really minor thing at the end of the day, I suppose.

Holy moly, you can now disable "autocombat". I just wanted to stop in and say thanks for this addition. This has been at the top of my wishlist forever. I can't wait to try it out!

As far as I know, literally the only difference between the "Switch" and "None" trigger types is the waypoint skipping property. Everything else works exactly the same between the two types. It has always been this way; now, the name is just less ambiguous. Triggers should still execute whatever is in the activation field when fired, so I am assuming the problem you are experiencing is unrelated.

It appears that Switch triggers have been renamed to "Skip waypoint" triggers. Same functionality as before.

It won't. waitUntil loops run only once per frame, which would have a negligible impact on performance for such a simple check, and the while loop that beno provided had significant sleeps in it, making the performance hit there absolutely negligible.

It's important to understand that "player in thisList" doesn't actually return a list of players. Like all conditions, it returns either true or false; that's it. What you are doing by using that condition is making it so that the trigger only fires locally on a machine where that player meets the trigger detection criteria. Because "player" has a different value on each machine in a network game, the effect is that all players can cause the trigger to fire, but -- importantly -- each player can only cause the trigger to fire for itself. In other words, if Player A is in the trigger zone, the trigger will fire for Player A. But if Player B is NOT in the zone when this happens, the trigger will NOT fire for Player B, because from the perspective of Player B's machine, the condition of the trigger has not been met. This may very well be the desired behavior for your application, but if your end goal is to get an accurate list of the number of players in a zone that is then evaluated by some code on the server, it might not be. It's worth double-checking, anyway. As I stated in the previous reply, if you want to get a list of everyone in the trigger, both player and AI, then the proper condition is just "this," which essentially means that the trigger just defers to the detection criteria set in the trigger menu. Then you can pass the contents of the "thisList" variable -- which will include all units who meet the trigger detection criteria, both player- and AI-controlled -- to your script (through the on activation field) to handle whether or not the units are alive. Alternatively, as NeoArmageddon helpfully pointed out, a check for alive status is implicitly made if you set the trigger to filter by side because all dead units are automatically moved by the engine to the civilian side (although historically this has not always happened instantly).

Hello all, My company is looking to purchase the services of a skilled terrain developer (or team of developers) to create a 15-25 square kilometer geo-specific terrain from the Caribbean region of the world. This would be a paid opportunity. If this is something you think you might be interested in, send me a message, and I will provide further details.

I was making the implicit assumption that the trigger would only fire once. If it is a repeatable trigger, then your concern is completely valid.

That condition would not return a list of alive players. That condition would have the trigger fire if the player's vehicle (or the player itself in the case of no vehicle) entered the trigger area and met the detection conditions set in the trigger menu. The equivalent condition that would include all units, player controlled or not, would simply be "this" If you actually want to get this list and save it to a variable, you would do that in the activation section of the trigger, not the condition section. To capture everyone meeting the conditions of the trigger, you could simply use myVar = thisList. If you only want to capture those that are alive, you would need two lines in your activation field: myVar = []; {if (alive _x) then {myVar pushBack _x}} forEach thisList

Notepad++ is all you need.

Very rarely. I get how it's supposed to work, but I've found that the AI's engagement behavior is usually too unpredictable to be used when stealth is a concern. On a related note, there doesn't seem to be much purpose in distinguishing between engage at will and non-engage at will combat modes with AI squads. AI leaders fairly reliably give engagement orders all the time anyway, so the only way to really disable an AI squad's engagement behavior is with the scripting command "enableAttack".

I don't actually recommend doing this, but the following line will turn your AI chopper into an omniscient god of destruction: {if (side _x == west) then {yourChopper reveal [_x,4]}} forEach allUnits;

You're trying to do too many things at once, which is naturally going to be overwhelming. Start small. Figure out how to get the units into the chopper using waypoints alone. There is no need to put anything in any activation field; there is no need to store the group or its members as a variable/as variables. Just try this: Create your infantry group in the editor. Give it a "GET IN" waypoint at the location where you want your group to get into the chopper. Create your chopper in the editor. Give it a "MOVE" waypoint near (but not directly on top of) the location of your infantry group's "GET IN" waypoint. Synchronize your infantry group's "GET IN" waypoint to your chopper's "MOVE" waypoint using the synchronization tool in the editor (shortcut: F5). OPTIONAL: To have more control over the exact position at which the chopper will land, place an "H" object (found under Units Mode (F1) > Empty > Objects) at the LZ location. AI pilots will prefer H locations when landing. If you don't want a visible helipad, you can use the "H (Invisible)" object. Before you go any further with scripting, I would strongly recommend getting the above to work.

Have you tried loading your display as a resource and then using cutRsc?

Yes, this is because moveInCargo cannot take a group as an argument. If you want to move everyone in a group into the cargo space of a vehicle, use: {_x moveInCargo chopper2} forEach (units sq1); What that code is really doing is 1.) Getting the units in the group sq1 ("units sq1") 2.) for each unit in that array ("forEach"), the code in curly braces {} is run 3.) this code takes the currently selected array element ("_x") and attempts to move it into the cargo space of chopper2. Keep in mind, though, that moveInCargo will instantaneously move a unit into a vehicle; there will be no animation, so it's basically teleportation. If you simply want a group to get into a helicopter, you can achieve this entirely without scripting. Simply give the group a "GET IN" waypoint in the editor, and then synchronize this waypoint (use F5 for synchronize mode) to one of the chopper's waypoints at the desired loading zone.

You can use % in SQF as well. Both % and mod function identically... so that's one less new thing you need to remember :)

That is correct. However, you should know that the game handles groups in a special way. A group is not simply an array of units; it is actually its own entity with its own properties. In ArmA, every unit is the member of a group, even if it's the only member of that group. To find out what group a unit belongs to, you can use the group command. If Tom, Dick and Harry are grouped together in the editor (indicated by a light blue line), then running "group Tom", "group Dick" and "group Harry" would all return the same result. To save this result (Tom, Dick and Harry's group) to a variable, you can simply assign it like so: init.sqf: sq1 = group Tom; A typical practice for saving group variables is to use the init field of group leaders you wish to save. Because you are working in a unit's init field, you have access to the special variable "this," which refers back to that unit whether or not you have named it. Group leader's init field: sq1 = group this Note that you don't actually have to use the group leader; as stated above, using any unit in the group would produce the same result, but using the leader makes it easier to keep track of things in the editor. For multiplayer scenarios where the group leader in the editor might not exist (which would happen if no player occupied this unit's slot and AI was disabled), you may want to consider copy and pasting the line into the init field of every unit in a group just to be sure. Now that you have your group saved to a variable, you can do several things with it. Certain script commands, like addWaypoint, require a group input to function. Other commands will require individual units as input. In this case, you can get an array of all units in a group at any time with the units command. You should reference the Biki to see what kind of input is required for the command you wish to use. Hope that helps.