Scripting in Galaxy inside the editor should be enough to drive any reasonably intelligent person insane due to the numerous failings in the editor and the language itself. A few people have attempted to created Galaxy compilers to help relieve this situation, however, they are either dead or woefully buggy and borderline unusable (Andromeda).
After discovering some interesting methods I have decided to create a Galaxy preprocessor to deal with the situation and turn Galaxy into a usable language. In truth, there are only a few fundamental issues which hold Galaxy back from being a reasonable language to work with. A preprocessor is fully capable of dealing with these issues without the immense time requirement or complexity entailed by a full-fledged compiler.
Main features:
1.) Store your code as .galaxy files, not triggers - This preprocessor will allow you to save your code as .galaxy files within whatever directory/subdirectory structure you please.
2.) Script requirements - Galaxy's import system is unreliable once an imported script imports another script. The editor doesn't like it at all, and it may completely lose its ability to syntax check the resulting script file. This preprocessor allows you to specify which scripts require which other scripts, and merges the resulting output into a single script.
3.) Scoping - This preprocessor will treat each .galaxy file as its own scope, and allow you to create public and privately scoped globals and functions. No more worrying about clashing identifiers or using awkward names to avoid it.
4.) Initialization - An init function for each script that will automatically run in its own thread. A well-defined initialization order.
5.) Convenience features - This preprocessor will allow you to freely declare locals throughout a function and fix small known bugs in the Galaxy language.
6.) Conditional compilation - Debug mode will be supported, along with the possibility for other forms of conditional compilation.
7.) Script compression - Deleting whitespace and comments will be optionally possible.
8.) Macros - Text macros will be supported.
8.) Function pointers - Yes, OMG, it will be possible to create working function pointers.
10.) Structs - Simple structs with . syntax and dynamic creation/destruction should be available at some point.
11.) Simple/friendly GUI with options displayed.
12.) Hotkeys - Allows you to test or compile your map instantly, even when not looking at the editor.
13.) Enhanced autocompletion for NotepadPlusPlus - You will be able to automatically add/remove user-defined functions to/from your autocompletion file.
So why, you ask, is it possible to create such a tool in a relatively short period of time? It is because every one of these tasks can be accomplished through string manipulation and logic without having to build an abstract syntax tree or anything of that nature. It is also being written in a very simple scripting language called AutoIt, which has a rich library of support functions available which will greatly simplify a project of this nature.
I guess the next question is, how fast can it possibly be if you're writing it in an interpreted language? Isn't speed essential for this type of task? I was worried about this at first, however, I decided that the speed of development and debugging gained from using a higher-level language greatly outweighed any speed concerns. But if you are interested in a bunchmark, the amount of time it currently takes for it to read and alter 50,000 lines of code from 200+ files and output them into a single script file is less than 3 seconds.
In this thread (if anyone takes interest in it) I will provide an ongoing updates of the development progress and take any suggestions regarding features or syntax. However, please keep in mind the scope of this project and don't ask me to convert Galaxy into a fully OOP language or something like that.
I am currently building my AI project in Notepad++. It currently exists of 893.556 bytes of .galaxy files.
Notepad++ works fine for syntax highlighting and auto-completion, but what I am really missing is debugging functionality.
When I make a typo somewhere, the game simply refuses to run and I have to dig through my most recent changes to find the mistake.
I am unable to develop this project in the editor, because the editor does not recognize the "include" statement so functions declared in other files are not known to him, generating tons of compile errors.
If you could provide with a program that has similar features to Notepad++ and includes a galaxy preprocessor so it can tell where I made an error in the script, I will love you till the end of time.
There is already a way to perform syntax checking on your local .galaxy files, but everything must be setup correctly. If you feel like logging in to SC2Mapter IRC I can explain it to you there.
Looking forward to this. I miss scopes from vJass. They made it so easy to make custom spells as i didn't have to worry about accidentally redeclaring an existing variable. I recognize your alias.. I've seen you before in wc3c forums :) I went by the alias spyralz back then.
Why do you want to base this tool on text manipulation instead of real parsing and syntax trees? I think this is one of the main problems with vjass: you sometimes have cryptic compiler errors - with some typing errors you do not even get a compiler error at all. I hope this will be better with your tool ;)
Despite of that this project really sounds promising. But I think it is hard for a scripting language to become popular in sc2 since
1. the gui does not suck as much as it did in wc3 as there are functions and local variables
2. scripting is less important because many things have to be done with the data editor
Maybe a successful scripting language would need support to create and manipulate data at compile time.
The many reasons I am basing it on text manipulation:
Every feature that is needed for this project can be accomplished with text manipulation, and it is in fact much easier to handle that way.
Anyone who understands Galaxy code will be able to open the source code and modify it due to the simplicity of the code structure and the AutoIt scripting language.
It will be more than fast enough, even in an interpreted language.
I am not compiling anything, you will have to rely on Galaxy's build-in syntax checker for your syntax errors. However, I plan to provide extremely specific error information if you use a preprocessor feature incorrectly.
Would you rather have a project that can be working in a couple weeks and feature-complete in a couple months, or yet another project that will never be finished?
As far as popularity, it seems like almost no one actually uses Galaxy anyway, so I wouldn't be doing this if I cared for popularity. I plan to use it myself and if a few other people enjoy it, so much the better. :)
I do not plan to add support for data editor manipulation, that is beyond the scope of this project, and I don't see how it would be nearly as useful as it would have been in WC3.
As far as popularity, it seems like almost no one actually uses Galaxy anyway, so I wouldn't be doing this if I cared for popularity. I plan to use it myself and if a few other people enjoy it, so much the better. :)
This preprocessor will be very useful, certainly more useful than the various language extensions that are not yet or will never be finished. =D
A script's filename (dropping the .galaxy extension) is considered to be its scope identifier. Scopes are synonymous with individual files, so there will be no syntax to actually declare new scopes.
Requirements are expected to be listed as the first non-comment line of a .galaxy file. They are listed as "requires ScriptA, ScriptB, ScriptC", or you may use "requires *" to move a script to the bottom of the output. (Unsorted order with any other script that requires *)
Scoping is simple, you either put "public" or "private" in front of the declaration of a global or function. Public prefixes the scope identifier, such as "MyScript_FuncName" whereas private makes the function/global invalid for use outside of that scope.
To declare an initializer you will simply declare "private void Init()" inside your scope.
If debug mode is enabled, any line that begins with "DEBUG" will be replaced with a comment.
I have not put much thought into the syntax of other features yet, but getting all of the above working is my current goal.
Just to clarify for me, I still write my code in say NotepadPlusPlus and then run it through your preprocessor?
I'm rather new to this and wonder how I'll go ahead coding with this.
Is that preprocessor build within the SC2 editor then, do I still have to import my scripts in someway after they run through the preprocessor?
Would be nice if you could clarify the whole procedure of creating the code and actually starting a map with it, so newbies like me understand it ;P
Very nice, I especialy like that you will do Scopes and merge it into 1 script. Much easier! Oh and I will no matter what use Galaxy instead of GUI, It is much faster and easier to write/read Galaxy than GUI. If you have to do some math in GUI like 3 + VARIABLE * VARIABLE then it is such a pain in the ass, but in Galaxy you can just type it in 2 seconds. I hope you will get this done, good luck.
Progress update... the following features are done:
Combining all of the .galaxy files from a specified directory into an output script at a specified directory.
Script requirements, requires *, topological sorting to resolve script order
Public and private scopes
Map/script headers
Script compression options
Handling of multi-statement lines
Specific error reporting
The next step is to add proper handling of comments/block comments/string literals, as well as differentiating between identifiers in the global and local namespace. After that, initializers will be next, followed by hotkeys for syntax checking/testing.
Once the above is complete I will make a basic GUI and some documentation and do an initial release for people who want to use this tool as soon as possible.
@grim001: Go
This is very interesting.
I'm working on generating Galaxy code from a certain theoretic model, but I'm doing my work in prolog. I generally tried to avoid any text-manipulating languages, like Perl, because if I want to do smart analysis (whether on the model, or plain Galaxy) those languages are very poor "hosts".
I would sure like to borrow your techniques, if you don't mind, when the time comes.
Can you further elaborate on "Specific error reporting"? Did you write an exception mechanism?
Andromeda is broken and is unusable for anything resembling actual mapping. My numerous bug reports on the forum that show that even the most basic functionality is broken demonstrate that. Anything that works would be an improvement.
I have reconsidered my approach and I will be building an AST and creating a true compiler. I believe that this can be accomplished in a relatively short amount of time, however, it will delay development by several weeks at least. All of the previous features mentioned will still exist, the major change being that you will not need to rely on the editor's syntax checker at all. It also presents the possibility of adding many more features in the future since with a proper AST I will be able to manipulate the language in any way imaginable. I plan to leave this thread dormant for a while and possibly create a new one when new information is available.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Scripting in Galaxy inside the editor should be enough to drive any reasonably intelligent person insane due to the numerous failings in the editor and the language itself. A few people have attempted to created Galaxy compilers to help relieve this situation, however, they are either dead or woefully buggy and borderline unusable (Andromeda).
After discovering some interesting methods I have decided to create a Galaxy preprocessor to deal with the situation and turn Galaxy into a usable language. In truth, there are only a few fundamental issues which hold Galaxy back from being a reasonable language to work with. A preprocessor is fully capable of dealing with these issues without the immense time requirement or complexity entailed by a full-fledged compiler.
Main features:
So why, you ask, is it possible to create such a tool in a relatively short period of time? It is because every one of these tasks can be accomplished through string manipulation and logic without having to build an abstract syntax tree or anything of that nature. It is also being written in a very simple scripting language called AutoIt, which has a rich library of support functions available which will greatly simplify a project of this nature.
I guess the next question is, how fast can it possibly be if you're writing it in an interpreted language? Isn't speed essential for this type of task? I was worried about this at first, however, I decided that the speed of development and debugging gained from using a higher-level language greatly outweighed any speed concerns. But if you are interested in a bunchmark, the amount of time it currently takes for it to read and alter 50,000 lines of code from 200+ files and output them into a single script file is less than 3 seconds.
In this thread (if anyone takes interest in it) I will provide an ongoing updates of the development progress and take any suggestions regarding features or syntax. However, please keep in mind the scope of this project and don't ask me to convert Galaxy into a fully OOP language or something like that.
@grim001: Go
Interesting.
Good luck with this. Would prove most valuable for people that program in Galaxy.
I am currently building my AI project in Notepad++. It currently exists of 893.556 bytes of .galaxy files.
Notepad++ works fine for syntax highlighting and auto-completion, but what I am really missing is debugging functionality.
When I make a typo somewhere, the game simply refuses to run and I have to dig through my most recent changes to find the mistake.
I am unable to develop this project in the editor, because the editor does not recognize the "include" statement so functions declared in other files are not known to him, generating tons of compile errors.
If you could provide with a program that has similar features to Notepad++ and includes a galaxy preprocessor so it can tell where I made an error in the script, I will love you till the end of time.
There is already a way to perform syntax checking on your local .galaxy files, but everything must be setup correctly. If you feel like logging in to SC2Mapter IRC I can explain it to you there.
@grim001: Go
Looking forward to this. I miss scopes from vJass. They made it so easy to make custom spells as i didn't have to worry about accidentally redeclaring an existing variable. I recognize your alias.. I've seen you before in wc3c forums :) I went by the alias spyralz back then.
Why do you want to base this tool on text manipulation instead of real parsing and syntax trees? I think this is one of the main problems with vjass: you sometimes have cryptic compiler errors - with some typing errors you do not even get a compiler error at all. I hope this will be better with your tool ;)
Despite of that this project really sounds promising. But I think it is hard for a scripting language to become popular in sc2 since
1. the gui does not suck as much as it did in wc3 as there are functions and local variables
2. scripting is less important because many things have to be done with the data editor
Maybe a successful scripting language would need support to create and manipulate data at compile time.
The many reasons I am basing it on text manipulation:
As far as popularity, it seems like almost no one actually uses Galaxy anyway, so I wouldn't be doing this if I cared for popularity. I plan to use it myself and if a few other people enjoy it, so much the better. :)
I do not plan to add support for data editor manipulation, that is beyond the scope of this project, and I don't see how it would be nearly as useful as it would have been in WC3.
This preprocessor will be very useful, certainly more useful than the various language extensions that are not yet or will never be finished. =D
Hey grim.
Do you have any example syntax yet? Even if it's not implemented?
Thanks. :)
A script's filename (dropping the .galaxy extension) is considered to be its scope identifier. Scopes are synonymous with individual files, so there will be no syntax to actually declare new scopes.
Requirements are expected to be listed as the first non-comment line of a .galaxy file. They are listed as "requires ScriptA, ScriptB, ScriptC", or you may use "requires *" to move a script to the bottom of the output. (Unsorted order with any other script that requires *)
Scoping is simple, you either put "public" or "private" in front of the declaration of a global or function. Public prefixes the scope identifier, such as "MyScript_FuncName" whereas private makes the function/global invalid for use outside of that scope.
To declare an initializer you will simply declare "private void Init()" inside your scope.
If debug mode is enabled, any line that begins with "DEBUG" will be replaced with a comment.
I have not put much thought into the syntax of other features yet, but getting all of the above working is my current goal.
Hey, this sounds really promising.
Just to clarify for me, I still write my code in say NotepadPlusPlus and then run it through your preprocessor? I'm rather new to this and wonder how I'll go ahead coding with this.
Is that preprocessor build within the SC2 editor then, do I still have to import my scripts in someway after they run through the preprocessor?
Would be nice if you could clarify the whole procedure of creating the code and actually starting a map with it, so newbies like me understand it ;P
If you want to imagine what the general procedure will be while using this...
Alright thanks, hope you'll get it done soon :>
Very nice, I especialy like that you will do Scopes and merge it into 1 script. Much easier! Oh and I will no matter what use Galaxy instead of GUI, It is much faster and easier to write/read Galaxy than GUI. If you have to do some math in GUI like 3 + VARIABLE * VARIABLE then it is such a pain in the ass, but in Galaxy you can just type it in 2 seconds. I hope you will get this done, good luck.
Progress update... the following features are done:
The next step is to add proper handling of comments/block comments/string literals, as well as differentiating between identifiers in the global and local namespace. After that, initializers will be next, followed by hotkeys for syntax checking/testing.
Once the above is complete I will make a basic GUI and some documentation and do an initial release for people who want to use this tool as soon as possible.
@grim001: Go This is very interesting. I'm working on generating Galaxy code from a certain theoretic model, but I'm doing my work in prolog. I generally tried to avoid any text-manipulating languages, like Perl, because if I want to do smart analysis (whether on the model, or plain Galaxy) those languages are very poor "hosts". I would sure like to borrow your techniques, if you don't mind, when the time comes.
Can you further elaborate on "Specific error reporting"? Did you write an exception mechanism?
Nice! gGalaxy and GalaxyNewGen! This is something that may finally sway me back to making sc2 maps :). Keep up the good work!
I don't see how this is better than Andromeda...
Andromeda is broken and is unusable for anything resembling actual mapping. My numerous bug reports on the forum that show that even the most basic functionality is broken demonstrate that. Anything that works would be an improvement.
Status update for anyone who was following this:
I have reconsidered my approach and I will be building an AST and creating a true compiler. I believe that this can be accomplished in a relatively short amount of time, however, it will delay development by several weeks at least. All of the previous features mentioned will still exist, the major change being that you will not need to rely on the editor's syntax checker at all. It also presents the possibility of adding many more features in the future since with a proper AST I will be able to manipulate the language in any way imaginable. I plan to leave this thread dormant for a while and possibly create a new one when new information is available.