I deal with triggered special effects a lot, so here's what I do.
First check to see if the effect needs to play it's Stand animation or its Death animation. It depends on the model and you need to know for it to work properly. Go to the Data editor, and search for it under the Models tab. Search for the model you want. Open up "(Basic) Art: Model" on the right. Click "View In Cutscene Editor".
In the Cutscene Editor, look at the blue bar underneath the red bar on the bottom right area. If it says Stand or Birth or something similar, then you want to let it run its default animation. If it says Death while doing its effect, then you want to run its Death effect.
Death effects are the simplest because you just kill them immediately after creating them. Use the "Create Model At Point" or "Attach Model To Unit" trigger actions, then after that do "Kill Model" on "Last Created Actor". An example:
For the others, however, you need to let them live long enough to play their full animation and then dispose of them. If you neglect to dispose of them, you will have a memory leak that will add up and cause lag over time. So instead of killing the model immediately, I run an Action Definition that creates a new thread of execution and waits a specified amount of time, then kills the model. Here's the code for it:
Important - make sure Create Thread is checked under Options at the top!
Use this immediately after creating the model and it will monitor it then destroy it without interrupting your trigger's current thread of execution because it creates a new one. An example:
I realize that you could probably do this through data.. but I spent the last 7 years learning the trigger system, I don't need another one to get confused about.
The actor system has it's own caveats, if you want to handle actors with triggers like a baus you should learn actor system separately. This functions your using "Create Model", "Create Explosion at Point", "Attach Model to Unit", whatever, are derivatives from basic funtions. To make things clear you should manualy create new scopes and actors and send actor messages to handle them or things become messy very fast. For attaching model there is a actor message "Attach" this should be sent to actor that model will be attached to (if you want to attach model to marine you need to create actor in marine scope or separate scope, make this actor recognizable for marine's actor (set reference) and then send marine actor message like "Attach ::Reference {Center 0}")
Also you can see how i made triggered chain lighting in this map: (Attached)
What i want to say after messing with actor handling in triggers is that it's not so good because: there is no chance to replicate action actors with triggers (in my map chain beams attached to attachment points of model, when the action actor placing impacts on model's hitbox), from my experience "Wait" function in triggers is slower than Persistent Effects in data, and overal it is much more work and typing with triggers than with data for simple spells. (as you can see in my map i need to create all stuff manualy (sounds, site actors, placing everything in right positions, etc), when with data lot of this is automated.
I realize that you could probably do this through data.. but I spent the last 7 years learning the trigger system, I don't need another one to get confused about.
Seeing how StarCraft II Wings of Liberty was only released 4 years ago (July 27, 2010) and the beta lasted at most 1 year (during which most of the time the editor could not be used) it is only possible that you could have been learning the trigger system for at most 5 years. Not the "7" you are claiming.
Warcraft III does not count as JASS and Galaxy are not at all similar. The GUI interface might be similar but the list of differences is pretty massive and the syntax/behaviour of the underlying script is completely different.
Quote:
Will I need to clean this up further?
No, but you might as well not bother running it as chances are the actor will be removed before it even gets displayed.
Quote:
from my experience "Wait" function in triggers is slower than Persistent Effects in data
That would be due to the need to re-schedule the Galaxy virtual machine thread that is waiting probably being quite resource intensive.
The smallest granularity of time for both is still 0.0625 game seconds so both are equally as accurate. This is because the game updates deterministic state 16 times per game second (which may or may not correspond to a real second depending on speed). The only exception I know of are missile movers which calculate their movement 32 times per second (twice per deterministic frame) to give a smoother path.
However actors run in an entirely different system. Actors are not deterministic so can be modified at any time. The results that appear are at however quickly the frames can be drawn (usually 60 fps, sometimes 30 with VS enabled and possibly lower in demanding sessions).
The smallest granularity of time for both is still 0.0625 game seconds so both are equally as accurate. This is because the game updates deterministic state 16 times per game second
They recently made so in data the smallest time gap is 0.03125, probably something that Heroes demands, the new point defence drone work better due to this change.
So, you can also do much more precise missile collision detection with search area effects for spells like Temporal Field.
Well I wasn't referring to the fact that ive been using the sc2 triggers, more the wc3 ones. I would disagree that they aren't similar, because in a lot of ways they are.However, the implementation of local variables, among other things, is certainly game changing.
I see the potential in actors, and certainly there was a lot of waste in the way data was handled as different types in Warcraft 3 instead of all as actors having the same functions available for all objects. An obvious example of this was the heavily restrictive floating text system, which had been heavily improved in sc2.
The explosion effect does certainly work, as the death animation plays when the model is killed.
They recently made so in data the smallest time gap is 0.03125, probably something that Heroes demands
Yet the heroes gates still work with the 0.0625 timing according to another topic. I am also sure it does not demand it. Nothing in the game is that fast (most heroes attack around 1 attack per second with most damage over time being in seconds).
Additionally it would raise the system requirements immensely as it would force double the deterministic frame rate so that it could run those (so they might as well double it for triggers).
Quote:
the new point defence drone work better due to this change
Same result could be achieved by performing an area search around the drone on attack and selecting 2 targets. This alone is not proof that they halved the minimum period.
Quote:
The explosion effect does certainly work, as the death animation plays when the model is killed.
If it has a death animation. If it does not it might be instantly removed depending how the actor you made is setup. It could also leak if you just play the death animation and the actor has no events to destroy on completion. Be very wary of issues of orphaned actors as they are a sort of leak that the game engine cannot detect (most common when using the actor system to handle references and the host actor is removed and the actor has no on orphan destroy self action).
Quote:
Well I wasn't referring to the fact that ive been using the sc2 triggers, more the wc3 ones. I would disagree that they aren't similar, because in a lot of ways they are.However, the implementation of local variables, among other things, is certainly game changing.
Here is just a few ways they are different.
Locals are accessible from GUI.
You can create functions in GUI.
The concept of "usless BJ" calls does not exist as GUI mostly wraps natives when possible.
Arrays have a hard-coded maximum size and throw an error when exceeded unlike in WC3 where they were always dynamic arrays of size 8192.
The real type is a 32bit fixed point type as opposed to in JASS it being a single precision floating point.
Timing precision is no longer sub-frame when using timers. All SC2 timing for triggers in 1/16 of a game second precision.
The concept of reference leaks in SC2 is almost impossible unlike in WC3 where many BJs had them.
Galaxy supports bitwise operators (<< >> ^ & |) to some extent unlike JASS which had no such operators. These can only be used by custom script expresions as GUI in SC2 lacks them.
Galaxy offers limited support for sub-32bit types such as byte.
Many events in SC2 have a finite number of event sockets. Trying to bind more will result in the triggers not working (like how the unit approaches specific unit event in WC3 worked with it breaking all auras on the specific unit).
All angels are in degrees in SC2. WC3 used both degrees and radians in an inconsistent way.
SC2 supports basic C style structs, a concept completely alien to WC3.
WC3 did not have automatic garbage collection for many commonly used types.
SC2 supports basic reference passing (not in GUI?). WC3 had no such concept.
The SC2 AI runs through standard triggers. In WC3 there was a separate JASS virtual machine/interpreter for it. Note many natives required are not available through GUI by default (but can be included easily enough).
SC2 only offers you a limited space for code and globals. In WC3 it was practically unlimited. This means that making massive arrays for everything is not viable in SC2 (the standard way GUI MUI systems were made in WC3).
In SC2 there is no way to bypass point usage efficiently. In WC3 most people avoided locations/points by manipulating cords directly.
There is no "player" type in SC2. Instead players are standard integers with the first human being 1 (instead of 0). In WC3 players outside of 0-15 could crash (but might not depending where they pointed to if it was a valid page).
Many natives operate differently in SC2. Some have very strict argument conditions and will error returning a default value rather than attempt to do something if the arguments are not correct.
Many natives in SC2 rely on good understanding of the data editor to use properly (most unit natives, catalogs etc). In WC3 the trigger editor hardly related to the object editor in any way.
The syntax of Galaxy and JASS is completely different. JASS (2) was based on the language for StarCraft 1 (JASS 1) where as Galaxy is some safe subset of standard C.
SC2 only offers you a limited space for code and globals. In WC3 it was practically unlimited. This means that making massive arrays for everything is not viable in SC2 (the standard way GUI MUI systems were made in WC3).
This space was expanded a couple patches ago. It is now effectively unlimited (I think we reasoned it out that you have now 2^24 memory addresses for globals). This was mostly detected because those using the trigger debugger saw the memory/code % drop to nothing, I now almost never see over 2% usage for either.
I'm still quite new to the whole actor idea..
How would I attach an explosion to a unit when it takes damage etc...
Do you need to clean this up like you did in Warcraft 3?
This is what I'm currently trying.
Thanks
I deal with triggered special effects a lot, so here's what I do.
First check to see if the effect needs to play it's Stand animation or its Death animation. It depends on the model and you need to know for it to work properly. Go to the Data editor, and search for it under the Models tab. Search for the model you want. Open up "(Basic) Art: Model" on the right. Click "View In Cutscene Editor".
In the Cutscene Editor, look at the blue bar underneath the red bar on the bottom right area. If it says Stand or Birth or something similar, then you want to let it run its default animation. If it says Death while doing its effect, then you want to run its Death effect.
Death effects are the simplest because you just kill them immediately after creating them. Use the "Create Model At Point" or "Attach Model To Unit" trigger actions, then after that do "Kill Model" on "Last Created Actor". An example:
For the others, however, you need to let them live long enough to play their full animation and then dispose of them. If you neglect to dispose of them, you will have a memory leak that will add up and cause lag over time. So instead of killing the model immediately, I run an Action Definition that creates a new thread of execution and waits a specified amount of time, then kills the model. Here's the code for it:
Important - make sure Create Thread is checked under Options at the top!
Use this immediately after creating the model and it will monitor it then destroy it without interrupting your trigger's current thread of execution because it creates a new one. An example:
The Cutscene Editor can help you see how long it takes for the animation to finish, so set the timer longer than that.
When you use "Attach Model To Unit" instead, I typically use the attachment points "Center", "Origin", and "Overhead".
Hope this helps.
It should not need triggers and be entirely possible with the data editor.
I realize that you could probably do this through data.. but I spent the last 7 years learning the trigger system, I don't need another one to get confused about.
I'm going to go ahead and go with
Will I need to clean this up further?
Thanks
The actor system has it's own caveats, if you want to handle actors with triggers like a baus you should learn actor system separately. This functions your using "Create Model", "Create Explosion at Point", "Attach Model to Unit", whatever, are derivatives from basic funtions. To make things clear you should manualy create new scopes and actors and send actor messages to handle them or things become messy very fast. For attaching model there is a actor message "Attach" this should be sent to actor that model will be attached to (if you want to attach model to marine you need to create actor in marine scope or separate scope, make this actor recognizable for marine's actor (set reference) and then send marine actor message like "Attach ::Reference {Center 0}")
Here i explained a bit about creating actors with triggers and added map with comments. Ofcourse this is not enought to understand actor system, but you will get a clue how this built-in function "Create Explosion at Point" works: http://www.sc2mapster.com/forums/development/galaxy-scripting-and-trigger-lib/67396-actor-send-spoof-source/#p6
Also you can see how i made triggered chain lighting in this map: (Attached)
What i want to say after messing with actor handling in triggers is that it's not so good because: there is no chance to replicate action actors with triggers (in my map chain beams attached to attachment points of model, when the action actor placing impacts on model's hitbox), from my experience "Wait" function in triggers is slower than Persistent Effects in data, and overal it is much more work and typing with triggers than with data for simple spells. (as you can see in my map i need to create all stuff manualy (sounds, site actors, placing everything in right positions, etc), when with data lot of this is automated.
Seeing how StarCraft II Wings of Liberty was only released 4 years ago (July 27, 2010) and the beta lasted at most 1 year (during which most of the time the editor could not be used) it is only possible that you could have been learning the trigger system for at most 5 years. Not the "7" you are claiming.
Warcraft III does not count as JASS and Galaxy are not at all similar. The GUI interface might be similar but the list of differences is pretty massive and the syntax/behaviour of the underlying script is completely different.
No, but you might as well not bother running it as chances are the actor will be removed before it even gets displayed.
That would be due to the need to re-schedule the Galaxy virtual machine thread that is waiting probably being quite resource intensive.
The smallest granularity of time for both is still 0.0625 game seconds so both are equally as accurate. This is because the game updates deterministic state 16 times per game second (which may or may not correspond to a real second depending on speed). The only exception I know of are missile movers which calculate their movement 32 times per second (twice per deterministic frame) to give a smoother path.
However actors run in an entirely different system. Actors are not deterministic so can be modified at any time. The results that appear are at however quickly the frames can be drawn (usually 60 fps, sometimes 30 with VS enabled and possibly lower in demanding sessions).
They recently made so in data the smallest time gap is 0.03125, probably something that Heroes demands, the new point defence drone work better due to this change. So, you can also do much more precise missile collision detection with search area effects for spells like Temporal Field.
Well I wasn't referring to the fact that ive been using the sc2 triggers, more the wc3 ones. I would disagree that they aren't similar, because in a lot of ways they are.However, the implementation of local variables, among other things, is certainly game changing.
I see the potential in actors, and certainly there was a lot of waste in the way data was handled as different types in Warcraft 3 instead of all as actors having the same functions available for all objects. An obvious example of this was the heavily restrictive floating text system, which had been heavily improved in sc2.
The explosion effect does certainly work, as the death animation plays when the model is killed.
Yet the heroes gates still work with the 0.0625 timing according to another topic. I am also sure it does not demand it. Nothing in the game is that fast (most heroes attack around 1 attack per second with most damage over time being in seconds).
Additionally it would raise the system requirements immensely as it would force double the deterministic frame rate so that it could run those (so they might as well double it for triggers).
Same result could be achieved by performing an area search around the drone on attack and selecting 2 targets. This alone is not proof that they halved the minimum period.
If it has a death animation. If it does not it might be instantly removed depending how the actor you made is setup. It could also leak if you just play the death animation and the actor has no events to destroy on completion. Be very wary of issues of orphaned actors as they are a sort of leak that the game engine cannot detect (most common when using the actor system to handle references and the host actor is removed and the actor has no on orphan destroy self action).
Here is just a few ways they are different.
@ImperialGood: Go
Thanks for that list, I didn't realize how much they have improved.
This space was expanded a couple patches ago. It is now effectively unlimited (I think we reasoned it out that you have now 2^24 memory addresses for globals). This was mostly detected because those using the trigger debugger saw the memory/code % drop to nothing, I now almost never see over 2% usage for either.
Thanks again, I finally came back and used the second part, making an action definition.
Goes to show how little I know about galaxy, and by making functions with action definitions the possibilities seem endless.