This thread exists for the sole purpose of answering questions that are too complex for a single sentence answer yet specific enough not to warrant a full blown tutorial. If you have questions that you can't find the answers to, this is a good place to ask them.
Your question should be something specific like "How do I make a mana shield?" or "How do I make units spawn on a timer?" Questions that can be answered with a short tutorial you complete in 5-10mins. Vague questions like "How do movers/morphs/dialogs" work will be directed to the Tutorial Section
IMPORTANT:Be sure to let us know what method you would prefer such as Data vs Triggers.
I've got an air unit using a modified Reaper weapon, the stats and everything work properly, but the weapon's origin point is way down on the "ground" about 5 height units below my unit. From what I understand this is a common problem, how does one adjust the missile point of origin?
One more "simple" question... when I use the "Ping the Map at XXX" via triggers it doesn't let me press spacebar to be taken to that location instantly, like what happens when other alerts happen in-game (such as a unit being trained, construction complete, etc). Is there an easy way to do this?
Hello, i have what i hope is a simple Data Question. I have created a Buff that when applied to a unit has a Damage Response effect. there are also charge counts for the damage response effect. my question is as follows: How can i cause the Buffs Damage Response Charge Count to show on a Passive Button on the command card? for more reference this behavior restores its charge count over time. thank you for you time.
I've noticed a lot of posts in the Triggers section about persistent unit movement (like those related to physics systems.) I'm not going to go into a physics system because it's too advanced for a mini-tutorial and, frankly, there's already a tutorial about that. This will be a basic introduction into such a system at best. You will be instructed on how to create an "ice rink" which causes units that step onto it to be propelled in the direction that they are moving until they reach the other side. Completion of this tutorial should provide you with a basic understanding of the following concepts:
Regions: How to place a region to act as a "skating rink" and how to reference that region with triggers.
Triggers: Basic triggering skills including the use of loops for moving a unit and action definitions.
Implementation: Making your triggers work for multiple players and units.
Step 1 is, of course, to create a new map. For the purposes of this tutorial it doesn't matter what your map looks like so just pick any settings you are comfortable with as long as you are creating a MAP, not a MOD. I recommend keeping it on the smaller side (less than 128x128) to reduce loading times.
Once your map is loaded in the editor, open up the terrain editor and apply texture to a square patch of ground to distinguish it from the surrounding terrain. This will be your "ice rink."
Open up the region editor and place a region completely over your ice rink. Press ESC to get out of placement mode, then double-click on the region you just created and rename it to "Ice Rink".
In the unit editor, place a Terran Marine on your map for player 1. Put it somewhere outside of the ice rink.
At this stage, you should have created a patch of texture on the ground in the shape of a square which appears different from the surrounding texture. You should have placed a region over said patch and renamed it to "Ice Rink". Finally, you should have placed a marine for player 1 somewhere outside of the "Ice Rink".
Before we dive straight into trigger creation I'd like to go over some concepts that will aid you in your understanding of what's going on:
I understand that not everyone approaching the trigger editor is a programmer. Heck, I'm not a programmer. But having a basic understanding of certain programming concepts will give you a huge advantage in making SC2 maps. One of these concepts is called a loop.
A loop is basically a big circle that the computer processes through. Loops are incredibly useful because they can save you a lot of time when you are writing triggers. An infinite loop looks something like this:
Once this loop is activated, the game will continuously repeat the message "I'm loopy!" after every second of game-time that passes. Generally you want to avoid using infinite loops unless you put them in their own separate threads - something I will discuss soon. Often, however, you will want to restrict your loops to certain conditions. The Galaxy Editor provides several useful actions that help you accomplish this:
For/Pick Each Integer: If you want to make the game count sequentially from 1 to 10, you could use this:
General-Pickeachintegerfrom1to10,anddo(Actions)ActionsUI-Display(Combine("There are ",(Text((Pickedinteger)))," Zerglings in the pot!"))for(Allplayers)toSubtitleareaGeneral-Wait1.0GameTimesecondsOncethegamereaches10itwillstop.Ifyouwanttouseavariableinsteadof"picked integer"youcanusetheForEachIntegeraction.
For/Pick Each Player: Same as For/Pick Each Integer except that it uses players from a player group
Repeat X Times: Repeats the loop for the number of times specified
While Loop: Repeats the loop so long as the prescribed conditions are met
Each trigger in Starcraft 2 runs in its own "thread." The best way to describe threads is to think of a length of string which is comprised of many tiny threads. All of your triggers together represent the string, with each individual trigger being a thread. At any given point on the string you have many threads gathered together - just like at any given point in your game you can have many different triggers firing at once.
Why is this important? Well, sometimes you want to have a loop that goes on for a very long time and you don't want it to interrupt the rest of a trigger. When this happens, the best solution (usually) is to put that loop in its own thread. This will allow the game to continue processing the trigger that activated the loop while the loop is actually happening. In essence, you are allowing SC2 to multi-task.
To put a loop into its own thread, you need to make use of Action Definitions.
Action Definitions are another useful tool for saving time while writing triggers. They allow you to define certain parameters which can affect the actions they contain. They also have a lot of options that you can manipulate to change how the AD works. I won't go into these options in this tutorial - the most important one for us is the "Create Thread" option. If you've read the last part of this tutorial, what this option does should be obvious.
To put it simply, an Action Definition is a collection of actions (big surprise, I know.)
Alright, now let's begin making some triggers.
Open up the trigger editor. First things first, delete the Melee Initialization trigger. It will only get in the way.
Create an Action Definition and call it "Slide Movement."
Under options, check "Create Thread."
Add three parameters:
Slider = No Unit <Unit>
Direction = 0.0 <Real>
Speed = 0.0 <Real>
Under actions, create a While Loop.
Under the conditions for the While Loop, add "Unit In Region," setting Unit to the parameter Slider you created and the region to Ice Rink. Set the right hand side of the equation to True.
Under the actions for the While Loop, add a Move Unit (instantly) action. Set the unit to Slider, the point to Point with Polar Offset (using Position of (Slider), offset by (Speed / 10) toward Direction,) Blend.
Still under the actions for the While Loop, add "Wait 0.05 game-time seconds".
Create a new event using event type Unit Enters Region, setting the unit to Any Unit and the region to "Ice Rink", which you created at the beginning of the tutorial.
Under actions, add an Issue Order function. We need to tell the marine to Stop when he hits the ice or the game's AI will cause problems. Your function should read "Unit - Order (Triggering unit) to ( Stop) (Replace Existing Orders)."
Create a new action and look under the General assortment. You should see Slide Movement. Select this and click on OK.
Set the parameters to the following:
Slider: (triggering unit)
Direction: (facing angle of (triggering unit)) #This uses the Facing of Unit function#
Speed: (Triggering unit) Movement Speed (current) #This uses the Unit Property function#
Create a new action after Slide Movement which displays a message to the player. Something like "OH NOOOOOO!" might be appropriate. I also recommend playing the marine's death sound for extra fun.
It is important to note that these fields reference Actors and NOT Models. Thus if you use these fields you must pick Actors that create Models. A Site Operation Actor wouldn't work in these fields despite being allowed to pick them.
Launch Assets +, Impact Map + and Damage Map + skip Actors and use Models directly. They require less work but restrict customization.
Art - Beam:
Links the Beam Actor that will be created for the Action Actor.
Example: Colossus beams.
Art - Container Model:
Links the Model Actor that will be used in the place of Launch Assets + when the Unit that creates it is garrisoned.
Example: firing from a Bunker.
Art - Impact Model:
Links the Model Actor that will be used in the place of Impact Map +.
Example: explosion from impact.
Art - Impact Model Reaction:
Links a Model Actor that will be created in addition to the Impact Model or Impact Map +. This is only created if the target reacts to the attacker. Thus this usually only shows up when attacking enemy players while not showing up when attacking yourself or allies.
Example: adding effects when attacking enemies without requiring a Switch or Validator.
Art - Launch Model:
Links the Model Actor that will be used in the place of Launch Assets +.
Example: muzzle flash on a Marine's weapon.
Art - Missile:
Links the Missile Actor that will be created for the Action Actor.
Example: Marauder missiles.
Art - Shield Flash Type:
Determines how the target's shields will respond.
Facer: triggers shield ripples facing the attacker. Header: triggers shield ripples facing the attacker and angled upwards. Full: triggers full sphere shield ripples. None: doesn't trigger shield ripples.
Art - Shield Ripple Scale Factor:
Determines the magnitude of shield ripples.
Combat - Damage Model:
Links the Model Actor that will be used in the place of Damage Map +.
Example: blood splats from splash damage.
Combat - Damage Model Reaction:
Links a Model Actor that will be created in addition to the Damage Model or Damage Map +. This is only created if the target reacts to the attacker. Thus this usually only shows up when attacking enemy players while not showing up when attacking yourself or allies.
Example: adding effects for splash damage to enemies without requiring a Switch or Validator.
Art - Model: the Model shown when not overridden by the exceptions below.
Art - Model (Build): the Model shown while under construction
Art - Model (Editor): the Model shown after being placed in the editor.
Art - Model (Placement): the Model shown when being placed in the editor and in-game.
Art - Model (Portrait): the Model shown in the portrait window.
Combat - Death Actor Model: the Model used for death.
This is most commonly caused by a problem in the Art - Missile field. Specifically, the custom radial button is selected instead of the actor radial button.
Actor Radial Button:
This is the one you want to use. Find the appropriate Missile Actor on the list and this "should" correct the issue.
Alias Radial Button:
I don't recommend using this. Aliases are typically used to select a range of data objects as in the case of _Missile or _Unit. Great for various types of attachments. Not so great for selecting the Missile Actor.
System Radial Button:
I don't recommend using this either. Most of the values on the list will cause problems as the product derived from whatever value you choose is highly likely to pick an Actor that isn't compatible.
Reference Radial Button:
Another option you should avoid. As with the previous two, this looks for an Actor by reference based on the chosen value rather than using a specific Actor.
Custom Radial Button:
I honestly couldn't tell you what this does. If you're using this, chances are your Action Actor is broken.
The Token Fields at the top of the list on the right allow you to quickly link Effects to their respective Events. They use Bogus Effects as default values that you replace with your desired Effects. Think of them as "Cause and Effect" values.
You will usually only use the Attack Token or the Launch Token and Impact Token. You should never "need" to use all three together.
"Effect without a Cause"
The Effect that triggers the Impact Model or Impact Map + in one-step Effect-Chains.
Example: Marine's Effect - Damage from weapon.
"Cause and Effect"
The Effect that triggers the Launch Model or Launch Assets + at the beginning of an Effect-Chain segment.
Example: Marauder's Effect - Launch Missile from weapon launch.
Example: Mutalisk's Effect - Launch Missile at each weapon bounce.
"Cause and Effect"
The Effect that triggers the Impact Model or Impact Map + at the end of an Effect-Chain segment.
Example: Marauder's Effect - Damage from weapon impact.
Example: Mutalisk's Effect - Damage at each weapon bounce.
The names refer to the order they appear on the list.
1st Default (Impact) Effect:
Effect.Bogus.Start - At Caster | From Effect Tree Descendant - Action Impact
Creates the Impact Model or Impact Map +. Bogus is replaced with the Impact Token's value.
2nd/3rd Default (Splash) Effects:
Effect.SplashDamage.Start - At Caster | From Effect Tree Descendant - Action DamageEffect.SplashDamage.Start - At Source | From Effect Tree Descendant - Action Damage
Creates the Damage Model or Damage Map +. This is only used if the Effect - Damage from the Attack Token or Impact Token has splash built into it.
4th Default (Attack) Effect:
Effect.Bogus.Start - At Caster - Create
Creates the Impact Model or Impact Map +. Bogus is replaced with the Attack Token's value.
5th Default (Launch) Effect:
Effect.Bogus.Start - At Caster - Create
Creates the Launch Model or Launch Assets +. Bogus is replaced with the Launch Token's value.
Line + in a Function Validator opens up a window that allows you to create a system of Validators that function similar to if-then-else. This system allows you to dynamically change how the Function Validator reacts based upon which Validator in the list passes first. These are currently being used by the Tactical AI Data tab in determining how the AI plays.
It is important to understand how Validators are considered "passed." A Validator can enable or disable Find. When disabled, if the target doesn't meet the conditions, it is considered passed. Thus if you were looking for a specific unit and it didn't find it, the Validator would allow whatever you validated to happen. When enabled, the opposite is true. If the target doesn't meet the conditions, the Validator disallows whatever you validated from happening.
Determines the order in which lines of Validators are checked. Standard top to bottom.
Stops the Function Validator once a line with this is enabled. Useful for testing long lists.
If the listed Validator passes (finds what it's looking for, failure or success) the Function Validator returns failure. All following lines are ignored.
If the listed Validator passes (finds what it's looking for, failure or success) the Function Validator returns ignored. This is similar to returning failure, but does not display the error messages associated with failure. All following lines are ignored.
The Function Validator returns whatever the listed Validator returns (failure or success). All following lines are ignored.
This is typically used with Test as a way to replace the Function Validator under certain conditions.
If the listed Validator passes (finds what it's looking for, failure or success) the Function Validator returns success. All following lines are ignored.
If the listed Validator does not pass (finds what it's looking for, failure or success) the Validator in the same line (Failure/Return/Success) is skipped.
This allows you to check for a specific "something" on whatever is being validated. This can be used to put multiple units in the same list by using Test to check for each unit or even to make the validated target have a different list for variable "somethings."