Just started touching the SC2 editor, and learning how it does triggers.

I just don't see yet why they added events, which just seem like conditions to me. What's the reason for this? Is there something I can do with events that I be able to with conditions?

It's already got me worried about optimization, because in staredit, I would set certain unlikely conditions first so the map wouldn't cycle through all of them. But with things like like "Event: any unit dies" and then checking that unit in a condition has got me all weirded out.

Events are great for two things, as far as I know:
# efficiency :: no triggers in sc2 are executed for no reason. Every trigger gets fired by an event. If you want to simulate a SC1-Trigger, your best choice is to use "periodic event" as an event for a trigger.

# flexibility :: in sc1, if you had a condition like "brings 1 dragoon to REGION" there is no way -in the action- to manipulate that exact unit/dragoon.

My one issue with the "flexibility" aspect is that unlike SC1, SC2 requires you to determine exact units rather than generally letting you determine units. At least as far as I can tell. For example, I can't make a trigger that says any time a marine enters a region, do something. I'd have to either have a specific marine or create a unit group that the marine is a part of. Unless, of course, I've been doing those types of triggers incorrectly this whole time.

Overall I like Events a lot, and though I was worried about the "any unit dies" thing as well, I haven't noticed any lag or slow registration of the triggers when I have 50 units die almost simultaneously.

For Devlin's example:
Any Marine enters Region1, kill it in SC2 is:

Event: Any Unit enters Region1
Condition: Unit Type of Triggering Unit == Marine
Action: Kill Triggering Unit.

EDIT: If you want like Brings at least 5 Marines to Region1, go for this:
Event: Any Unit enters Region1
Condition: Number of Units in Unitgroup(Marine units in (Region1) owned by Player Any Player matching (...)) >= 5
Actions: (...)

Wouldn't the "Unit group" have to be set prior, though? As opposed to any 5 marines on the map, that is. That's what I always got hung up on.

If I get you correctly, no.

Well I don't know Devourer. I just tried recreating what you just wrote there. I can't becuase I didn't already create a "marine" unit group.

So how do you do this? (assuming you mean any marine in general, and not a specific preplaced one on the map.)

Like, I litteraly see now where under function (which I assume it has to be) to pick "marine" or anything generic like that

The unit group is calculated each time the trigger runs (like a local variable), as opposed to a global variable that you maintain the state of. Each time the event fires, it grabs all marines in Region1 and checks that there are at least 5 in the condition.

The reason it's not "any marines on the map" is because the Unit Group function takes in a region, and you can be generic and say "Entire Map" or you can specify a particular region like Devourer has. Though you can be even more neat and say "Triggering Region" if you wanted as well.

Events are logical ORs, meaning if any event occurs, the trigger will be evaluated. Conditions are logical ANDs (like they are in SC1) by default, though you can also nest some or all of them in an "Or" statement to work that way. But like Devourer says, the reason events exist is for efficiency: instead of the map checking every X milliseconds if a unit on the map has died, there is an event that a unit fires as part of their death, which will activate any triggers that listen for that event. In computer science, SC1 has a polling system while SC2 has a pushing or event-driven system, and generally the latter is favored because it can be heavily optimized by the language or framework you're using.

For the unit type, instead of using a function, switch to the "Value" radio button and find the Marine value.

Ok so I see some conditions/actions have this very useful "unit type" option where it pops up something very different from the typical fucntions/presets/value/etc.

So yes I can do whatever I want when I get this "game link/unit type" box to pop up. But why does it seem to be so rare! Like, I'm making a Send Transmission action, and where I put in what I want in the portrait, I only get to pick preplaced units because I don't get the unit type pop up. Send Transmission(advanced) donesn't even give me the option, but for some reason the (simple) option does.

I must be missing something here, because I know whoever made this is way smarter than me, and I would ALWAYS have that be an option in a drop down or what not.

When doing an action on units, you have to affect specific units. If you want to affect all units of a specific type, then do a "Pick Each Unit In Unit Group," and make the Unit Group be all units of a specific type. Then inside that loop you can refer to each individual unit by using the "Picked Unit" function variable.

In the case of a transmission, you can in fact pick a unit type without doing something like the above. For the "Source" argument, you can select the "Unit Type Transmission Source" function and then pick a unit type value like "Marine."

ahhhh, I feel like I can see now!

I guess the trick is to click the "(" when stuck. Thanks!

Oh yeah, that got me too for a while; the opening brace is really the start of a function, so you'll have to get used to clicking those if you want to change what type of function you're using. Alternatively, you can look at the panel above the verbalization, which isn't as descriptive but will in fact show every function and value supplied to the action.

We feel spoiled because we've been using conditions as events in sc1. Events aren't necessary, but a lot of things we do in programming aren't really necessary, they just make things easier and improve organization. Which is every reason to use them.

As a general rule of thumb, use events to determine when and what of occurrences, and use conditions to determine what will then occur.

I guess you can also compare events to requirements (for the trigger to be called) and conditions to actual conditions.

Yeah, for people who were heavily experienced with SC mapping, SC2 is a bit of a mind fuck. If you ever get stuck, it's generally not about creating more actions or conditions, the answer probably lies within existing fields... The exact opposite of the method you are used to using for problem solving.

Indeed, it's working different than in SC1. There it was periodically checking all conditions and in sc2 that behavior would be equal to one periodic trigger having all conditions build into a big list of IF-THENs.

In SC2, events are very generic and should be generic most of the time. They only start a trigger and give you a few parameters ("Triggering ...") to check the conditions you need.

If you would want to optimize your map, you would just use one trigger for each event. But for the sake of modularity, it's often easier to use multiple ones, so you can easily disable the trigger later on. So, this is just for you to keep in mind in case you want to start huge projects.

Each event starts a thread. Threads in SC2 are different from the ones you may know in programming because in SC2, they are no real threads. They are executed in a determined order:
1. older, already existing threads
2. new threads in order how they appear in the trigger code

There is no race condition in SC2 as the thread order is linear.

A nice piece of info here is, that a wait duration of "0.0" will only push the trigger to the end of the trigger execution list, so it will be executed after all other running threads. If you want to ensure some actions are executed after all triggers, put a wait(0.0) before those actions. Btw, the wait(0.0) only works once per game frame, so a second wait(0.0) in a thread will make it continue running in the next game frame update. SC2 runs with 16 game frame updates (where everything is updated, weapon firing, damage, etc) per game second.

Action definitions can start threads, too, if you've enabled the "Thread" option within them.

I'm not sure I understand this. Creating a thread generates lag, no? So if you could cram as many triggers inside a single thread you would reduce lag?

Every firing of an event creates a thread. If you have duplicated events in your code, it will always generate a thread for each of them.

Creating a thread obviously requires some work for your CPU even if that amount of work is very small. That's why the optimal solution is to reduce the amount of duplicated events and that's what you are doing when you just use one trigger for an event instead of having 10 triggers with the same event. Instead of creating 10 threads, it will just create one.
Then you would check which case you are dealing with in your triggers.

Also, there is a limit of 1024 threads. So, for example, if you have 100 triggers with a "Unit dies" event and in each one of them you filter for a specific unit type (Zergling, Marine, Ultralisk, ....), having 12 units die at the same time will cause the game to bug as it will try to have more than 1024 threads.

Oh, my bad. I was understanding "trigger" as "action".