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.
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've spent all day researching exactly how time works in SC2, and I'm here to document the results of my findings.
Ticks Per Second vs Game Speed:
The scripting engine runs with a certain number of ticks per second depending on the current game speed setting. To calculate this, you can simply take the base number of updates per second in normal speed (32) and multiply it by the current game speed modifier (retrievable by using the GameGetSpeed() native). Yes, it actually does use non-integer values for the number of updates per second, so do not round to the nearest integer or your timing calculations will become inaccurate.
Now, about the Wait function. Using either Wait(0, c_timeReal) or Wait(0, c_timeGame) has precisely the same effect: the function will resume during the very next tick. This means that a 0.0 Wait loop will iterate during every single tick of the scripting engine. ANY other value than 0.0 will cause the next tick to be skipped. The number of iterations per second will be decided by your current game speed as shown in the chart above. The actual duration of a Wait 0.0 is equal to the Tick Duration on the chart above. In other words, the speed at which 0.0 loops iterate scales directly with the adjustment of the game speed.
Timers and Wait >0:
Timers and the Wait function when used with non-0 values both share something in common, and that is that they are incapable of expiring on every tick of the scripting engine. They will only expire every OTHER tick. This means that a Wait 0.00001 loop will expire half as quickly as a Wait 0 loop! The minimal expiration time of timers and non-0 wait loops for each game speed is listed in the chart below. If your wait or timer duration isn't a multiple of those values, it may cause a rather large amount of inaccuracy which has the potential to compound in itself if you repeatedly restart the wait or timer.
Here's the first thing you should know: StarCraft 2's perception of real time does not match match your clock's perception of real time. The game engine is meant to pretend that time is not elapsing during any lag or slowdown. If you watch SC2's real time (viewable in the debug menu with an option), it will never progress quite as quickly as a clock, and the more stuff that's going on in your map, the larger the gap will become. If you have large amounts of slowdown, SC2 may believe that time is passing much more slowly than it really is. Also, time does not advance while a player is lagging. During optimal conditions, SC2's real time may fall behind a clock by about 1 second each minute.
Tracking Real Time:
Starcraft 2 lacks a native to return the current amount of elapsed real time. You can use this simple function to do so:
It is possible to view the current elapsed game time by using the native GameGetMissionTime(). However, you can expect 3 strange behaviors out of this native: first, it only updates the time it will return on every other tick of the scripting engine. Second, its time output is directly scaled by the game speed modifier, i.e. in fastest mode, time will pass 40% more quickly. Third, the passage of time will also be influenced by SC2's perception of real time, as described above.
Real Time vs Game Time:
With Waits and Timers, you have the option to use either c_realTime or c_gameTime. As we mentioned before, this distinction has no effect on 0.0 wait timers. It is simply up to you whether you would prefer to have your waits and timers speed up or slow down based on the game speed modifier, or whether you would like for them to expire in the same amount of real time regardless of game speed. There should be different times that each is appropriate.
I will update this guide to contain any new information discovered about the topics addressed above, so feel free to contribute anything else you discover.
0
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.
0
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.
0
I've spent all day researching exactly how time works in SC2, and I'm here to document the results of my findings.
Ticks Per Second vs Game Speed:
The scripting engine runs with a certain number of ticks per second depending on the current game speed setting. To calculate this, you can simply take the base number of updates per second in normal speed (32) and multiply it by the current game speed modifier (retrievable by using the GameGetSpeed() native). Yes, it actually does use non-integer values for the number of updates per second, so do not round to the nearest integer or your timing calculations will become inaccurate.
Wait 0:
Now, about the Wait function. Using either Wait(0, c_timeReal) or Wait(0, c_timeGame) has precisely the same effect: the function will resume during the very next tick. This means that a 0.0 Wait loop will iterate during every single tick of the scripting engine. ANY other value than 0.0 will cause the next tick to be skipped. The number of iterations per second will be decided by your current game speed as shown in the chart above. The actual duration of a Wait 0.0 is equal to the Tick Duration on the chart above. In other words, the speed at which 0.0 loops iterate scales directly with the adjustment of the game speed.
Timers and Wait >0:
Timers and the Wait function when used with non-0 values both share something in common, and that is that they are incapable of expiring on every tick of the scripting engine. They will only expire every OTHER tick. This means that a Wait 0.00001 loop will expire half as quickly as a Wait 0 loop! The minimal expiration time of timers and non-0 wait loops for each game speed is listed in the chart below. If your wait or timer duration isn't a multiple of those values, it may cause a rather large amount of inaccuracy which has the potential to compound in itself if you repeatedly restart the wait or timer.
Real Time:
Here's the first thing you should know: StarCraft 2's perception of real time does not match match your clock's perception of real time. The game engine is meant to pretend that time is not elapsing during any lag or slowdown. If you watch SC2's real time (viewable in the debug menu with an option), it will never progress quite as quickly as a clock, and the more stuff that's going on in your map, the larger the gap will become. If you have large amounts of slowdown, SC2 may believe that time is passing much more slowly than it really is. Also, time does not advance while a player is lagging. During optimal conditions, SC2's real time may fall behind a clock by about 1 second each minute.
Tracking Real Time:
Starcraft 2 lacks a native to return the current amount of elapsed real time. You can use this simple function to do so:
Game Time:
It is possible to view the current elapsed game time by using the native GameGetMissionTime(). However, you can expect 3 strange behaviors out of this native: first, it only updates the time it will return on every other tick of the scripting engine. Second, its time output is directly scaled by the game speed modifier, i.e. in fastest mode, time will pass 40% more quickly. Third, the passage of time will also be influenced by SC2's perception of real time, as described above.
Real Time vs Game Time:
With Waits and Timers, you have the option to use either c_realTime or c_gameTime. As we mentioned before, this distinction has no effect on 0.0 wait timers. It is simply up to you whether you would prefer to have your waits and timers speed up or slow down based on the game speed modifier, or whether you would like for them to expire in the same amount of real time regardless of game speed. There should be different times that each is appropriate.
I will update this guide to contain any new information discovered about the topics addressed above, so feel free to contribute anything else you discover.