FUNCTIONS
If you've used Staredit's trigger system for a while (especially for large projects) and also know some other basic programming language, you know that Blizzard's user-friendly design is a b-tch to deal with. One useful thing about programming languages is the ability to create functions. For example:
void print_blah()
{
printf("Blah Blah Blah and more Blah\n");
}
This simple C function (which is really redundant, but for the sake of example =) prints the line "Blah Blah Blah and more Blah". The utility of functions is that you can "call" them anytime during a program to carry out the actions within. For example, whenever I input print_blah in a line of my program, it will output the line "Blah Blah Blah and more Blah." This saves you from having to write out the entire function each time you want to carry it out.
Now to the point. Wouldn't it be nice to be able to do that in Staredit? For example, let's say you have a lot of triggers that have sections of actions that are identical. Instead of having to re-input the actions over and over again in each trigger, it would be simpler to have a single user-defined action that would carry out all of them. Well, it is possible, and really pretty simple to understand (albeit functioning with a couple exceptions that will be explained later).
Here is a sample trigger "function":
Owner:
Player 1
Conditions:
- 'print_blah' is set.
- 'function running' is
clear.
Actions:
- Set 'function running'.
- Display Text message: 'Blah Blah Blah and more Blah'.
- Clear 'print_blah'.
- Clear 'function running'.
- Preserve trigger.
To call this function in another trigger, you just need the action: Set 'print_blah'. Whenever you set that switch, the trigger above will initiate because its conditions will be met. You can use this to perform much more elaborate trigger actions just by inserting your specified actions in the place of the "Display Text" action in the trigger above. For each function, you only need another switch that will call it. The 'function running' switch is important because it will prevent the function from running over itself (i.e., running more than once for each call).
Now, here are the things you have to understand about this method ("exceptions"). First, calling the function may take up to 2 seconds to carry out because Starcraft only checks triggers every two seconds. You should be aware of that if timing is important. There really is no way to get around it.
Second, unlike in C, when you call a function in Staredit, the trigger calling it will not stop and wait for the function to be complete until it moves on. It will run the function while it runs-out the rest of the actions in the trigger (just like running 2 triggers at the same time). There is a little way to get around it, but it requires one more trigger. For example, let's say I want it to carryout the print_blah funtion above, but want to wait until the message is displayed before moving on to another action in the main trigger sequence. Here is the main trigger sequence:
Owners:
Player 1
Conditions:
- [what ever]
Actions:
- Set 'print_blah'.
- Set 'move on'
Owners:
Player 1
Conditions:
- 'move on' is set.
- 'print_blah' is clear.
Actions:
- [what ever]
The first trigger runs the function print_blah (obviously, in reality you'd have it do other stuff too =) and then tells the second trigger it can start (by setting 'move on'; you can substitute Custom Scores or other actions to keep track of when to "move on"). However, the second trigger will not start until 'print_blah' is clear -- looking back at the original function above will show you that this occurs when the function is complete. Thus, the second trigger will start after the first, but wait until the function is carried out before beginning.
Another thing you want to be careful about when using this function method is if you have blocking actions (wait, transmission, or center view) in either the function trigger or in other triggers running simultaneously with the function. Blocking actions will delay all other blocking actions in any trigger for that player. A way to get around this is to have the trigger with the blocking action run for another player (i.e., an unused computer or neutral player -- by unused, I mean with no other triggers containing blocking actions). That way, the blocking action will not interfere with actions for the current player. Obviously that is not applicable in the case that the trigger containing the blocking action also contains owner-specific actions such as display text or transmission. You can actually use functions to get around this. For example:
Owner:
Player 2 [unused
neutral/rescuable/computer]
Conditions:
- 'wait_10sec' is set.
- 'function running' is
clear.
Actions:
- Set 'function running'.
- Wait for 10000
milliseconds.
- Clear 'wait_10sec'.
- Clear 'function running'.
- Preserve trigger.
Call this function whenever you want to wait 10 seconds but don't want to obstruct other actions for Player 1 (the current player). One additional thing you want to note here is that if you use a universal 'function running' switch for all your function triggers, no two functions will be able to run at the same time (since each will have to wait until 'function running' is clear before it begins). If you want to allow some functions to run simultaneously, you just need to give them their own 'function running' switch (that is not shared).
Now, what is the point of all this? Well, for the average 50-trigger map, there isn't much use. It'd probably be simpler to avoid this method just so you don't confuse yourself. However, for more trigger intensive maps, this method can be a vital aspect in an otherwise very disorderly trigger list. First, this will save you a lot of trigger work if you plan it correctly, and second, it will be a life-saver for times when you otherwise would have run into things like the string limit. For example, let's say you have 10 triggers that display the same text message, but for different reasons. If you used a function to call that text message each time, not only will you save time by not having to type in the message 10 times, you will use only 1 string instead of 10 (a string is any custom text that is input into a map). There are about 1024 strings allowed in each map, but if you think about it, that is not really that many. Renaming all the units already gives you upwards of 250, location names take can take up over 200, naming switches uses strings, all "comment" actions are strings, even wav file names take up string space, and that still leaves you with all the display text and transmission actions. Just as conserving locations was important in the days of good-old-64, conserving strings is important in today's trigger (and text) intensive maps.
Phew, that was a long article. =) To be honest, I have only used this method sparingly and it does take some practice to be able to determine exactly when it is a good idea to use it and when not to. But if you're longing for some C instead of Blizzard's clunky trigger system, here's a way to start. [You theoretically could also integrate Score variables into this method to serve as arguments to each function -- but that's probably going overboard.] =)
DI
May 15, 1999
