I know this is really getting down to the wire in terms of speed, but I'm really curious, does anyone know which takes Starcraft more time, running a condition check, or running an action?

For example, say you had a map with a hatchery, and you wanted to make sure P1 never had any larva.

My first inclination would be to do option #1:

C: P1 commands at least 1 larva.
A: Remove all larva for P1. Preserve trigger.

But option #2 would be to do this:

C: Always.
A: Remove all larva for P1. Preserve trigger.

The reason I wouldn't use #2 is I always assumed that each Action cost a tiny amount of memory to run. In a map using hypertriggers, this would essentially mean I would have a "remove" action executing 12 times per second, without need (except every what, 20 seconds when a larva spawns?). A lot of wasted memory. I figured that would lag up the game, even if only by a tiny amount (but in a huge RPG with thousands of triggers, these things add up). So I would always prevent Starcraft from running all those needless actions by putting in a condition.

Does that seem right? Or does the Condition "check if P1 has a larva" take more time to execute than the Action "Remove all larva for P1"?

Thanks in advance.

The only problem with your theory is that one, usually a tiny trigger like that causes negligible lag, I mean TRULY negligible, so it doesn't really matter, and second, the second option will run faster than the first, since SC takes about 2 trigger loops to update Command or a single loop to update Bring, but it can still remove it, even if it doesn't think it's there.

Sweet, thanks for answering... I was afraid no one would... I have a question though...


What do you mean by that? Shouldn't it make no difference, because it'll only activate the Remove action once every trigger loop anyway?

Or do you mean that when SC runs a Bring check in that trigger, it won't act on it until the next time the trigger comes up?

Let's say I had a trigger that created a unit, then right after that trigger I have another one that removes the unit I just created, IF the player that the unit was created for brought the unit to the location it was created at, then what would happen is the unit would show up, the second trigger wouldn't notice it, but it would notice it on the second loop and remove it.

Now do the same scenario, except replace the bring condition in the second trigger with an Always, then the unit will be created and removed in the same loop immediately, and the players might not even see it.

That's the reason why Mobile Grids work so well, because they can be done so quickly that the player can't even see them, since all they are is a bunch of actions, they never have a condition to see if the units created are actually there, they just assume so.

ahhhhhh I see... Makes sense. And you said that Command checks take an extra loop to be updated? So if I had a trigger creating a unit, it couldn't be detected by a Command condition until two loops later?

Man, I'm glad people like you exist.

Man, this really is extreme mapping.
I think that we're getting ahead of ourselves...
Do we really need to push every edge of mapping?
Is it really necessary?
And if it is.
What do you use these insane things for?

Well, that actually causes a lot of bugs, so knowing that information is extremely handy.

I can't think of any point in any map where it would matter which of those are faster.
I just use always, it's reliable, and easy to change if you need something more definitive later on.

I mean, when always isn't flipping over. You KNOW something's [Drastically] wrong eh?

Okay, let me show you one then:

Trigger 1:
Player 1 brings 1 Terran Marine Anywhere

Remove 1 terran marine for player 1 at anywhere
Give 1 mineral to player 1
Preserve trigger

Trigger 2:
Player 1 brings 2 Terran Marine Anywhere

Remove 2 terran marine for player 1 at anywhere
Give 2 mineral to player 1
Preserve trigger

These triggers will give you 3 minerals per 2 marines, since the bring condition will not update in time to realize that one of the two marines has been removed, so the second trigger will think that there are still two marines.

I'd just use:

Player 1 brings at least 1 Terran Marine Anywhere

Remove 1 terran marine for player 1 at anywhere
Give 1 mineral to player 1
Preserve trigger

See? Easy.

And now you have to loop through for every marine, making it take longer for larger amounts of marines, whereas, with my way, you would EXPECT to transfer 3 marines at a time, going 3x faster than your way.

Post has been edited 1 time(s), last time on Jan 28 2008, 10:54 pm by Falkoner.

But with hypertriggers. All but a MASSIVE amount of marines would be gone in the blink of an eye.
Besides, if you were planning on giving marines for the minerals for whatever, couldn't you just make a trigger:
Player Commands at least 101 marines [Or bring, whatever.]
Remove 100 rines
Make 1 Zealot.
Prserve trigger.

Add a trigger to deal with zealots.
The 101 is just because a marine may get removed in the middle of that cycle.

But what about if you have 150 marines? Now you are stuck with fifty extra, and hyper triggers only run 12 times a second, so it's really not the blink of an eye, 60 units takes 5 seconds to transfer.

So hide said marines.

It is probably important to note that this is not actually due to the physical CPU time it takes to update any lists, but rather the manner in which the Starcraft engine handles its threading.

Yeah, exactly. In addition to speed, I guess I just have a philosophical reason for always using conditions... I like to treat each trigger as an action in the world, and so I metaphysically link each trigger to the reasons it executes. But now that I know that bring and command conditions take an extra loop, I will probably only use conditions when necessary.