I've been using the editor for several months now, and figure I have most of the GUI trigger editor down. I haven't really needed anything that I couldn't do without custom scripts yet, but I remember when toying with the WC3 editor there was tons of stuff. I'm just wondering what kind of stuff in Galaxy would you need custom scripting for? Also, are leaks just not a problem anymore in Galaxy? I remember they were a huge pain in WC3.
They improved the editor to the point where it now has garbage collection AFAIK. So most commonly used variables will not leak anymore. Unfortunately I can't find the list in the wiki because its been moved to some location that I'm unaware of.. hopefully someone will be able to find it and post it here.
Another advantage of galaxy is you can run triggers on a 1 shot basis. That is, its called and created only when it's needed, then destroyed afterwards. Though I'm not sure how to explain how this is a benefit. I suppose you can say it gives you a higher level of control over how the script is processed. I believe GUI by default creates every single trigger that exists, even if they are never used. If you have a lot of triggers, thats a lot of wasted memory space, and possibly poorer gameplay performance (since the triggers are most likely going to be just sitting in the stack doing nothing)
If you're familiar with the functions and stuff, its significantly faster to code in Galaxy than to code in GUI (Mouse clicks). Plus, There's always the option to use external tools such as Beiers Galaxy+ + to help you.
Another advantage of galaxy is you can run triggers on a 1 shot basis. That is, its called and created only when it's needed, then destroyed afterwards. Though I'm not sure how to explain how this is a benefit. I suppose you can say it gives you a higher level of control over how the script is processed. I believe GUI by default creates every single trigger that exists, even if they are never used. If you have a lot of triggers, thats a lot of wasted memory space, and possibly poorer gameplay performance (since the triggers are most likely going to be just sitting in the stack doing nothing)
How does this calling triggers thing work exactly? I know you can enable/disable triggers. I'm going to need to learn how to organize my triggers better eventually. Right now they're sort of just scattered all over the place. Can you point me to a good advanced trigger tutorial?
The main reason to use galaxy script for me is simple: Gui annoys me like hell. Having to click through tons of lists, especially when setting up complex calculation formulas is very irritating, if you could just type out the formula in a second.
There are several more advantages, like easier "conversion" of variable types (there is no "game link" or "dialog item" in galaxy script, almost everything is just strings or integers. You just need to know the IDs).
Some conversions of Game Link and String are not even possible in Gui, it seems.
The dynamic trigger creation/destruction is a big deal as well, this way you can easily create dynamic functions and store them as triggers to save them in variables and run them later on; this is impossible in Gui, where you can only start specific functions.
Also you can dynamically create triggers for lists of objects.
Imagine triggers reacting on a bunch of abilities: In Gui you either need to create a trigger for every single one of those abilities (a nuisance) or you need to create a trigger reacting to all abilities and exclude other stuff via conditions (a performance killer).
In Galaxy, you can loop your list of abilities and easily create 1 trigger per ability, without having to select every single ability manually. You can even set up the IDs of your abilities accordingly ("Abil1" - "Abil17") and loop through them as well, by connecting strings.
The one and only disadvantage of Script vs Gui is the editor support for scripting: Its basically non-existent. No autocompletion, failed syntax highlighting, cumbersome function list, useless error messages, slow as shit, no direct manipulation of the map script possible; it basically forces you to use external tools.
The dynamic trigger creation/destruction is a big deal as well, this way you can easily create dynamic functions and store them as triggers to save them in variables and run them later on; this is impossible in Gui, where you can only start specific functions.
Also you can dynamically create triggers for lists of objects.
Imagine triggers reacting on a bunch of abilities: In Gui you either need to create a trigger for every single one of those abilities (a nuisance) or you need to create a trigger reacting to all abilities and exclude other stuff via conditions (a performance killer).
In Galaxy, you can loop your list of abilities and easily create 1 trigger per ability, without having to select every single ability manually. You can even set up the IDs of your abilities accordingly ("Abil1" - "Abil17") and loop through them as well, by connecting strings.
So... dynamic triggering puts together triggers in game?
You said excluding things via conditions kills performance. I have a trigger with Event player presses a button (an command card button) NoGameLink. I'll then have a fairly big If Then Else-If list to go through a bunch of "Button Pressed" conditions, that will eventually check up to 200 buttons, but they'll be grouped together in clusters for buttons that have the same desired Actions. I don't know of a better way to do this. Is there one? Will this be a performance killer? I don't know atm how I would make it more efficient. I assume breaking it up into more than 1 trigger will be less efficient, but I wouldn't know.
So... dynamic triggering puts together triggers in game?
You said excluding things via conditions kills performance. I have a trigger with Event player presses a button (an command card button) NoGameLink. I'll then have a fairly big If Then Else-If list to go through a bunch of "Button Pressed" conditions, that will eventually check up to 200 buttons, but they'll be grouped together in clusters for buttons that have the same desired Actions. I don't know of a better way to do this. Is there one? Will this be a performance killer? I don't know atm how I would make it more efficient. I assume breaking it up into more than 1 trigger will be less efficient, but I wouldn't know.
That can be done without if else loops at all. You just need to create one trigger script that catches when an ability is cast. (With a condition that checks the phase of the cast) There's multiple phases... I can't remember what they are, but there's ability start, channel end etc etc. You need to check the wiki to find out. Assuming each of your 200 abilities are created in data with the ID's A001 to A200, you just need an event to catch the spell that was cast, retrieve it's ability command (and the ability name), then use the ability name to call the trigger script(s) which should be appropriately named A001 to A200.
This is the function to create a single trigger and destroy it afterwards, credit goes to s3rius
The main reason to use galaxy script for me is simple: Gui annoys me like hell. Having to click through tons of lists, especially when setting up complex calculation formulas is very irritating, if you could just type out the formula in a second.
Ditto.. Its damn annoying having to click click just to do a + b + c + d. In script you can just type it out, in GUI, you have to click (a + (b + (c + d))), that's a bracket in a bracket in a bracket.. CALCULATION
Same thing with strings. I think in GUI you're forced to use string concatenation function. Whereas you can actually just do s1 + s2 + s3
The truth is that GUI in SC2 is vastly superior to what it was in WC3. As such, the only practical differences with Galaxy come down to personal preference (I can type faster than I can click). If you've spent months mastering the GUI then there is no reason to throw that away for Galaxy. Put another way, there are virtually no performance or feature improvements to be had by switching to Galaxy.
As a disclaimer, I was a strong supporter of anti-GUI in WC3. But, all the good reasons have vanished. Besides, with the data editor being so powerful there is a much smaller role for triggering anyway.
<<quote>>
That can be done without if else loops at all. You just need to create one trigger script that catches when an ability is cast. (With a condition that checks the phase of the cast) There's multiple phases... I can't remember what they are, but there's ability start, channel end etc etc. You need to check the wiki to find out. Assuming each of your 200 abilities are created in data with the ID's A001 to A200, you just need an event to catch the spell that was cast, retrieve it's ability command (and the ability name), then use the ability name to call the trigger script(s) which should be appropriately named A001 to A200.
This is the function to create a single trigger and destroy it afterwards, credit goes to s3rius.
<</quote>>
Don't know why that quote isn't working.
So you're saying triggers can be stored in variables as strings, and created in game by plugging in an ability's ID to get the string variable it is stored in? That does sound pretty nifty. But will it increase performance over the other method? For me, though, it would actually take a lot longer to make and organize than just a GUI trigger.
So far I've basically gotten the impression that Karawasa mentioned. I made a prototype for my map in WC3, and it was a huge pain and custom scripting would have been necessary to complete it, but in Galaxy I haven't run into anything I absolutely need, but can't do with data and GUI, yet.
So you're saying triggers can be stored in variables as strings, and created in game by plugging in an ability's ID to get the string variable it is stored in? That does sound pretty nifty. But will it increase performance over the other method? For me, though, it would actually take a lot longer to make and organize than just a GUI trigger.
You don't even need to store them. The function I mentioned above serves only to handle the spells that are cast. You have the freedom to create your spell triggers at any sequence in the script, it should still work. If you have a trigger with the name A001, you can simply call it with RunFunction("A001"). The string itself can be extracted from the ability command, which is already stored automatically in the data when you create the dummy ability (with the id A001) in data.
In other words, you can basically have triggers binded to dummy abilities in data by name. And they will be multi-instanceable, because each call is run in its own thread. I'm not sure if GUI offers MUI functionality, this we have to check with someone else.
You said excluding things via conditions kills performance. I have a trigger with Event player presses a button (an command card button) NoGameLink. I'll then have a fairly big If Then Else-If list to go through a bunch of "Button Pressed" conditions, that will eventually check up to 200 buttons, but they'll be grouped together in clusters for buttons that have the same desired Actions. I don't know of a better way to do this. Is there one? Will this be a performance killer? I don't know atm how I would make it more efficient. I assume breaking it up into more than 1 trigger will be less efficient, but I wouldn't know.
If/then/else checks are pretty fast in galaxy, maybe I exaggerated a bit here. However for WC3 Gui it was quite common to use 1 trigger per ability, which fires on any ability being cast and then checks in the conditions, if the ability was the correct one. Back then, it was sort of okay, because conditions were handled differently and actually prevented the actions from being executed.
In SC2, the conditions just translate to an if/then/else within the actions, so the actions will be executed anyway. If you then do the same thing here, the triggers for all abilities would run their actions for every ability casted in the game, which obviously would not be that good for a serious number of abilities.
Well, this is just theoretically, you cannot even react to all casted abilities right now, I think.
You combined all your stuff in one trigger, which should be okay. However, breaking this up into 1 trigger per button would, in theory, improve the performance. It would need a little more memory because of more trigger objects, but each of the triggers does only react for one button, so the triggers are never executed unnecessarily.
However, your solution is just fine; no desparate reason to change it, I think. The performance gain should be marginal.
The truth is that GUI in SC2 is vastly superior to what it was in WC3. As such, the only practical differences with Galaxy come down to personal preference (I can type faster than I can click). If you've spent months mastering the GUI then there is no reason to throw that away for Galaxy. Put another way, there are virtually no performance or feature improvements to be had by switching to Galaxy.
As a disclaimer, I was a strong supporter of anti-GUI in WC3. But, all the good reasons have vanished. Besides, with the data editor being so powerful there is a much smaller role for triggering anyway.
I second that, in WC3 Jass was vastly superior to Gui, in SC2 Gui has improved a lot (while scripting basically has not changed). There is absolutely nothing wrong to use Gui over Galaxy at the moment.
Quote:
I'm not sure if GUI offers MUI functionality, this we have to check with someone else.
MUI does not necessarily mean, that a function runs in its own thread, but Gui supports creating custom actions, which can be executed in their own thread. In Galaxy, this translates to creating a new trigger again.
BTW what I meant with dynamic function calling was stuff like this:
Does not make much sense used like this, but can be very useful; for example, if you want to spawn units via trigger and eventually run a custom function for some of them (at least, thats what I use it for), or whatever.
If/then/else checks are pretty fast in galaxy, maybe I exaggerated a bit here. However for WC3 Gui it was quite common to use 1 trigger per ability, which fires on any ability being cast and then checks in the conditions, if the ability was the correct one. Back then, it was sort of okay, because conditions were handled differently and actually prevented the actions from being executed.
Happens now too - only the stack is being built. Since the condition breaks the function at the very beginning.
You can actually pretty easily reconstruct Wc3 triggers.
In Wc3 the condition was basically just a seperate function (with a few limitation such as not allowed to have waits) that returned a bool value to indicate if the main function should be called or not.
There is actually a major difference between Jass Conditions and Actions. Conditions were no real functions, but a special type called "boolexpr" for boolean expression. Functions returning boolean could be converted in boolexprs and stored in variables etc.
If used as a condition for a trigger, those prevented the action functions from being run, and using this was significantly faster than using the trigger without conditions, running the trigger actions and aborting them with an if/then/else.
I can't say anything certain about the speed, but my method doesn't abort anything.
triggerCondition is a fast function and I'd say it's at least as fast as it's JASS2 boolexpression equivalent. (Keeping in mind that Galaxy inherently is like 2x as fast as JASS2).
The more expensive triggerAction (it'll likely be larger and contain more variables) won't be touched then.
From my understanding, there is no difference in runtime between a function, which has thousands of lines and gets aborted at the first line and a function, which only has one line. So your solution does not have an advantage over the usual trigger structure Galaxy uses (if (!conditions) return true; ), but will only use an additional function call.
While it is true, that Galaxy is significantly faster than Jass, both share the fact, that function calls are very expensive, compared to other common programming languages (Function calls as in empty functions, just the call itself).
For Jass conditions, a boolexpr call of an empty boolexpr was significantly faster than executing an empty action without conditions. For galaxy, there is no difference for these 2 cases.
Since Galaxy is faster than Jass, this should not be a big deal anyway, but something to keep in mind. Also, while function calls are indeed "slow", this does not mean you should avoid them at all costs. You probably won't ever have a situation, where inlining function calls improves the performance of your map noticeably.
I don't know how they handle functions, so I don't know if the size matter when calling it. But we can at the very least assume that a smaller function won't be slower :)
However, you can save yourself variable declaration, which has to be done before you can insert a break. And that can make a difference.
Whether that's worth the trouble? Probably not. But performance is unnecessary to worry about as long as nothing lags.
I've been using the editor for several months now, and figure I have most of the GUI trigger editor down. I haven't really needed anything that I couldn't do without custom scripts yet, but I remember when toying with the WC3 editor there was tons of stuff. I'm just wondering what kind of stuff in Galaxy would you need custom scripting for? Also, are leaks just not a problem anymore in Galaxy? I remember they were a huge pain in WC3.
Anything you can do in the GUI, u can do in custom scripting.
@xKenneth: Go
Well yeah but my question was what are the benefits of custom scripting over GUI?
@Monictor: Go
They improved the editor to the point where it now has garbage collection AFAIK. So most commonly used variables will not leak anymore. Unfortunately I can't find the list in the wiki because its been moved to some location that I'm unaware of.. hopefully someone will be able to find it and post it here.
Another advantage of galaxy is you can run triggers on a 1 shot basis. That is, its called and created only when it's needed, then destroyed afterwards. Though I'm not sure how to explain how this is a benefit. I suppose you can say it gives you a higher level of control over how the script is processed. I believe GUI by default creates every single trigger that exists, even if they are never used. If you have a lot of triggers, thats a lot of wasted memory space, and possibly poorer gameplay performance (since the triggers are most likely going to be just sitting in the stack doing nothing)
If you're familiar with the functions and stuff, its significantly faster to code in Galaxy than to code in GUI (Mouse clicks). Plus, There's always the option to use external tools such as Beiers Galaxy+ + to help you.
@FuzzYD: Go
How does this calling triggers thing work exactly? I know you can enable/disable triggers. I'm going to need to learn how to organize my triggers better eventually. Right now they're sort of just scattered all over the place. Can you point me to a good advanced trigger tutorial?
The main reason to use galaxy script for me is simple: Gui annoys me like hell. Having to click through tons of lists, especially when setting up complex calculation formulas is very irritating, if you could just type out the formula in a second.
There are several more advantages, like easier "conversion" of variable types (there is no "game link" or "dialog item" in galaxy script, almost everything is just strings or integers. You just need to know the IDs).
Some conversions of Game Link and String are not even possible in Gui, it seems.
The dynamic trigger creation/destruction is a big deal as well, this way you can easily create dynamic functions and store them as triggers to save them in variables and run them later on; this is impossible in Gui, where you can only start specific functions.
Also you can dynamically create triggers for lists of objects.
Imagine triggers reacting on a bunch of abilities: In Gui you either need to create a trigger for every single one of those abilities (a nuisance) or you need to create a trigger reacting to all abilities and exclude other stuff via conditions (a performance killer).
In Galaxy, you can loop your list of abilities and easily create 1 trigger per ability, without having to select every single ability manually. You can even set up the IDs of your abilities accordingly ("Abil1" - "Abil17") and loop through them as well, by connecting strings.
The one and only disadvantage of Script vs Gui is the editor support for scripting: Its basically non-existent. No autocompletion, failed syntax highlighting, cumbersome function list, useless error messages, slow as shit, no direct manipulation of the map script possible; it basically forces you to use external tools.
So... dynamic triggering puts together triggers in game?
You said excluding things via conditions kills performance. I have a trigger with Event player presses a button (an command card button) NoGameLink. I'll then have a fairly big If Then Else-If list to go through a bunch of "Button Pressed" conditions, that will eventually check up to 200 buttons, but they'll be grouped together in clusters for buttons that have the same desired Actions. I don't know of a better way to do this. Is there one? Will this be a performance killer? I don't know atm how I would make it more efficient. I assume breaking it up into more than 1 trigger will be less efficient, but I wouldn't know.
That can be done without if else loops at all. You just need to create one trigger script that catches when an ability is cast. (With a condition that checks the phase of the cast) There's multiple phases... I can't remember what they are, but there's ability start, channel end etc etc. You need to check the wiki to find out. Assuming each of your 200 abilities are created in data with the ID's A001 to A200, you just need an event to catch the spell that was cast, retrieve it's ability command (and the ability name), then use the ability name to call the trigger script(s) which should be appropriately named A001 to A200.
This is the function to create a single trigger and destroy it afterwards, credit goes to s3rius
Yeap.. you can call triggers by name.
Ditto.. Its damn annoying having to click click just to do a + b + c + d. In script you can just type it out, in GUI, you have to click (a + (b + (c + d))), that's a bracket in a bracket in a bracket.. CALCULATION
Same thing with strings. I think in GUI you're forced to use string concatenation function. Whereas you can actually just do s1 + s2 + s3
The truth is that GUI in SC2 is vastly superior to what it was in WC3. As such, the only practical differences with Galaxy come down to personal preference (I can type faster than I can click). If you've spent months mastering the GUI then there is no reason to throw that away for Galaxy. Put another way, there are virtually no performance or feature improvements to be had by switching to Galaxy.
As a disclaimer, I was a strong supporter of anti-GUI in WC3. But, all the good reasons have vanished. Besides, with the data editor being so powerful there is a much smaller role for triggering anyway.
@FuzzYD: Go
<<quote>>
That can be done without if else loops at all. You just need to create one trigger script that catches when an ability is cast. (With a condition that checks the phase of the cast) There's multiple phases... I can't remember what they are, but there's ability start, channel end etc etc. You need to check the wiki to find out. Assuming each of your 200 abilities are created in data with the ID's A001 to A200, you just need an event to catch the spell that was cast, retrieve it's ability command (and the ability name), then use the ability name to call the trigger script(s) which should be appropriately named A001 to A200.This is the function to create a single trigger and destroy it afterwards, credit goes to s3rius. <</quote>>
Don't know why that quote isn't working.
So you're saying triggers can be stored in variables as strings, and created in game by plugging in an ability's ID to get the string variable it is stored in? That does sound pretty nifty. But will it increase performance over the other method? For me, though, it would actually take a lot longer to make and organize than just a GUI trigger.
So far I've basically gotten the impression that Karawasa mentioned. I made a prototype for my map in WC3, and it was a huge pain and custom scripting would have been necessary to complete it, but in Galaxy I haven't run into anything I absolutely need, but can't do with data and GUI, yet.
@Monictor: Go
You don't even need to store them. The function I mentioned above serves only to handle the spells that are cast. You have the freedom to create your spell triggers at any sequence in the script, it should still work. If you have a trigger with the name A001, you can simply call it with RunFunction("A001"). The string itself can be extracted from the ability command, which is already stored automatically in the data when you create the dummy ability (with the id A001) in data.
In other words, you can basically have triggers binded to dummy abilities in data by name. And they will be multi-instanceable, because each call is run in its own thread. I'm not sure if GUI offers MUI functionality, this we have to check with someone else.
If/then/else checks are pretty fast in galaxy, maybe I exaggerated a bit here. However for WC3 Gui it was quite common to use 1 trigger per ability, which fires on any ability being cast and then checks in the conditions, if the ability was the correct one. Back then, it was sort of okay, because conditions were handled differently and actually prevented the actions from being executed.
In SC2, the conditions just translate to an if/then/else within the actions, so the actions will be executed anyway. If you then do the same thing here, the triggers for all abilities would run their actions for every ability casted in the game, which obviously would not be that good for a serious number of abilities.
Well, this is just theoretically, you cannot even react to all casted abilities right now, I think.
You combined all your stuff in one trigger, which should be okay. However, breaking this up into 1 trigger per button would, in theory, improve the performance. It would need a little more memory because of more trigger objects, but each of the triggers does only react for one button, so the triggers are never executed unnecessarily.
However, your solution is just fine; no desparate reason to change it, I think. The performance gain should be marginal.
I second that, in WC3 Jass was vastly superior to Gui, in SC2 Gui has improved a lot (while scripting basically has not changed). There is absolutely nothing wrong to use Gui over Galaxy at the moment.
MUI does not necessarily mean, that a function runs in its own thread, but Gui supports creating custom actions, which can be executed in their own thread. In Galaxy, this translates to creating a new trigger again.
BTW what I meant with dynamic function calling was stuff like this:
Does not make much sense used like this, but can be very useful; for example, if you want to spawn units via trigger and eventually run a custom function for some of them (at least, thats what I use it for), or whatever.
Happens now too - only the stack is being built. Since the condition breaks the function at the very beginning.
You can actually pretty easily reconstruct Wc3 triggers.
In Wc3 the condition was basically just a seperate function (with a few limitation such as not allowed to have waits) that returned a bool value to indicate if the main function should be called or not.
@s3rius: Go
There is actually a major difference between Jass Conditions and Actions. Conditions were no real functions, but a special type called "boolexpr" for boolean expression. Functions returning boolean could be converted in boolexprs and stored in variables etc.
If used as a condition for a trigger, those prevented the action functions from being run, and using this was significantly faster than using the trigger without conditions, running the trigger actions and aborting them with an if/then/else.
@Kueken531: Go
I can't say anything certain about the speed, but my method doesn't abort anything.
triggerCondition is a fast function and I'd say it's at least as fast as it's JASS2 boolexpression equivalent. (Keeping in mind that Galaxy inherently is like 2x as fast as JASS2).
The more expensive triggerAction (it'll likely be larger and contain more variables) won't be touched then.
From my understanding, there is no difference in runtime between a function, which has thousands of lines and gets aborted at the first line and a function, which only has one line. So your solution does not have an advantage over the usual trigger structure Galaxy uses (if (!conditions) return true; ), but will only use an additional function call.
While it is true, that Galaxy is significantly faster than Jass, both share the fact, that function calls are very expensive, compared to other common programming languages (Function calls as in empty functions, just the call itself).
For Jass conditions, a boolexpr call of an empty boolexpr was significantly faster than executing an empty action without conditions. For galaxy, there is no difference for these 2 cases.
Since Galaxy is faster than Jass, this should not be a big deal anyway, but something to keep in mind. Also, while function calls are indeed "slow", this does not mean you should avoid them at all costs. You probably won't ever have a situation, where inlining function calls improves the performance of your map noticeably.
I don't know how they handle functions, so I don't know if the size matter when calling it. But we can at the very least assume that a smaller function won't be slower :)
However, you can save yourself variable declaration, which has to be done before you can insert a break. And that can make a difference.
Whether that's worth the trouble? Probably not. But performance is unnecessary to worry about as long as nothing lags.