Waiting for Death

[Barak]

I have a group (call it W) that I need to wait at one of its waypoints until either everybody in group P is dead, or everybody in groups A, B, C, D, and E is dead.  Once that happens, group W should move to its next waypoint and so on.

I don't want to unduly slow down the game engine, so I'd rather not have to do something like (count units P == 0) || (count (units A + units B + units C + units D + units E) == 0); that's a lot of counting to be done.  Is there a trigger type or something that's meant to fire when all units of a group are dead?  Is there some other shortcut that I'm not thinking of?

Thanks,
Barak

[Sentinel]

Perhaps you could make a script that checks, say couple times a minute, are they all dead, like this:

__________
#wait
~15
?((count units W == 0) || (count (units A + units B + units C + units D + units E) == 0)):dead=1; exit
goto "wait"
________________

Use a trigger taht activates when dead == 1.

[Barak]

Yah, I guess that'd work.

Another question: does anybody know if the performance difference between counting and appending is significant?

What I mean is, there are at least a couple of ways to count the number of units remaining in a collection of groups:

Appending:
count (units A + units B + units C)

Counting:
(count units A) + (count units B) + (count units C)

The appending method probably takes less time for the script interpreter to parse, but appending arrays to one another probably takes a significant amount of memory shuffling, especially if the groups are still well-populated--which would be at the point where the game engine has the least time to spare.

The counting method arrives at the answer much more quickly, because all it has to do is count preexisting (well, sort of) arrays and numerically add the results, instead of first copying all their contents into yet another array and then counting that.  However, there are more tokens for the interpreter to parse, so conceivably the extra time taken for the interpreter to figure out what it's supposed to do might cancel out the time it saves in doing it.

Does anybody know?  (This is the sort of thing that would be difficult to test.)

Oh--one other thing.  Where should I put the [] exec "script.sqs" for a script like this that's supposed to run in the background?  Perhaps in the On Activation box in the waypoint before the one at which group W is supposed to wait?

Thanks again,
Barak

[Sentinel]

My opinion is that scripts that doesn't change any objects current status by moving or rotating are quite light. Foe example, I made a script that checks if a unit is dead. If it is dead, it will be removed and deleted (I know it isn't my idea, but it works). Anyway, it checked about 60 units and no waiting times from an array. I didn't see any lag in my machine (Celeron 500, 320MB, Ati Radeon 7200) which is quite a surprise to me.

The if you have a script that moves object(s) rapidly, like an artillery script, it slows computer, at least mine.

I usually use triggers, that checks if there is people from wanted side. I think if you use waypoints (I don't use them, I do everything by scripting) script is launched when group comes to that waypoint, not when they are commanded to move to that waypoint. Not sure, haven't tested.

Hups, little way out of the question.

You could sychronize waypoint with trigger so that when trigeer is activated, waypoint will be released or you could use LockWP command which locks next waypoint. If I remember correctly it is used like this:

GroupName LockWP True or False

True locks next waypoint and False releases it.

Long questions, longer answers