" General - If (Conditions) then do (Actions) else do (Actions) If Or Conditions (Triggering order) == (((Move, 0)) targeting P_UnitPoint) (Triggering order) == (((Move, 1)) targeting P_UnitPoint) (Triggering order) == (((Move, 3)) targeting P_UnitPoint) Then Variable - Set P_InitialOrder = (Triggering order) Else "
Then does that set P_IntialOrder with the Target Point as well?
No idea, but I do know it will not do anything like you want it to do. All the order tests will evaluate false as no 2 differently created orders are ever equal (they are compared by reference only). If you want to test what an order is about you need to break it down into the Ability Command and the resulting arguments as both of those can be compared using comparisons.
I'd also rather not have 3-4 different Events in the Events section...
If you can get away with only 4 events then it is a lot more efficient than using the generic solution provided by 2.
Quote:
2. Ya lost me. No clue what you're talking about by "Add a condition to Any Ability Command Preset"
Which is why I gave an example of what I meant in the form of GUI. You did see it right?
Quote:
Basically, I'm converting this into SC2:
As far as I can tell that is a formation system where you keep units in relative formation. Doing something like that should be reasonably simple. When a point order is issued you abort it and re-issue it for each unit based on the order position and their position relative to the group centre. It would even work with shift since you only modify the top order.
One more, in WC3 there is an event that goes "A unit is issued an order targeting a point" How would I do that in SC2?
You use this...
Unit-AnyUnitisissuedanordertoAbilityCommand
There is no longer an event directly like that, instead you have two options.
If you only are expecting a specific command to be ordered, then choose that specific command. This is far more efficient than anything possible in WC3 as it will only fire the trigger if that command is issued.
If you want a generic point order then add a condition to the "Any Ability Command" pre-set for the event ability command. You then add a condition to check the order was a point order. This is less efficient but will work for any point order.
Also, I don't I need to use Arrays for all my variables, do I?
You should only use arrays when you need to dynamically get an index. Array lookups are always slower than static lookups due to the extra argument involved. The Galaxy Virtual Machine may or may not be smart enough to optimize out static index array lookups like C/Cplusplus or Java compilers can.
Unlike JASS, Galaxy fully compiles into byte code so no dynamic name lookup occurs at run time. As such declaring locals should be a lot cheaper time wise in SC2 than they were in WC3.
Quote:
I can just use Local Variables and it'll be MUI?
"MUI" is a very loose term. It practically does not exist in SC2 since the data system handles most of the complex persistent parts of abilities with triggers only being used for complicated logical effects. That said you could do many conventional WC3 style trigger enhanced abilities using locals for storage thanks to the perfect timing accuracy of the defer executing native "Wait". Do be aware that a hard-coded thread limit does exist so you would want to avoid generating threads for trivial tasks (such as each unit hit by an AoE spell getting its own trigger thread).
Quote:
Do I have to manually clean up points and unit groups like in WC3 or are those automatically cleaned up?
The Galaxy virtual machine will automatically garbage collector those types once all references to them are lost. In fact there are no destructor natives for garbage collected types so you have to rely on the mechanic. There is also no "local handle reference counter error" in Galaxy like there was in JASS so there is no need to null any locals at the end of functions. Do note that a minor leak can still occur if you assign a reference to a complex type to a variable that is never accessed again as the object will persist until end of session however this is small and bounded so can be ignored.
Below is a list of types which the Galaxy Virtual Machine will automatically garbage collect once there are no references to them. It is taken from the natives declaration file and written by Blizzard.
// Many native types represent "complex" objects (i.e. larger than 4 bytes). The script language// automatically keeps track of these objects and deletes them from memory when they are no longer// used (that is, when nothing in the script references them any longer). The types which benefit// from automatic deletion are://// abilcmd, bank, camerainfo, marker, order, playergroup, point,// region, soundlink, string, text, timer, transmissionsource, unitfilter, unitgroup, unitref,// waveinfo, wavetarget
No idea, but I do know it will not do anything like you want it to do. All the order tests will evaluate false as no 2 differently created orders are ever equal (they are compared by reference only). If you want to test what an order is about you need to break it down into the Ability Command and the resulting arguments as both of those can be compared using comparisons.
If you can get away with only 4 events then it is a lot more efficient than using the generic solution provided by 2.
Which is why I gave an example of what I meant in the form of GUI. You did see it right?
As far as I can tell that is a formation system where you keep units in relative formation. Doing something like that should be reasonably simple. When a point order is issued you abort it and re-issue it for each unit based on the order position and their position relative to the group centre. It would even work with shift since you only modify the top order.
You use this...
There is no longer an event directly like that, instead you have two options.
Below is an example of how to do two.
You should only use arrays when you need to dynamically get an index. Array lookups are always slower than static lookups due to the extra argument involved. The Galaxy Virtual Machine may or may not be smart enough to optimize out static index array lookups like C/Cplusplus or Java compilers can.
Unlike JASS, Galaxy fully compiles into byte code so no dynamic name lookup occurs at run time. As such declaring locals should be a lot cheaper time wise in SC2 than they were in WC3.
"MUI" is a very loose term. It practically does not exist in SC2 since the data system handles most of the complex persistent parts of abilities with triggers only being used for complicated logical effects. That said you could do many conventional WC3 style trigger enhanced abilities using locals for storage thanks to the perfect timing accuracy of the defer executing native "Wait". Do be aware that a hard-coded thread limit does exist so you would want to avoid generating threads for trivial tasks (such as each unit hit by an AoE spell getting its own trigger thread).
The Galaxy virtual machine will automatically garbage collector those types once all references to them are lost. In fact there are no destructor natives for garbage collected types so you have to rely on the mechanic. There is also no "local handle reference counter error" in Galaxy like there was in JASS so there is no need to null any locals at the end of functions. Do note that a minor leak can still occur if you assign a reference to a complex type to a variable that is never accessed again as the object will persist until end of session however this is small and bounded so can be ignored.
Below is a list of types which the Galaxy Virtual Machine will automatically garbage collect once there are no references to them. It is taken from the natives declaration file and written by Blizzard.
Enjoy mapping with SC2.