Which of these is faster, assuming they don't fire constantly?

-=SAMPLE 1=-
-Player 1 Brings at least 1 Marine to Location
=Remove all Marines for Player 1 at Location
=Preserve

-=SAMPLE 2=-
-Always
=Remove all Marines for Player 2 at Location
=Preserve

The trigger function of this site doesn't work, it just makes your posts blank, remove the Trigger tags and that should fix it.

How can they not fire constantly if the second trigger is always-preserved? Not preserving it would defeat the purpose of having it, because it will only run once at the beginning. If you mean to ask which one will detect and delete the unit(s) faster, they are equal in that respect.

Let's assume there's a large length of time when no player has a Marine at Location. Which trigger lags less?

The Sample 2 will actually delete the unit faster, however, it will cause more lag to your map as well, and it's only a fraction of a second faster. Bring takes a bit to update, even if the unit is there.

No, one is not faster than the other. It is better to minimize how often those conditions run, however, so it is better to have the bring condition.

You sure about this? I thought bring has a delay only when it comes detecting dead units. Test map?

And yes, the second one will lag less in theory. But in practice, you can copy that trigger a hundred times and it won't lag, so it doesn't really matter.

Didn't we have a thread some time ago where we found that "bring" fires faster than command?

In terms of game time, they are identical. Everything else is arguing about nanoseconds. Actions lag more than conditions, so NOT running a trigger is better than running one.

"Fire faster" isn't quite the right way to describe it. The definitions for the "Command" condition update less frequently than "Bring". Namely, with "Bring" you don't really need to worry about it, unless you're trying to do binary count offs with units. Whereas with "Command" you can remove all units for all players and in the same loop it'll still register those units in "Command".

If the wiki is wrong, Kaias (or anyone else), please change it. I don't feel like testing (since obviously its been done before).
http://www.staredit.net/wiki/Bring

I don't really have a test for it(no idea how you could), but there is a sort of updating to bring, and so if a unit walked in, I'm unsure if they would fire the same or not, but I do know for certain, that if you Created the unit there, with a trigger directly preceding the other 2, the second trigger would fire first, and the first one would take an extra trigger loop to respond to the unit being there.

Let's just pretend I didn't say anything Especially in light of Falks nice clarification:
Actions listed in Nude's post:

Oh?


Post has been edited 2 time(s), last time on Jan 25 2010, 2:42 am by NudeRaider. Reason: removed ambiguousness

Not correct; the trigger run through begins will all the 'Bring' definitions marked invalid (so to speak), meaning it will be updated upon the bring condition being analyzed. One will be just as fast as the other. The only thing that could change the results for 'Bring' that it won't necessarily recognize are the Create and Give actions, and even then chances are that the definitions will be marked invalid when it gets to it. Not that that matters anyway since I'm pretty sure he is using it only in the context of players walking their units into the location.

AKA Same response time.

Bring also fails to detect the death of a unit every second frame.

Not really true.

When units die they have one frame where they are at 0 health and designated to die. For that frame they are technically still there, have a collision area that can displace, can be detected with bring and can even be given (but cannot be moved). When you kill a unit with triggers, they are set to that 0 health dead-but-not-dead state. Since triggers run every other frame with hyper-triggers, there is essentially a 50% chance that a unit killed (not by triggers) will be in that state when the triggers run.

So the "Kill" action isn't so much a "Kill" action as it is a "Sentence to death" action.

Ahh. This makes sense. I didn't know about the 0 hp mechanics.

Is that not what I said?


While I didn't have all the facts, I wouldn't say I'm incorrect


Yeah, for example, if you had a trigger that killed a science vessel, the trigger directly after it would still detect it as there with Bring, even after being "killed".

Oh, also, Nude, when he first posted his post was blank, and once I posted that he edited it, removing the trigger and it showed up, I've also had the same experience.

EDIT: Rereading Nude's post, it seems pretty unclear to me what he's saying, due to the crossing out and such, I'm pretty sure how it works is Bring runs at the same speed as Always, if the unit walks in, or is moved into the location, however, if it is given from another player already in the location, or created there, then the bring will take an extra trigger loop to respond, unless you also run one of the actions listed in Nude's post after giving or creating the unit there, before the Bring conditions checks.

Post has been edited 1 time(s), last time on Jan 25 2010, 12:13 am by Falkoner.

Kaias is right, the difference is so minuscule it doesn't even matter. This is like nanosecond differences, if even that.

Well, it's actually a 12th of a second difference(8th of an in-game second) if you wanna get precise, but it can make all the difference in a trigger system that relies on StarCraft functioning one way or the other.