Why do people continue to believe that any amount of time at all passes while code is executing? The amount of time that passes is something on the scale of nanoseconds, which far too miniscule to affect anything. Furthermore, the game does not simulate the progression of time until it is done with all current threads.
The actual problem is that, if you have a trigger that's supposed to execute when a unit receives a buff, and the code in the part of the original trigger after the buff is applied needs that buff application trigger to have already run, you will need to use a Wait(0) to allow the queued trigger to actually occur.
Another problematic example is a system that indexes units when they enter the map. Due to the fact that the unit creation trigger does not run instantly, anytime you create a unit, it would not have an index assigned until after a wait. This forces the index retrieval function to do a check for whether the unit has an index or not, rather than just returning the unit's custom value without any safety checks.
In general, triggers would be more useful if they applied side effects instantly, whereas this arrangement will make you have to worry about whether or not side effects have actually been processed yet.
I was a wc3 mapper back then and I can't remember it being any different from how things go in SC2.
Anyway, you don't want concurrent threads. You want serialized threads. It's a trigger-action system and not a game engine in itself.
The way that threads worked in WC3 was very well known, and they worked as I just described. It was an excellent design. The way they work now will cause a large number of problems for non-GUI users creating maps of sufficient complexity. (Example: being forced to use Wait 0 when you want the side-effects of an action to be processed before continuing). The only way to deal with this is to use native wrappers that force side-effects to be processed immediately, and to avoid relying on triggers for certain things. Once code sharing gets thrown into the mix, a compiler that hooks natives will be the only way to deal with it that doesn't require people to go around massively editing libraries that they import.
Also, there has never been such a thing as concurrency in WC3 or SC2.
MTops, your example is flawed because time does not elapse while script is executing.
OK, I went ahead and did some conclusive testing on this subject so we can all stop speculating. I will admit that I assumed it worked the same way as in WC3, because that is the most sensible and correct way to handle events. Instead, SC2 does something shitty and places new events at the end of the trigger queue.
Everything else mentioned in the thread is correct. Triggers are first-come-first-serve, and they will yield to other triggers in the queue as soon as they hit a wait.
To complicate things, there is an exception. Due to some GUI-related limitations that go back to WC3, Blizzard specifically makes unit creation events non-interrupting, and places the event at the end of the thread stack instead. However that is the only non-interrupting trigger event that I know of, and it may in fact be the only one.
Kakuen, that's incorrect. MTops, every time anything happens which would cause a new event to fire, it pushes the current thread into a stack where it lies dormant until the new thread is complete or hits a wait, at which point the previous thread is popped from the stack, etc., until no current threads remain. It works the same way as calling a function from within a function from within a function... etc.
Everything that happens in Galaxy happens sequentially. However, if any code in that trigger causes another trigger to fire, the current trigger will be interrupted at that point and the new trigger will begin executing. It will continue until it either finishes or hits a Wait, at which point it will yield to the previous trigger's thread.
In addition, if you have the same event registered to multiple triggers, they will be served in order of registration as s3rius mentioned.
SBeiers editor is pretty nice indeed. After checking it out, I would offer this comparison to anyone who is wondering whether they should use NotepadPlusPlus or his editor for scripting Galaxy:
SBeiers editor:
+ Continuous syntax checking
+ Autocomplete is always up to date
- Any 3rd party Galaxy parser that exists at this point has not been sufficiently tested
- Cannot change font, font size, or syntax coloring
- Only handles 1 currently open script
NotepadPlusPlus:
+ Control over the appearance of code
+ Autocomplete is a bit more responsive
+ Open multiple scripts in tabs
- Autocomplete may be out of date after a patch until it is updated
These files include every native and constant from natives.galaxy, NativeLib.galaxy, AI.galaxy and TacticalAI.galaxy as of the current 1.3.0 patch. This is much more up to date and exhaustive than any previously released autocomplete file.
I prefer a darker color theme while scripting because staring at a 100% white screen for 8+ hours can cause eye strain. If you've never used a dark theme for scripting/coding before, I highly suggest you try it out. Below are a couple screenshots to give you an idea of what it looks like:
Of course, if you don't like the style you are free to use the autocomplete file and design your own theme.
If you plan to download this, make SURE you follow the steps in the included readme file. If you have any trouble getting it working after following all of the directions, feel free to post about it here.
Edit: I have created a modified 2nd version of the theme which supports code folding but does not support syntax highlighting for the NativeLib functions. (Those are the ones that begin with libNtve_) It does still autocomplete them, however, they appear in white text like user-defined functions. If you enjoy code folding, you will want to download this version instead.
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.
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.
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.
for example if you have a pick each unit in unit group and the unit group being all units in Entire Map
it will take 0-10 seconds and the game will completely halt until the loop has finished.
That is not nearly enough to lag the game, even if you have a couple hundred units, unless you are doing extremely heavy processing on each unit in the loop... which means you have something severely wrong with your code design.
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.
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.
0
Why do people continue to believe that any amount of time at all passes while code is executing? The amount of time that passes is something on the scale of nanoseconds, which far too miniscule to affect anything. Furthermore, the game does not simulate the progression of time until it is done with all current threads.
The actual problem is that, if you have a trigger that's supposed to execute when a unit receives a buff, and the code in the part of the original trigger after the buff is applied needs that buff application trigger to have already run, you will need to use a Wait(0) to allow the queued trigger to actually occur.
Another problematic example is a system that indexes units when they enter the map. Due to the fact that the unit creation trigger does not run instantly, anytime you create a unit, it would not have an index assigned until after a wait. This forces the index retrieval function to do a check for whether the unit has an index or not, rather than just returning the unit's custom value without any safety checks.
In general, triggers would be more useful if they applied side effects instantly, whereas this arrangement will make you have to worry about whether or not side effects have actually been processed yet.
0
The way that threads worked in WC3 was very well known, and they worked as I just described. It was an excellent design. The way they work now will cause a large number of problems for non-GUI users creating maps of sufficient complexity. (Example: being forced to use Wait 0 when you want the side-effects of an action to be processed before continuing). The only way to deal with this is to use native wrappers that force side-effects to be processed immediately, and to avoid relying on triggers for certain things. Once code sharing gets thrown into the mix, a compiler that hooks natives will be the only way to deal with it that doesn't require people to go around massively editing libraries that they import.
Also, there has never been such a thing as concurrency in WC3 or SC2.
0
MTops, your example is flawed because time does not elapse while script is executing.
OK, I went ahead and did some conclusive testing on this subject so we can all stop speculating. I will admit that I assumed it worked the same way as in WC3, because that is the most sensible and correct way to handle events. Instead, SC2 does something shitty and places new events at the end of the trigger queue.
Everything else mentioned in the thread is correct. Triggers are first-come-first-serve, and they will yield to other triggers in the queue as soon as they hit a wait.
0
To complicate things, there is an exception. Due to some GUI-related limitations that go back to WC3, Blizzard specifically makes unit creation events non-interrupting, and places the event at the end of the thread stack instead. However that is the only non-interrupting trigger event that I know of, and it may in fact be the only one.
0
Kakuen, that's incorrect. MTops, every time anything happens which would cause a new event to fire, it pushes the current thread into a stack where it lies dormant until the new thread is complete or hits a wait, at which point the previous thread is popped from the stack, etc., until no current threads remain. It works the same way as calling a function from within a function from within a function... etc.
0
@moshewe: Go
Everything that happens in Galaxy happens sequentially. However, if any code in that trigger causes another trigger to fire, the current trigger will be interrupted at that point and the new trigger will begin executing. It will continue until it either finishes or hits a Wait, at which point it will yield to the previous trigger's thread.
In addition, if you have the same event registered to multiple triggers, they will be served in order of registration as s3rius mentioned.
0
SBeiers editor is pretty nice indeed. After checking it out, I would offer this comparison to anyone who is wondering whether they should use NotepadPlusPlus or his editor for scripting Galaxy:
SBeiers editor:
NotepadPlusPlus:
0
I have finished my syntax highlighting and autocomplete files for NotepadPlusPlus and I've decided to release them for public use.
If you've never used NotepadPlusPlus you can find it here: http:notepad-plus-plus.org/
These files include every native and constant from natives.galaxy, NativeLib.galaxy, AI.galaxy and TacticalAI.galaxy as of the current 1.3.0 patch. This is much more up to date and exhaustive than any previously released autocomplete file.
I prefer a darker color theme while scripting because staring at a 100% white screen for 8+ hours can cause eye strain. If you've never used a dark theme for scripting/coding before, I highly suggest you try it out. Below are a couple screenshots to give you an idea of what it looks like:
Of course, if you don't like the style you are free to use the autocomplete file and design your own theme.
If you plan to download this, make SURE you follow the steps in the included readme file. If you have any trouble getting it working after following all of the directions, feel free to post about it here.
Download link: http://bit.ly/e6npsO
Edit: I have created a modified 2nd version of the theme which supports code folding but does not support syntax highlighting for the NativeLib functions. (Those are the ones that begin with libNtve_) It does still autocomplete them, however, they appear in white text like user-defined functions. If you enjoy code folding, you will want to download this version instead.
Download link (folding version): http://bit.ly/gTPu1P
0
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.
0
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.
0
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.
0
That is not nearly enough to lag the game, even if you have a couple hundred units, unless you are doing extremely heavy processing on each unit in the loop... which means you have something severely wrong with your code design.
0
If you want to imagine what the general procedure will be while using this...
0
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.
0
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.