What is the best way to code using the scripting language instead of the GUI?
A long time ago I found some methods online but they were very tedious and time consuming and I can no longer find the links online. A lot of the time I find myself making only changes to a few lines of code and then running it to see the output so any overhead in getting the script to run builds up very quickly.
I know there is an action in the GUI called custom script where you can place text. I've had to do that before to access things which are not available through the GUI but are there any limitations to that function? can you define and call functions through it? Is there a limit to how long it can be? for example if I had 10 thousand lines of code could I just place the entire program in a single "custom script" block in the GUI?
Hey, I generally just use custom script blocks where I need them. However, I have never tried large-scale galaxy scripting. I like to use the GUI as much as I can because (as tedious as code creation may be in GUI) if you change variable names, data object names, function names, etc, the GUI will automatically update them everywhere, which saves you a lot of pain if you need to change something and suddenly get a couple hundred syntax errors.
I'm used to using the GUI as well and can get around pretty fast in it. More just thinking so I can write scripts when away from my gaming computer such as on my laptop on the train or even on paper when I don't have access to my computer with SC2 on it. which happens a lot of the time.
Also I love it when someone picks the origin of my name. Usually I just go by turtles these days so nobody knows. :)
Scripting in GUI is a bit painful to me. Their editor can't even highlight syntax properly.. not even talking about bunch of other features that editor should have. Although aslong as you use scripts as a backup to the existing trigger system that's build into GUI, there's unfortunately no other way to keep both of those working properly.
If you would like to rely only only on scripts, the best way is to save map in unpacked format (.SC2Component) and then edit MapScript.galaxy directly. This way you can have editor open (data, terrain etc.) and at the same time do the scripting in your own editor. There's package to the Notepad+ with syntax highlight and autocompletion of the natives. http://www.sc2mapster.com/assets/notepad-galaxy-package/
Although i personally use the sublime text.
Once you get familiar with natives, scripting triggers etc. Everything will be much faster than building stuff in GUI.
The bad side of it is the galaxy language itself. It's really poor.. lacks a lot of features that modern script language should have. There were few galaxy extensions in the past, but unfortunately they died.. so there's no alternative at the moment.
I have been working on a fairly sizable SC2 project, and we are currently at 25,000 lines of code, about half of them written by me in galaxy script.
There are many, many things about it that allow you to code more effectively than the GUI. You can create triggers and add events to them dynamically. You can use function pointers and array pointers to code faster and more efficiently in many cases. You can use structs, though I prefer using the data table. It's far better organizationally, and encourages very abstract modular code, the more you get into it.
There's no need to put your galaxy in a custom script block inside of a trigger. You can create a custom script element much like a trigger, or function definition. It consists of just a text editor (to put your code in) and an input at the bottom for an initialization function. For this initialization function, it simply expects the name of a function you've defined with type void(), and it will run this initialization function during the load screen.
You can have as many of these custom script elements as you want to keep different modules of code separately, and you can give any/all/none of them initialization functions. A custom script element placed lower in the list can reference anything from the elements above it.
-
If you want to get into it, I recommend creating a single custom script element to contain all of your initialization. Use only a single initialization function, in this element. From there, create and execute triggers to initialize all of your other code modules.
The problem I have had with galaxy is the lack of pointers, templates, dynamic memory alloc, dynamic containers. Also, I have not seen any documentation of all the functions, macros and data types for galaxy.
What is the best way to code using the scripting language instead of the GUI?
A long time ago I found some methods online but they were very tedious and time consuming and I can no longer find the links online. A lot of the time I find myself making only changes to a few lines of code and then running it to see the output so any overhead in getting the script to run builds up very quickly.
I know there is an action in the GUI called custom script where you can place text. I've had to do that before to access things which are not available through the GUI but are there any limitations to that function? can you define and call functions through it? Is there a limit to how long it can be? for example if I had 10 thousand lines of code could I just place the entire program in a single "custom script" block in the GUI?
Thanks.
@finiteturtles: Go
Hey, I generally just use custom script blocks where I need them. However, I have never tried large-scale galaxy scripting. I like to use the GUI as much as I can because (as tedious as code creation may be in GUI) if you change variable names, data object names, function names, etc, the GUI will automatically update them everywhere, which saves you a lot of pain if you need to change something and suddenly get a couple hundred syntax errors.
P.S. It's turtes all the way down :P
I'm used to using the GUI as well and can get around pretty fast in it. More just thinking so I can write scripts when away from my gaming computer such as on my laptop on the train or even on paper when I don't have access to my computer with SC2 on it. which happens a lot of the time.
Also I love it when someone picks the origin of my name. Usually I just go by turtles these days so nobody knows. :)
Scripting in GUI is a bit painful to me. Their editor can't even highlight syntax properly.. not even talking about bunch of other features that editor should have. Although aslong as you use scripts as a backup to the existing trigger system that's build into GUI, there's unfortunately no other way to keep both of those working properly.
If you would like to rely only only on scripts, the best way is to save map in unpacked format (.SC2Component) and then edit MapScript.galaxy directly. This way you can have editor open (data, terrain etc.) and at the same time do the scripting in your own editor. There's package to the Notepad+ with syntax highlight and autocompletion of the natives.
http://www.sc2mapster.com/assets/notepad-galaxy-package/
Although i personally use the sublime text.
Once you get familiar with natives, scripting triggers etc. Everything will be much faster than building stuff in GUI.
The bad side of it is the galaxy language itself. It's really poor.. lacks a lot of features that modern script language should have. There were few galaxy extensions in the past, but unfortunately they died.. so there's no alternative at the moment.
Man how I wish I could just write cplusplus code for sc2. I could do so many more things, sadly you cant. :(
I have been working on a fairly sizable SC2 project, and we are currently at 25,000 lines of code, about half of them written by me in galaxy script.
There are many, many things about it that allow you to code more effectively than the GUI. You can create triggers and add events to them dynamically. You can use function pointers and array pointers to code faster and more efficiently in many cases. You can use structs, though I prefer using the data table. It's far better organizationally, and encourages very abstract modular code, the more you get into it.
There's no need to put your galaxy in a custom script block inside of a trigger. You can create a custom script element much like a trigger, or function definition. It consists of just a text editor (to put your code in) and an input at the bottom for an initialization function. For this initialization function, it simply expects the name of a function you've defined with type void(), and it will run this initialization function during the load screen.
You can have as many of these custom script elements as you want to keep different modules of code separately, and you can give any/all/none of them initialization functions. A custom script element placed lower in the list can reference anything from the elements above it.
-
If you want to get into it, I recommend creating a single custom script element to contain all of your initialization. Use only a single initialization function, in this element. From there, create and execute triggers to initialize all of your other code modules.
Thanks for the heads up MasterWrath. I might soon be embarking on a large project that will require this kind of stuff.
It's a mystery to me why this kind of thing isn't listed in some kind of Blizzard information or tutorial.
The problem I have had with galaxy is the lack of pointers, templates, dynamic memory alloc, dynamic containers. Also, I have not seen any documentation of all the functions, macros and data types for galaxy.
@finiteturtles: Go
Yeah, no worries. If you want advice on anything specific in the future, I'll be happy to help.