Is there a complete list of all the Galaxy Editor limitations? I would rather not do the grunt work if other people have discovered it. I am looking for things such as the max number of threads, heap limit, stack limit, and any other types of limitations related to triggers/scripting. I would like to mess around with a custom parser and lexer, but need some of these requirements.
@KorvinGump: Go
what do you mean with dynamicly change attributes? if you want to add or remove an point to an attribute you can use a behaviour which changes the attribute and then use catalogs / upgrades to modify the amount.
a set effect can't contain another set effect to bybass the 8 effect limit?
containers are not too hard to use for an X -slot always open inventory.
the line of sight is limited to 16, sightrange can be 32.
"Dynamically change attributes", i mean dynamically change attributes of unit, for example Armored, Biological, Heroic and etc. Currently you can't change it during the game.
Limits #1, #2, and #4 are tied directly to the first limit Jade posted.
SC2 used Fixed precision real numbers, with 19 bits assigned to whole part, and 12 bits assigned to the fractional part, with 1 bit reserved for the sign. This means the largest whole number value that can be represented is 2^19 = 524288 -1 for the sign = 524287. Now you might ask "Why not use floating point to get larger numbers?" Floating point is non deterministic, its behavior is entirely hardware dependent, with different generations of intel and amd cpus doing things slightly different than each other. Non determinism in an RTS = big big no no.
Also you might ask "Why not use 64 bit?" 64 bit wasn't exactly common when SC2 was originally design and even today, making it 64 bit only still makes your application off limits to a not so insignificant market.
At this point, to change such a limitation would break everything. Even the game time itself is stored as a fixed. The ticks occur every 1/16th of a second. 1/16 * 524287 = roughly 9 hours, which is the known time a game will time out.
Text can not be converted to string because text is localized, string is not. When you see a string, the game has looked up the key, and applied the localization to produce the actual viewed text. This is not apparent to most mapmakers because they do not have the time, nor care to do localization.
Map Size is going to be asked for and always be denied. Pathfinding can not handle it, nor can most peoples computers, with the memory requirements. People have asked, saying Wc3 was bigger. Wc3 was not bigger, it just gave a good appearance of it, because its pathfinding resolution was much much lower than SC2.
Nearly all limitations can be derived from the ones Jade has posted
Is it true Blizzard is putting more support towards the GUI, and there is more things you can do in the GUI that you can't with just galaxy? I know that the GUI is just a wrapper for Galaxy, but I think someone had said there are additional features like libraries or something?
I haven't looked at the editor since like WoL Release so just wondering if this is true. Do most people just code using GUI...? If that is true is that because there is no tool for Galaxy? I'm just trying to gather more information before I waste a crap ton of time.
I don't want to write maps using the GUI, but I don't want to write a tool if there is going to be no use for it :P.
Most people do indeed use GUI. GUI permits the interaction with script macros, and many options are enforced via GUI. What GUI really does is write to the triggers.xml, and that file, combined with the galaxy scripts, forms what we see in both the editor and in the game.
The difficulty in creating any tool that interacts with galaxy is that by the very nature of the editor, such a tool will need to be able to read and write to the relevant XML file associated with that galaxy script.
Ultimately, the main things I find, and this is a common issue among all programming tools/langauges, is the lack of examples for certain things, and furthermore, the lack of hosted mods by Blizzard that support various things. For example, a mod that one could include that has a trigger library already setup to do a tower defense game. Things like that seem simple, but having every small block available very much smooths the process of building a game.
Floating point is non deterministic, its behavior is entirely hardware dependent, with different generations of intel and amd cpus doing things slightly different than each other. Non determinism in an RTS = big big no no.
Floating points are deterministic if they follow IEEE specification which any decent compiler should allow. If they perform well enough is another question then as on many platforms they might end up being implemented with hacky software routines which are orders of magnitude slower than native support.
Quote:
Also you might ask "Why not use 64 bit?" 64 bit wasn't exactly common when SC2 was originally design and even today, making it 64 bit only still makes your application off limits to a not so insignificant market.
Internally it does use 64 bits to implement the multiply and division fixed operators. The problem is if the fixed type was 64 bit then it would need a 128 bit intermediate (not natively supported by most processors so will require slow hacky emulation) to compute multiply and division operations. This would be a major reduction in performance. Let us not forget the obvious of double the storage per fixed type in the game (units have dozens of these) so more memory bandwidth and more memory would be used.
Quote:
Wc3 was not bigger, it just gave a good appearance of it, because its pathfinding resolution was much much lower than SC2.
WC3 supported up to 480*480 maps which is considerably bigger than anything SC2 can do. Sure the AI and cloud boxes broke at that size and the map performed like garbage, took forever to load and often was left mostly empty but it still could do it and many late life RPGs took advantage of this massive map size.
Quote:
Is it true Blizzard is putting more support towards the GUI, and there is more things you can do in the GUI that you can't with just galaxy? I know that the GUI is just a wrapper for Galaxy, but I think someone had said there are additional features like libraries or something?
It is not true. Galaxy script directly allows you control over features such as AI, dynamic trigger creation, struct/function/array references etc which are all currently not supported by GUI.
Quote:
What GUI really does is write to the triggers.xml, and that file, combined with the galaxy scripts, forms what we see in both the editor and in the game.
The file triggers.xml is only used by the editor to handle the GUI formatting since information is lost when it is compiled into a galaxy script. In game only galaxy script is run, as proved by the trigger debugger.
Quote:
The difficulty in creating any tool that interacts with galaxy is that by the very nature of the editor, such a tool will need to be able to read and write to the relevant XML file associated with that galaxy script.
There are such files? As far as I am aware SC2 executes all galaxy script that it loads.
Good points all. Though one thing is changing. The GUI is automating so much more in Void that it now does do things that can not be done with straight galaxy. Specifically, it will now auto create presets as constants, and also do function inlining. Also dynamic trigger creation I do not think is done by GUI yet, but dynamic event registration is being added in Void as well, they are finally fixing event definitions and their use. You will be able to register events with a trigger or create custom events that tie multiple native events into a single custom event.
Also, the triggers XML is needed for galaxy compilation, since it is needed to do any form of preprocessor macros. Without it, at all levels, anything that relies on using subfunctions simply wouldn't work. Yes, the game solely uses the compiled galaxy script, but no preprocessor macro = almost nothing would compile to begin with.
I presume 64 bit intermediates are used for multiply and division to avoid loss of precision?
Also, another limit is being removed with Void, you can now alter armor attributes at run time with behaviors.
Also, the triggers XML is needed for galaxy compilation, since it is needed to do any form of preprocessor macros. Without it, at all levels, anything that relies on using subfunctions simply wouldn't work. Yes, the game solely uses the compiled galaxy script, but no preprocessor macro = almost nothing would compile to begin with.
All macros are resolved at map save time? Hence my statement still holds that it is only used by SC2E.
Quote:
I presume 64 bit intermediates are used for multiply and division to avoid loss of precision?
Without them fixed points would only have 16 bits of range which is useless. Even if multiple instructions are needed for the 64bit intermediate (as is the case on 32bit builds such as SC2 2.0) it is still probably faster than using floating points.
Yes, I think I'm phrasing things rather poorly. You can certainly code in straight galaxy and not use any preprocessor macros. However, to do so at this time would be almost pure masochism.
I guess I misunderstood what you mean by GUI formatting. The triggers XML does handle the GUI layout/formatting, but it also handles all compile time restrictions you may wish to impose (limits on parameter values, all macro substitution, preset substitution). I guess it would be more appropriate to say that although one does not NEED that to write code, to do so is self imposing a ton of extra work for no real reason.
Also, as a random aside, they are all improving reference capability.
Also, as a random aside, they are all improving reference capability.
I really hope so. If we could have static references to arrays and structs (references to global members only) which implicitly evaluate as normal references (but not the other way round) then one can really use object orientated programming techniques.
Possibly, but do note, object oriented is no longer all that useful for games, due to the performance hits it incurs. I've been doing some reading, and it appears the idea of designing a program around its data structures yields greater performance, hence the heavy heavy use of the data module in SC2 (data oriented design). With the overhead of scripting, I do not think object oriented coding will ever be a good thing in SC2, even if they do end up improving things to the point of being able to use it.
I keep forgetting this, and you seem to be in the know on the subject, what are the current limitations on references in SC2?
Possibly, but do note, object oriented is no longer all that useful for games, due to the performance hits it incurs. I've been doing some reading, and it appears the idea of designing a program around its data structures yields greater performance, hence the heavy heavy use of the data module in SC2 (data oriented design). With the overhead of scripting, I do not think object oriented coding will ever be a good thing in SC2, even if they do end up improving things to the point of being able to use it.
Actually the reason is because you end up with a hard to maintain mess of classes extending other classes for every single different thing (think WC3 abilities). Instead it can be applied to processing objects which deal with generic data (eg actors, entities or systems) which you can easily and efficiently feed in and modify.
In SC2 the main advantage would be re-usability of code. A few separate instances of a system can be created with a few variables. Different instances of such systems can be linked together. Such systems could easily be included into a map. Most people currently declare all the data the system could possibly use which wastes the limited memory space and does not make it very flexible.
Where it mostly shines is data processing and other indirect components of a map which are complex and standardisable. For example a save/load system could end up with many singleton objects linked together representing encryption functionality, hashing functionality, a high level API to access data and an object representing buffered data to feed in or out of the banks.
Another such system might be a UI system or other functionality which is often desired in an easy to use way. If the user desired two of such an element why could declare the underlying struct twice. Currently such functionality usually comes in hard-coded systems where he would only be able to create 1 such UI element without having to modify every thing piece of system code to support arrays.
Quote:
I keep forgetting this, and you seem to be in the know on the subject, what are the current limitations on references in SC2?
Function references of any function matching the parameters of the prototype declaration are allowed. These can be used anywhere, including locals, globals, function arguments, return type etc. As these are references you cannot hard-code in arguments, all arguments must be provided when calling.
Array and struct references share the same restrictions. Such references can be declared as function parameters and local variables. Can reference both global and local struct declarations of the appropriate type. You cannot declare these references as either a return parameter or a global variable. The reason for the restriction is to prevent one returning a reference to a local struct (memory which has been deallocated so contains garbage).
Array references implicitly include array size information since Galaxy treats array size as type information. Array size types and their references do not allow you to downsize an array (a sub array). Technically downsizing an array is completely safe and even a non-0 origin could be made safe thanks to available size information. Array length incompatibility is a big problem when it comes to system interoperability since even a difference of 1 length (an element which might be optional) will render the systems incompatible and need a bulk copy adapter.
Ok, thank you for that overview. Now I can more confidently state what is being changed in Void.
You can declare Array and Struct refs as return parameters and as globals. If you attempt to return a local struct reference, it will cause a run time error, but I'm assuming they are permitting it, with the understanding that someone who is using such things understands the consequences.
Attached is the 2 Galaxy test scripts that are currently present in Void and Storm. The first I believe tests for things working, the second more focuses on testing for things that should cause an error (error check testing).
Refer to line 983 in DebugGalaxy for examples of StructRefs and ArrayRefs being tested as return parameters. They also test for properly erroring out with local references being returned.
Also, of interest, is 2 other attached test files. One is a test for specific edge cases (Test.Galaxy), the other is a natives unit test as far as I can tell (TestNatives.galaxy).
Perhaps you can infer more from these then what I have, in terms of the changes coming to Void to Galaxy.
You can declare Array and Struct refs as return parameters and as globals. If you attempt to return a local struct reference, it will cause a run time error, but I'm assuming they are permitting it, with the understanding that someone who is using such things understands the consequences.
That is all a lie, it still works just like before.
Quote:
Script failed to compile: Can not use arrayref/structref as a global, a field, or a return value (only as a local or a parameter). (See Trigger Editor for more details)
Tested on version 3.0 (Legacy of the Void engine).
Is there a complete list of all the Galaxy Editor limitations? I would rather not do the grunt work if other people have discovered it. I am looking for things such as the max number of threads, heap limit, stack limit, and any other types of limitations related to triggers/scripting. I would like to mess around with a custom parser and lexer, but need some of these requirements.
Attached is a map with various test scripts, last one testing the thread limit. If no one else gets around to it, I'll test the heap and stack limits.
Thread limit: 2038 (additional threads may be reserved AI)
FIXED TYPE SCALE LIMITS
Fixed type bits: 1 sign, 19 whole, 12 fractional
Fixed type epsilon: 1/4096
Point distance epsilon: 1/4096 length
Update tick interval: 1/16 = 256/4096 game-time seconds
Speed epsilon: 32/4096 length/game-time seconds
Movement epsilon: 2/4096 length/tick
Unit radius epsilon: 1/16 = 256/4096 length
Unit collide epsilon: 1/8 = 512/4096 length
Galaxy Native Type Operator Support
Galaxy Script Data Type Tests
Cool I can always count on you Jade; I appreciate it like always.
If you are interested in other limitations, check this post on reddit https://www.reddit.com/r/sc2editor/comments/1cj2m6/stupid_limitations_of_sc2_editor/.compact. I wrote it 2 years ago, but it's still actual.
http://www.youtube.com/user/RussianMapster
@KorvinGump: Go what do you mean with dynamicly change attributes? if you want to add or remove an point to an attribute you can use a behaviour which changes the attribute and then use catalogs / upgrades to modify the amount.
a set effect can't contain another set effect to bybass the 8 effect limit?
containers are not too hard to use for an X -slot always open inventory.
the line of sight is limited to 16, sightrange can be 32.
i agree with the rest :D
@FunkyUserName: Go
"Dynamically change attributes", i mean dynamically change attributes of unit, for example Armored, Biological, Heroic and etc. Currently you can't change it during the game.
http://www.youtube.com/user/RussianMapster
Limits #1, #2, and #4 are tied directly to the first limit Jade posted.
SC2 used Fixed precision real numbers, with 19 bits assigned to whole part, and 12 bits assigned to the fractional part, with 1 bit reserved for the sign. This means the largest whole number value that can be represented is 2^19 = 524288 -1 for the sign = 524287. Now you might ask "Why not use floating point to get larger numbers?" Floating point is non deterministic, its behavior is entirely hardware dependent, with different generations of intel and amd cpus doing things slightly different than each other. Non determinism in an RTS = big big no no.
Also you might ask "Why not use 64 bit?" 64 bit wasn't exactly common when SC2 was originally design and even today, making it 64 bit only still makes your application off limits to a not so insignificant market.
At this point, to change such a limitation would break everything. Even the game time itself is stored as a fixed. The ticks occur every 1/16th of a second. 1/16 * 524287 = roughly 9 hours, which is the known time a game will time out.
Text can not be converted to string because text is localized, string is not. When you see a string, the game has looked up the key, and applied the localization to produce the actual viewed text. This is not apparent to most mapmakers because they do not have the time, nor care to do localization.
Map Size is going to be asked for and always be denied. Pathfinding can not handle it, nor can most peoples computers, with the memory requirements. People have asked, saying Wc3 was bigger. Wc3 was not bigger, it just gave a good appearance of it, because its pathfinding resolution was much much lower than SC2.
Nearly all limitations can be derived from the ones Jade has posted
Is it true Blizzard is putting more support towards the GUI, and there is more things you can do in the GUI that you can't with just galaxy? I know that the GUI is just a wrapper for Galaxy, but I think someone had said there are additional features like libraries or something?
I haven't looked at the editor since like WoL Release so just wondering if this is true. Do most people just code using GUI...? If that is true is that because there is no tool for Galaxy? I'm just trying to gather more information before I waste a crap ton of time.
I don't want to write maps using the GUI, but I don't want to write a tool if there is going to be no use for it :P.
Most people do indeed use GUI. GUI permits the interaction with script macros, and many options are enforced via GUI. What GUI really does is write to the triggers.xml, and that file, combined with the galaxy scripts, forms what we see in both the editor and in the game.
The difficulty in creating any tool that interacts with galaxy is that by the very nature of the editor, such a tool will need to be able to read and write to the relevant XML file associated with that galaxy script.
Ultimately, the main things I find, and this is a common issue among all programming tools/langauges, is the lack of examples for certain things, and furthermore, the lack of hosted mods by Blizzard that support various things. For example, a mod that one could include that has a trigger library already setup to do a tower defense game. Things like that seem simple, but having every small block available very much smooths the process of building a game.
Floating points are deterministic if they follow IEEE specification which any decent compiler should allow. If they perform well enough is another question then as on many platforms they might end up being implemented with hacky software routines which are orders of magnitude slower than native support.
Internally it does use 64 bits to implement the multiply and division fixed operators. The problem is if the fixed type was 64 bit then it would need a 128 bit intermediate (not natively supported by most processors so will require slow hacky emulation) to compute multiply and division operations. This would be a major reduction in performance. Let us not forget the obvious of double the storage per fixed type in the game (units have dozens of these) so more memory bandwidth and more memory would be used.
WC3 supported up to 480*480 maps which is considerably bigger than anything SC2 can do. Sure the AI and cloud boxes broke at that size and the map performed like garbage, took forever to load and often was left mostly empty but it still could do it and many late life RPGs took advantage of this massive map size.
It is not true. Galaxy script directly allows you control over features such as AI, dynamic trigger creation, struct/function/array references etc which are all currently not supported by GUI.
The file triggers.xml is only used by the editor to handle the GUI formatting since information is lost when it is compiled into a galaxy script. In game only galaxy script is run, as proved by the trigger debugger.
There are such files? As far as I am aware SC2 executes all galaxy script that it loads.
Good points all. Though one thing is changing. The GUI is automating so much more in Void that it now does do things that can not be done with straight galaxy. Specifically, it will now auto create presets as constants, and also do function inlining. Also dynamic trigger creation I do not think is done by GUI yet, but dynamic event registration is being added in Void as well, they are finally fixing event definitions and their use. You will be able to register events with a trigger or create custom events that tie multiple native events into a single custom event.
Also, the triggers XML is needed for galaxy compilation, since it is needed to do any form of preprocessor macros. Without it, at all levels, anything that relies on using subfunctions simply wouldn't work. Yes, the game solely uses the compiled galaxy script, but no preprocessor macro = almost nothing would compile to begin with.
I presume 64 bit intermediates are used for multiply and division to avoid loss of precision?
Also, another limit is being removed with Void, you can now alter armor attributes at run time with behaviors.
All macros are resolved at map save time? Hence my statement still holds that it is only used by SC2E.
Without them fixed points would only have 16 bits of range which is useless. Even if multiple instructions are needed for the 64bit intermediate (as is the case on 32bit builds such as SC2 2.0) it is still probably faster than using floating points.
Yes, I think I'm phrasing things rather poorly. You can certainly code in straight galaxy and not use any preprocessor macros. However, to do so at this time would be almost pure masochism.
I guess I misunderstood what you mean by GUI formatting. The triggers XML does handle the GUI layout/formatting, but it also handles all compile time restrictions you may wish to impose (limits on parameter values, all macro substitution, preset substitution). I guess it would be more appropriate to say that although one does not NEED that to write code, to do so is self imposing a ton of extra work for no real reason.
Also, as a random aside, they are all improving reference capability.
I really hope so. If we could have static references to arrays and structs (references to global members only) which implicitly evaluate as normal references (but not the other way round) then one can really use object orientated programming techniques.
Possibly, but do note, object oriented is no longer all that useful for games, due to the performance hits it incurs. I've been doing some reading, and it appears the idea of designing a program around its data structures yields greater performance, hence the heavy heavy use of the data module in SC2 (data oriented design). With the overhead of scripting, I do not think object oriented coding will ever be a good thing in SC2, even if they do end up improving things to the point of being able to use it.
I keep forgetting this, and you seem to be in the know on the subject, what are the current limitations on references in SC2?
Actually the reason is because you end up with a hard to maintain mess of classes extending other classes for every single different thing (think WC3 abilities). Instead it can be applied to processing objects which deal with generic data (eg actors, entities or systems) which you can easily and efficiently feed in and modify.
In SC2 the main advantage would be re-usability of code. A few separate instances of a system can be created with a few variables. Different instances of such systems can be linked together. Such systems could easily be included into a map. Most people currently declare all the data the system could possibly use which wastes the limited memory space and does not make it very flexible.
Where it mostly shines is data processing and other indirect components of a map which are complex and standardisable. For example a save/load system could end up with many singleton objects linked together representing encryption functionality, hashing functionality, a high level API to access data and an object representing buffered data to feed in or out of the banks.
Another such system might be a UI system or other functionality which is often desired in an easy to use way. If the user desired two of such an element why could declare the underlying struct twice. Currently such functionality usually comes in hard-coded systems where he would only be able to create 1 such UI element without having to modify every thing piece of system code to support arrays.
Function references of any function matching the parameters of the prototype declaration are allowed. These can be used anywhere, including locals, globals, function arguments, return type etc. As these are references you cannot hard-code in arguments, all arguments must be provided when calling.
Array and struct references share the same restrictions. Such references can be declared as function parameters and local variables. Can reference both global and local struct declarations of the appropriate type. You cannot declare these references as either a return parameter or a global variable. The reason for the restriction is to prevent one returning a reference to a local struct (memory which has been deallocated so contains garbage).
Array references implicitly include array size information since Galaxy treats array size as type information. Array size types and their references do not allow you to downsize an array (a sub array). Technically downsizing an array is completely safe and even a non-0 origin could be made safe thanks to available size information. Array length incompatibility is a big problem when it comes to system interoperability since even a difference of 1 length (an element which might be optional) will render the systems incompatible and need a bulk copy adapter.
Ok, thank you for that overview. Now I can more confidently state what is being changed in Void.
You can declare Array and Struct refs as return parameters and as globals. If you attempt to return a local struct reference, it will cause a run time error, but I'm assuming they are permitting it, with the understanding that someone who is using such things understands the consequences.
Attached is the 2 Galaxy test scripts that are currently present in Void and Storm. The first I believe tests for things working, the second more focuses on testing for things that should cause an error (error check testing).
Refer to line 983 in DebugGalaxy for examples of StructRefs and ArrayRefs being tested as return parameters. They also test for properly erroring out with local references being returned.
Also, of interest, is 2 other attached test files. One is a test for specific edge cases (Test.Galaxy), the other is a natives unit test as far as I can tell (TestNatives.galaxy).
Perhaps you can infer more from these then what I have, in terms of the changes coming to Void to Galaxy.
That is all a lie, it still works just like before.
Tested on version 3.0 (Legacy of the Void engine).