I just started creating maps so I am kinda new with editior, and I was wondering if it is worth learning how to script, from everything I have seen it seems to be, but then the next question is where is the best place to learn how to do it?
If someone could answer my questions above and perhaps provide a link to where I can learn galaxy would be much appericated.
if its writing in pure galaxy code... than no. not needed (only the really really advance stuff needs it, and its unlikely a normal map should ever need it)
In Warcraft 3 it was useful to learn Jass because there were things that weren't possible without it. However there's nothing more you can do in Galaxy than using the trigger editor. And, you will have a hard time doing things in Galaxy as it's not supported by default so you have to use tricky things to use it.
Blizzard is planning to give more focus on Galaxy in the next content patch, so it may be worth waiting.
Anyway if you want to learn Galaxy here are some links
Language Overview: Small article but contains all the structures of Galaxy (don't read everything about pointers, they have been removed since the beta).
Available functions: You can get all the available functions on the Wiki. Click on any function and you will have the galaxy version. Eg: point libNtve_gf_PointFromXYZ(fixed x, fixed y, fixed y2)
You can view what's your current triggers convert to galaxy by using the View Script option. Note: it will be kinda ugly since it's automatically generated.
Finally, you can read C tutorials as Galaxy is really close to C.
It all depends on how you like to work with your logic.
Personally, as a programmer, I like working with just the raw scripting language.
For a lot of people though, GUI offers a lot of good features and sheer simplicity.
As for how to "learn" Galaxy, start by learning basic C syntax. Nothing too complex, don't even bother with memory management or anything remotely beyond a 101 level. Hell, if you understand any programming language, Galaxy won't be a difficult learn.
Start by making something simple like Hello world in GUI. Then hit Data -> View Script. That's the raw Galaxy code, and that's basically how you start learning.
Vjeux isn't exactly correct, there are indeed quite a few things that cannot be done in GUI, but only in custom script. Some of these things are just small inconveniences, others could sometimes be very annoying (e.g. not being able to dynamically add new events to a trigger in GUI).
Also, once you got the hang of it, it is much easier to work with it. You can write triggers faster than you could ever do in GUI, because you don't have to click yourself through a ton of windows, prompts or lists. You'll also have much less trouble reading your triggers.
Last but not least you can make your script more efficient than with GUI. The difference isn't too great and most of the time you won't notice it at all. Still, from time to time it could help you.
I think you should consider learning scripting if:
You already have experience in languages like Java, Action Script, C+ +, etc. In this case learning SC2's scripting language will be pretty easy.
You know that you will be working with the Galaxy Editor for years to come and if you're a good learner. Even for someone without knowledge of other programming languages Custom Script is pretty easy to learn. You just need to be a logical thinker. But it isn't really worth the time if you'll stick with the editor for just a month or two.
The editor interface for working with custom scripts needs to be improved before it's worth it, IMO.
I wish Blizzard hadn't designed the editor around the lowest common denominator and just made the entire thing script-based using Lua or some established language (without a stupid 21-bit pointer.)
Just to clarify, are you debating between learning to script i GS (Galaxy Script) vs GUI triggers? or are you debating on wether to pick up SC2 edtitor as opposed to something like UDK (Unreal Development Kit) or Unity etc???
I am going to assume that you mean script vs GUI.
My short answer is... If you''re comfortable being called a "programmer", pick up scripting, if you aren't use the GUI.
SC2 is a bit more complex than WC3, but I recomended WC3 editor to a lot of my art major friends back in school because it was "color by number programming". That's not to make it sound bad or childish, it helps protect you from making a lot of mistakes and getting stuck on "programmer bugs" like the perverbial missig semi colon (Galaxy's Debugger is... barely there). It' also a good place to learn and refine your programming skills in terms of structure if you are a beginner programmer.
If you want deep control at the cost of complexity, script, but I doubt you'd be asking this question if that were the case.
If you are managing different game-states through a number of loops Galaxy is the only way to go. For a simplified example, I am working on a campaign map right and instead of making a periodic trigger and possibly hanging up the main thread, my AI runs off of a custom action in a separate thread similar to this:
While(true){Logic();Orders();Wait}
I do modify the actions inside of that Loop with triggers, but it frees up the main thread for the game itself instead of basic things like telling zerglings to evaluate possible success rate, unburrow, attack ect.
SC2 is a bit more complex than WC3, but I recomended WC3 editor to a lot of my art major friends back in school because it was "color by number programming". That's not to make it sound bad or childish, it helps protect you from making a lot of mistakes and getting stuck on "programmer bugs" like the perverbial missig semi colon (Galaxy's Debugger is... barely there). It' also a good place to learn and refine your programming skills in terms of structure if you are a beginner programmer.
If you want deep control at the cost of complexity, script, but I doubt you'd be asking this question if that were the case.
I highly agree with this. Using the GUI is a great way to learn basic programming concepts and work with interesting logical scenarios that you would not normally come across.
Vjeux isn't exactly correct, there are indeed quite a few things that cannot be done in GUI, but only in custom script. Some of these things are just small inconveniences, others could sometimes be very annoying (e.g. not being able to dynamically add new events to a trigger in GUI).
Also, once you got the hang of it, it is much easier to work with it. You can write triggers faster than you could ever do in GUI, because you don't have to click yourself through a ton of windows, prompts or lists. You'll also have much less trouble reading your triggers.
Last but not least you can make your script more efficient than with GUI. The difference isn't too great and most of the time you won't notice it at all. Still, from time to time it could help you.
I think you should consider learning scripting if:
You already have experience in languages like Java, Action Script, C+ +, etc. In this case learning SC2's scripting language will be pretty easy.
You know that you will be working with the Galaxy Editor for years to come and if you're a good learner. Even for someone without knowledge of other programming languages Custom Script is pretty easy to learn. You just need to be a logical thinker. But it isn't really worth the time if you'll stick with the editor for just a month or two.
I disagree completely here.
These "things you can only do in Galaxy" are just elitist myths so far. I mean, okay dynamically adding new events to triggers is one, but you can always obtain the same results within the GUI - just in a different way - without the code being any less efficient if you do things properly. We are being a bit obscure here so if you have any good exemples we can confront them, but think for a moment about what C actually does stack-wise in these triggers and loops... the difference usually isn't that great, and any map worrying about bad execution performances is seriously fuck*d up somewhere :)
About writing faster... meh, no. If you actually use both shortcuts and the search field (already knowing the functions, that is) the GUI is extremely fast and comfortable, unless you are able to code < pick each unit - if this - do something on them > loops in 10 seconds, also you have a MUCH clearer and coherent vision of the map/code structure itself when you need to change something later whether you commented your lines or not.
I don't normally mind writing raw code, I actually like doing that outside SC2, but to any new mapmaker I would recommend sticking with the GUI and only stop from time to time to learn (well, you are halfway there if your know C or Java) how the same thing is done in Galaxy just in case you really need it some day.
These "things you can only do in Galaxy" are just elitist myths so far. I mean, okay dynamically adding new events to triggers is one, but you can always obtain the same results within the GUI - just in a different way - without the code being any less efficient if you do things properly.
Well, you can always obtain same results in different ways. But not with the same efficiency.
In Warcraft II (where you actually COULD add events to a trigger through GUI actions) I've had a map with 12 different heroes. Each of which had a lot of triggers managing it's spells and skills. Through dynamic events I could make sure that only those heroes that were actually picked by a player would be loaded. As you can think it was going much easier on the performance this way.
Now, we're not in Wc3 anymore and people can talk much when they day is long, so there's two things that come to my mind which I regulary use and which are not possible using GUI (at least as far as I know).
Using Constants as length-definitions of arrays.
In GUI you always must use a magic number when you want to define the length of an array. Using Galaxy you can use constants. Why is that so useful? Well, I have a good example.
I'm in a small team working on a map. Initially we've decided on making it a 4-player map. Obviously I set up all my arrays accordingly with a length of 4 (= efficient room management). Now we noticed that 6 would be much better. Instead of having to manually change a dozen or more arrays to length of 6, I just change a single constant and all my arrays, all my systems, all my structs are suddenly working for all 6 players.
I'm using the same method for items, weapons and everything. If I need to make arrays to store something in it, then I make constants so I can change it within seconds.
I found this to be incredibly convenient.
Of course, in GUI, you can just change all values manually and obtain the same result with the same code efficiency. I just get it done in a hundredth of the time.
Being able to run a function in a (new thread) via it's string name. Galaxy has no native equivalent of Warcraft's ExecuteFun(). In Galaxy it's easy to recreate, but since you cannot dynamically create triggers using GUI it's impossible there.
Granted, in GUI you could just tick the Create Thread option to achieve the same thing, but behind the scenes this option creates unnecessary functions and globals for every function that it supposed to be New Threaded.
I use this to save myself time, work and performance when doing things like an item system. I don't wanna dive into exact explanations. Looking at my current map project I am using about 6 of these New threading functions. My way saves me 6 unneeded functions and about 20 globals that GUI would create.
Right. These things aren't really the stuff a "casual" (is it me or does the word sound kind of degrading?) mapper would miss, but nonetheless they're very comfortable for people who've worked with more powerful languages before and are used to this sort of stuff (thus my recommendation to learn Galaxy when you already have knowledge of some other languages)
and any map worrying about bad execution performances is seriously fuck*d up somewhere :)
As I mentioned, the difference really isn't great. Still, hand-written script can be written shorter and more efficient than it's translated GUI equivalent.
Some random example - A trigger that's supposed to spawn a few marines, wait 2 seconds, kill them off.
Well, that might be a question of preferences, but I find the lower one's purpose easier to identify. I'd also say it's faster (less function calls, stupid if-then gone, no useless declaration of the local group - one more local variable on the other hand).
Well, the same trigger in GUI-view would be ultimately easy to understand. But with longer GUI triggers I find it more and more convoluted. When I see nested if-thens and loops, and single actions with a parameter list of a mile's length.. that just looks confusing.
About writing faster... meh, no. If you actually use both shortcuts and the search field (already knowing the functions, that is) the GUI is extremely fast and comfortable, unless you are able to code < pick each unit - if this - do something on them > loops in 10 seconds, also you have a MUCH clearer and coherent vision of the map/code structure itself when you need to change something later whether you commented your lines or not.
Gotta give you that. The search function's pretty useful and makes GUI less of a pain to work with. It's also the way to go if I forgot the raw name of a function while scripting (although that won't happen to me anymore in half a year's time).
I don't agree on the "clearer and coherent" though. It's just like learning a different (human) language. At some point you're so accustomed to it that you immediately see what it's used for.
But that's the reason I suggested it to programmers or long-time mappers only. It takes some time until you can work with it really well.
I remember it took me about 4-6 months to learn vJass (with that I mean 4-6 months of working with it to be able to use it in my sleep), and that was my first programming language except of HTML. I worked with it for years and allowed me to easily learn Galaxy, Java and C+ + after that, so it was really worth the time for me.
Short answer: It depends on how much script you are going to end up writing. If you are planning on eventually working on cutting-edge or large scale projects then I believe that learning BOTH GUI and Galaxy scripting is a must. However, if you are only planning on making a few smaller maps, or maps that are moderately simple, then the time investment needed to learn galaxy will easily outweigh the benefits.
In the end, it is far more important to learn how to use the data editor properly - It can save you from writing a ton of script.
Excellent point there S3rius, didn't know you could use constants as length-definitions of arrays in Galaxy. I suggested that myself on the official forums before I started using arrays of struct (Record) in the form of P[n].variable to organize data :)
hah! That was the FIRST thing that bothered me about defining arrays in GE (as well as other parameters)... not being able to have a HUGE chunk of CONST definitions (or #def) at the beginning of my code for ease and flexibility, and starting with 3 instead of 8 or 20 or 100.
As for the example, you're talking about removing exception handling and safety measures in the code, and I'm not sure that's a "good" exchange, but it makes your point I guess.
But the question is, which should he learn, not which is better...
Haha variations of this thread cropped up all over the place in the Wc3 modding forums as well. As far as I can tell, everyone is still agreeing to disagree. GUI in Wc3 was crap though because of memory leaks in the Wc3 engine. These could only be cleaned up using pure JASS, or embedded JASS in your GUI scripts.
Personally, I don't see the point of a GUI for a scripting language. It's convoluted (try doing complex trigonometric functions and nested loops), painful to write - even if you can search for function names, and hell to understand and debug. Adding comments to explain your complicated sections is a lot easier to do in pure script, because you just type "// comment" instead of pressing yet another random button.
On that note, I wish the whole SC2 editor was script based, specifically the data editor. That thing is a behemoth of drop-down boxes and data fields. It would've been fine if all you could do with it is change units' damage, armour, etc. but now you can practically program in it. I find it ridiculously hard to figure out if I've set everything up correctly and almost impossible to "debug" a broken animation or effect. If all of that could be done in neatly commented script blocks, I would be much happier.
As for the example, you're talking about removing exception handling and safety measures in the code, and I'm not sure that's a "good" exchange, but it makes your point I guess.
I understand that concern, but I just can't think of a logical reason to keep the (!runactions) part.
Is there anything more brain-fried than to say "Run this (condition-less) trigger but don't run it's actions"? :D
Honestly I thought the same thing after I posted, but then I realized it's probably there to stop your triggers during cinematic mode and other situations where scripts are not supposed to be running (of course, you could shurt them all off yourself, but it's nice to have an off switch).
You can also turn triggers "on and off", and it may be for that purpose as well... so if you call a trigger and it is off, you don't crash and burn.
@s3rius: Go
About writing faster... meh, no. If you actually use both shortcuts and the search field (already knowing the functions, that is) the GUI is extremely fast and comfortable, unless you are able to code < pick each unit - if this - do something on them > loops in 10 seconds, also you have a MUCH clearer and coherent vision of the map/code structure itself when you need to change something later whether you commented your lines or not.
Really, gotta disagree with you here. For many tasks, the GUI is slower than Galaxy - take adding three variables together, or combining a string with multiple substrings, or setting the value of a unit type variable. Furthermore, you can use custom defined functions for common tasks to further speed up your coding. Being more clear/coherent is rather subjective, with proper indenting and such, your code should be rather easy to read (or at the least, no worse than GUI).
But anyways, regarding the thread, you should probably learn Galaxy if you already are good with another programming language, as it will come fairly easily. However, it is by no means a necessity, as almost everything can be done with GUI (the few things that can't, such as dynamic event adding, can be done with a custom script block anyways).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I just started creating maps so I am kinda new with editior, and I was wondering if it is worth learning how to script, from everything I have seen it seems to be, but then the next question is where is the best place to learn how to do it?
If someone could answer my questions above and perhaps provide a link to where I can learn galaxy would be much appericated.
Thank you for your time.
what do you think the scripting is?
if its writing in pure galaxy code... than no. not needed (only the really really advance stuff needs it, and its unlikely a normal map should ever need it)
if you think its the trigger editor. yeah.. pretty handy to learn it. (try look here: http://wiki.sc2mapster.com/galaxy/tutorials/
In Warcraft 3 it was useful to learn Jass because there were things that weren't possible without it. However there's nothing more you can do in Galaxy than using the trigger editor. And, you will have a hard time doing things in Galaxy as it's not supported by default so you have to use tricky things to use it.
Blizzard is planning to give more focus on Galaxy in the next content patch, so it may be worth waiting.
Anyway if you want to learn Galaxy here are some links
Eg:
point libNtve_gf_PointFromXYZ(fixed x, fixed y, fixed y2)@Jercy: Go
It all depends on how you like to work with your logic. Personally, as a programmer, I like working with just the raw scripting language.
For a lot of people though, GUI offers a lot of good features and sheer simplicity.
As for how to "learn" Galaxy, start by learning basic C syntax. Nothing too complex, don't even bother with memory management or anything remotely beyond a 101 level. Hell, if you understand any programming language, Galaxy won't be a difficult learn.
Start by making something simple like Hello world in GUI. Then hit Data -> View Script. That's the raw Galaxy code, and that's basically how you start learning.
Thanks for replying and thanks for the links, you guys answered my question very well, thanks again for the help.
I would like to post my view on that.
Vjeux isn't exactly correct, there are indeed quite a few things that cannot be done in GUI, but only in custom script. Some of these things are just small inconveniences, others could sometimes be very annoying (e.g. not being able to dynamically add new events to a trigger in GUI).
Also, once you got the hang of it, it is much easier to work with it. You can write triggers faster than you could ever do in GUI, because you don't have to click yourself through a ton of windows, prompts or lists. You'll also have much less trouble reading your triggers.
Last but not least you can make your script more efficient than with GUI. The difference isn't too great and most of the time you won't notice it at all. Still, from time to time it could help you.
I think you should consider learning scripting if:
The editor interface for working with custom scripts needs to be improved before it's worth it, IMO.
I wish Blizzard hadn't designed the editor around the lowest common denominator and just made the entire thing script-based using Lua or some established language (without a stupid 21-bit pointer.)
@Jercy: Go
Just to clarify, are you debating between learning to script i GS (Galaxy Script) vs GUI triggers? or are you debating on wether to pick up SC2 edtitor as opposed to something like UDK (Unreal Development Kit) or Unity etc???
I am going to assume that you mean script vs GUI.
My short answer is... If you''re comfortable being called a "programmer", pick up scripting, if you aren't use the GUI.
SC2 is a bit more complex than WC3, but I recomended WC3 editor to a lot of my art major friends back in school because it was "color by number programming". That's not to make it sound bad or childish, it helps protect you from making a lot of mistakes and getting stuck on "programmer bugs" like the perverbial missig semi colon (Galaxy's Debugger is... barely there). It' also a good place to learn and refine your programming skills in terms of structure if you are a beginner programmer.
If you want deep control at the cost of complexity, script, but I doubt you'd be asking this question if that were the case.
@vjeux: Go
If you are managing different game-states through a number of loops Galaxy is the only way to go. For a simplified example, I am working on a campaign map right and instead of making a periodic trigger and possibly hanging up the main thread, my AI runs off of a custom action in a separate thread similar to this:
I do modify the actions inside of that Loop with triggers, but it frees up the main thread for the game itself instead of basic things like telling zerglings to evaluate possible success rate, unburrow, attack ect.
I highly agree with this. Using the GUI is a great way to learn basic programming concepts and work with interesting logical scenarios that you would not normally come across.
I disagree completely here.
These "things you can only do in Galaxy" are just elitist myths so far. I mean, okay dynamically adding new events to triggers is one, but you can always obtain the same results within the GUI - just in a different way - without the code being any less efficient if you do things properly. We are being a bit obscure here so if you have any good exemples we can confront them, but think for a moment about what C actually does stack-wise in these triggers and loops... the difference usually isn't that great, and any map worrying about bad execution performances is seriously fuck*d up somewhere :)
About writing faster... meh, no. If you actually use both shortcuts and the search field (already knowing the functions, that is) the GUI is extremely fast and comfortable, unless you are able to code < pick each unit - if this - do something on them > loops in 10 seconds, also you have a MUCH clearer and coherent vision of the map/code structure itself when you need to change something later whether you commented your lines or not.
I don't normally mind writing raw code, I actually like doing that outside SC2, but to any new mapmaker I would recommend sticking with the GUI and only stop from time to time to learn (well, you are halfway there if your know C or Java) how the same thing is done in Galaxy just in case you really need it some day.
Well, you can always obtain same results in different ways. But not with the same efficiency.
In Warcraft II (where you actually COULD add events to a trigger through GUI actions) I've had a map with 12 different heroes. Each of which had a lot of triggers managing it's spells and skills. Through dynamic events I could make sure that only those heroes that were actually picked by a player would be loaded. As you can think it was going much easier on the performance this way.
Now, we're not in Wc3 anymore and people can talk much when they day is long, so there's two things that come to my mind which I regulary use and which are not possible using GUI (at least as far as I know).
In GUI you always must use a magic number when you want to define the length of an array. Using Galaxy you can use constants. Why is that so useful? Well, I have a good example.
I'm in a small team working on a map. Initially we've decided on making it a 4-player map. Obviously I set up all my arrays accordingly with a length of 4 (= efficient room management). Now we noticed that 6 would be much better. Instead of having to manually change a dozen or more arrays to length of 6, I just change a single constant and all my arrays, all my systems, all my structs are suddenly working for all 6 players.
I'm using the same method for items, weapons and everything. If I need to make arrays to store something in it, then I make constants so I can change it within seconds.
I found this to be incredibly convenient.
Of course, in GUI, you can just change all values manually and obtain the same result with the same code efficiency. I just get it done in a hundredth of the time.
Granted, in GUI you could just tick the Create Thread option to achieve the same thing, but behind the scenes this option creates unnecessary functions and globals for every function that it supposed to be New Threaded.
I use this to save myself time, work and performance when doing things like an item system. I don't wanna dive into exact explanations. Looking at my current map project I am using about 6 of these New threading functions. My way saves me 6 unneeded functions and about 20 globals that GUI would create.
Right. These things aren't really the stuff a "casual" (is it me or does the word sound kind of degrading?) mapper would miss, but nonetheless they're very comfortable for people who've worked with more powerful languages before and are used to this sort of stuff (thus my recommendation to learn Galaxy when you already have knowledge of some other languages)
As I mentioned, the difference really isn't great. Still, hand-written script can be written shorter and more efficient than it's translated GUI equivalent.
Some random example - A trigger that's supposed to spawn a few marines, wait 2 seconds, kill them off.
GUI translation:
Hand-written:
Well, that might be a question of preferences, but I find the lower one's purpose easier to identify. I'd also say it's faster (less function calls, stupid if-then gone, no useless declaration of the local group - one more local variable on the other hand).
Well, the same trigger in GUI-view would be ultimately easy to understand. But with longer GUI triggers I find it more and more convoluted. When I see nested if-thens and loops, and single actions with a parameter list of a mile's length.. that just looks confusing.
Gotta give you that. The search function's pretty useful and makes GUI less of a pain to work with. It's also the way to go if I forgot the raw name of a function while scripting (although that won't happen to me anymore in half a year's time).
I don't agree on the "clearer and coherent" though. It's just like learning a different (human) language. At some point you're so accustomed to it that you immediately see what it's used for.
But that's the reason I suggested it to programmers or long-time mappers only. It takes some time until you can work with it really well.
I remember it took me about 4-6 months to learn vJass (with that I mean 4-6 months of working with it to be able to use it in my sleep), and that was my first programming language except of HTML. I worked with it for years and allowed me to easily learn Galaxy, Java and C+ + after that, so it was really worth the time for me.
@Jercy: Go
Short answer: It depends on how much script you are going to end up writing. If you are planning on eventually working on cutting-edge or large scale projects then I believe that learning BOTH GUI and Galaxy scripting is a must. However, if you are only planning on making a few smaller maps, or maps that are moderately simple, then the time investment needed to learn galaxy will easily outweigh the benefits.
In the end, it is far more important to learn how to use the data editor properly - It can save you from writing a ton of script.
Excellent point there S3rius, didn't know you could use constants as length-definitions of arrays in Galaxy. I suggested that myself on the official forums before I started using arrays of struct (Record) in the form of P[n].variable to organize data :)
@s3rius: Go
hah! That was the FIRST thing that bothered me about defining arrays in GE (as well as other parameters)... not being able to have a HUGE chunk of CONST definitions (or #def) at the beginning of my code for ease and flexibility, and starting with 3 instead of 8 or 20 or 100.
As for the example, you're talking about removing exception handling and safety measures in the code, and I'm not sure that's a "good" exchange, but it makes your point I guess.
But the question is, which should he learn, not which is better...
Haha variations of this thread cropped up all over the place in the Wc3 modding forums as well. As far as I can tell, everyone is still agreeing to disagree. GUI in Wc3 was crap though because of memory leaks in the Wc3 engine. These could only be cleaned up using pure JASS, or embedded JASS in your GUI scripts.
Personally, I don't see the point of a GUI for a scripting language. It's convoluted (try doing complex trigonometric functions and nested loops), painful to write - even if you can search for function names, and hell to understand and debug. Adding comments to explain your complicated sections is a lot easier to do in pure script, because you just type "// comment" instead of pressing yet another random button.
On that note, I wish the whole SC2 editor was script based, specifically the data editor. That thing is a behemoth of drop-down boxes and data fields. It would've been fine if all you could do with it is change units' damage, armour, etc. but now you can practically program in it. I find it ridiculously hard to figure out if I've set everything up correctly and almost impossible to "debug" a broken animation or effect. If all of that could be done in neatly commented script blocks, I would be much happier.
I understand that concern, but I just can't think of a logical reason to keep the (!runactions) part. Is there anything more brain-fried than to say "Run this (condition-less) trigger but don't run it's actions"? :D
@s3rius: Go
Honestly I thought the same thing after I posted, but then I realized it's probably there to stop your triggers during cinematic mode and other situations where scripts are not supposed to be running (of course, you could shurt them all off yourself, but it's nice to have an off switch).
You can also turn triggers "on and off", and it may be for that purpose as well... so if you call a trigger and it is off, you don't crash and burn.
@Anthius: Go
It's for the turn trigger on/off functions.
Really, gotta disagree with you here. For many tasks, the GUI is slower than Galaxy - take adding three variables together, or combining a string with multiple substrings, or setting the value of a unit type variable. Furthermore, you can use custom defined functions for common tasks to further speed up your coding. Being more clear/coherent is rather subjective, with proper indenting and such, your code should be rather easy to read (or at the least, no worse than GUI).
But anyways, regarding the thread, you should probably learn Galaxy if you already are good with another programming language, as it will come fairly easily. However, it is by no means a necessity, as almost everything can be done with GUI (the few things that can't, such as dynamic event adding, can be done with a custom script block anyways).