st_dux

You'll have to be more descriptive than that to get any help. What was the trigger supposed to do exactly? What were its statements?

You can use the init variable in ALICE to add an extra killed event handler to each created civilian. Then you can use the event handler to detect if the killer was BLUFOR or not.

Exactly what constitutes "too off-topic for off-topic"? Whenever a thread is locked in off-topic for being "too off-topic," the reasoning is never clearly explained. It appears that there is no clear guideline for determining the degree of something's "off-topicness" and that this "rule" basically comes down to the arbitrary whims of the moderation staff.

What was wrong with it? I didn't notice any problems.

Boy, that TODO sure is quite the scripter. I see that guy's name everywhere :rolleyes: But to answer your questions: 1. This script will run for everyone on a dedicated server as long as it is called by everyone. Just execute it from init or wherever else you need without using a server check, and it should run on all clients just fine. 2. Have some variable set to true at mission start. Whenever the task fails, set that variable to false. Add that variable to the condition for the while loop, i.e.: while {_this > 0 [b]&& <yourVariableNameHere>[/b]} do { ...

It would be nice if the mission editor were allowed to set this sort of behavior directly. I have never understood why there isn't a simple scripting command along the lines of "allowLights."

AI pilots will always try to rigorously maintain a specific height above ground level even when flying through terrain that has highly variable elevation. Since they also have a tendency to overcompensate when making adjustments, this will often result in their demise in mountainous terrain. Like many things in ArmA, this doesn't make any sense -- there ought to be a way to set AI altitude above sea level, which is how pilots actually fly most of the time -- but unfortunately, there is no way around it. Your only options will be to make the AI fly even higher up, giving them more room to screw up, or to use scripting to force them upward in case they dip too low (this generally looks quite fake, though). You might also try forcing them to fly more slowly around the danger area, but there is no guarantee that this will fix the issue.

The optics appear to produce larger images because the default field of view is much larger than it would be if you were looking through a screen-sized window in reality. It's not that the images in the scope are too large; the images without the scope are too small. This is necessary, though. If the default field of view were set to a realistic level, then the smallness of your computer screen would make it practically impossible to have any situational awareness, and this is even less realistic than a zoomed out view.

Are you in Waypoints Mode when double-clicking? After you have selected the unit, press F4 to enter waypoints mode; then double-click.

This mission is a perfect example of the problem with default AI "combat behavior" in OA. Until they believe that an area is "clear," the AI will basically just freeze wherever they are and act super cautious. This might make sense in some situations, but it certainly doesn't make sense when the task at hand is to get the heck out of the AO ASAP. Unfortunately, there doesn't seem to be any way to force the AI to move quickly while under fire. More than any other aspect of the AI, this needs to be fixed.

There is an easier way. Simply make the trigger repeatable and add "&& alive <loudSpeaker>" to the condition field of the trigger after "this" (replacing <loudSpeaker> with the name of your loud speaker object).

I can find no such waypoint. What are you referring to, exactly?

Unfortunately, what you want to do isn't really possible. The AI has no concept of proper assault technique, and it is impossible to override their default combat behavior. In general, mission editors make up for this by just adding more AI to a mission. Yes, this is lame.

@AZCoder: Interesting use of private. I've always found it easier to simply declare the variable as any value (e.g., an empty string) prior to using it in an inner scope.

Now it's just a process of elimination. First, the way you're calling the script is odd. I don't know if this is actually causing a problem, but you shouldn't use local variables (variables that start with an underscore like "_Handle") in a trigger field. Furthermore, there is no reason to pass "player" to the script. Change your script call in the On Act field to the following: nul = [] execVM "join.sqf" If the "script is running" hint still doesn't show up when the host isn't a leader, try commenting out (just add "//" to the beginning of a line) different parts of the script to see if anything is causing a problem (I would start with the task stuff at the bottom -- just comment all of that out). ---------- Post added at 08:13 PM ---------- Previous post was at 08:11 PM ---------- Also, how are you naming these units? Are they all named in the editor's name field, or were some of them created using scripting?

See if the problem is with the trigger firing or the script itself. Using your original example, change the On Act of the trigger to just a simple hint; don't actually run the script. Then repeat the experiment and see if the hint works. From there, the solution should be easy to figure out.

You need to put man01 in thisList In the condition box. Erase the default "this" first.

1: This is possible, but it requires a fair amount of scripting. There is no way to make this happen auto-magically. Luckily, there are already a few community-made AI script suites that achieve this very goal; one such example is UPSMON. 2: Getting placed squads to patrol can be done very easily using the CYCLE waypoint type. Simply create a patrol path using MOVE waypoints, and then place a CYCLE waypoint at the end, next to the original MOVE waypoint where you want the patrol to start over. A CYCLE waypoint will automatically find the closest previous waypoint in the group's waypoint path and have the group switch back to that waypoint, progressing from that point forward. AI will automatically attack whatever enemies they are aware of, so technically all you need to do is create a waypoint in the vicinity of that which you wish to be attacked. If you want the AI to blow up a particular unit or vehicle, you can use a DESTROY waypoint that is attached to said unit or vehicle (to attach waypoints to objects, simply double click on the object in the editor while in waypoint mode). Of course, 95% of the time this won't create the most compelling of attack maneuvers; the AI tends to move extremely slowly and get bogged down while in "Combat Mode," which it always defaults to when it knows about nearby enemies (as long as it isn't already in "Careless" or "Stealth" mode, neither of which is particularly conducive to attacking). There are various methods of scripting AI behavior to look more assault-like, but honestly, as native FSMs (such as "how to behave in combat") cannot be overwritten or disabled, none of them are all that effective. This is just a shortcoming of the ArmA 2 AI. As for spawning AI randomly, this is again quite possible, but there is no auto-magical way to do it. However, there are a multitude of AI script suites out there that focus on doing just this in a somewhat easy-to-use way, the most prominent example being DAC (Dynamic AI Creator). Take note, however, that a large number of randomly spawning AI, particularly if using DAC, can cause considerable performance issues (and latency issues in MP). As a side note, the GUARD waypoint is actually a pretty powerful waypoint type that can be used to create a basic sort of "higher-order behavior" in the AI. Whenever a group is given a GUARD waypoint, it will move to the first-placed "Guarded By..." trigger area that hasn't already been occupied by another group following a GUARD waypoint. However, once enemy are spotted anywhere by anyone on that group's side, all groups currently on a GUARD waypoint will leave their assigned trigger area and move toward the enemy contact (N.B., this can sometimes lead to impractical/ridiculous results, such as when you have an infantry squad with no transportation stationed on the opposite corner of a large terrain -- they will just walk all day until they get to the enemy, which will likely be gone by the time they get there). Once the enemy contact has been eliminated or lost, the groups assigned to GUARD waypoints will return to their previous trigger area post. A GUARD waypoint, therefore, like many other waypoint types in the game, can only be competed via a Switch-type trigger or scripting commands; if neither measure is taken, the group will maintain its GUARD behavior until it is killed or the mission ends.

Alternatively, make the trigger for Anybody Present, then put "man01 in thisList" as the condition.

Thanks for clearing up the specifics on while/waitUntil loops, sbsmac. I suspected I had some of the details wrong. I'm pretty sure that the script scheduling of ArmA 2 limits while loops to running once every .02 seconds, though (whereas ArmA executed the code as many times per frame as possible). As for private, I still don't think it's necessary if you never intend to use the script outside of the standard "execVM 'myScript.sqf'" format. As long as you are using execVM to call it, the variables within will never overlap with anything else. I agree that it's a good precaution for publicly-released functions, though. @NGagedFX: Even with the .02 second delay, while loops can get a bit intensive, so I think it's good practice to add a short delay if the loop is going to be running for any considerable length of time. waitUntil, on the other hand, seems fine to run without a delay; with execution being limited to one time per frame, waitUntil loops don't seem to be all that resource-intensive.

shk's method works and is the best solution I can think of. Make sure that the trigger is actually setup to be activated by "Anybody: Present" at the top of the trigger dialog.

@HitmanFF: Your use of "private" is unnecessary. Basically, "private" only matters if you are calling other code (e.g., a function) within a script, and then it only matters for the called code (and really, it only matters there if any local variable names between the main script and the called code overlap). -snip- See sbsmac's description below. It's more accurate than mine was.

If you don't need the unit to do a smooth transition into the animation initially, you can use switchMove instead of playMove. Then you will be able to exit the loop using switchMove "".

Of all the issues mentioned by the OP, I'd say that the most irritating to me is probably the fact that it's nearly impossible to get the AI to actually move aggressively. You cannot take them out of "combat mode," which means that you cannot overcome their default, overly-cautious behavior. You can see them trying to do a form of "bounding overwatch" when they move, but they do it right in the open without any regard to cover and in little over 20 meter intervals. It's not realistic at all, and it turns them into sitting ducks. I know AI programming is difficult, and considering the dynamic and open nature of the game, AI issues are inevitable. It would be really nice if BI allowed mission editors to override default AI behaviors, though. Even being able to just force the AI to run from point A to point B without trying to go prone in the middle of a field while providing "overwatch" for someone who is also prone in a field some five meters ahead would be a godsend. I mean, just check out the very first mission of the OA campaign. As soon as your "assault team" gets off the helicopter on the airfield, they go prone in the middle of an open space that has no cover. This would never happen in reality, and indeed, they wind up getting shot up and killed much of the time. It would be great to see the AI actually sprinting for some form of cover before getting low like soldiers do in the real world.

The "aiming circle" will get larger the longer you hold the button down. This is a progress bar of sorts. Still, throwing grenades in ArmA is always a dangerous affair. The "physics" are utterly unpredictable, and it's very difficult to get a feel for exactly where you're aiming, particularly at short distances. Something that would be really simple in reality, like tossing a grenade through a window into a room, is extraordinarily challenging and potentially suicidal in ArmA.