I meant that the reason they are filled with junk is because it was the wrong patch file. Somewhere should be ones which allow you to extract a non-garbage native list. I think I told you the wrong path to look but I am sure you tried looking for other patch files in other paths right?
For the latest version of the native list at time of posting get it from \StarCraft II\Updates\base\s2-update-base-33553.MPQ where "StarCraft II" is the installation folder.
You can use the native list (extract from the MPQs (CASC in version 3.0 onwards)) for all the native functions to call. Do note that AI natives are declared in separate files from the general trigger natives although they exist in the same pool of available functions for you to call.
Galaxy seems to have use Java style meanings regarding "char" and "byte".
The "char" type represents a single character of a string. It does not evaluate numerically and appears to be a type that was intended for string manipulation purposes but never fully implemented (it appears to have no purpose). It might be used internally by various string natives.
The "byte" type is a non standard C/C++ type representing a 8 bit signed numeric value. It appears to operate similar to the byte type from Java except slightly more restrictive.
There appears to be no 16bit signed type unfortunately meaning you need to waste 2 bytes using an "int". If space is a concern for 16bit types you could always use bit operators to pack 2 different 16bit values into a single int in bitfield style.
Galaxy has very poor implicit type casting. Mixing byte and int with an operator results in a syntax error as only int on int or byte on byte operators are defined. There is also no explicit type casting to get around this. The only way to typecast mid-function appears to be an implicit typecast as a result of variable assignment (int a; a = byte;, byte b; b = int;). This is crucial for array indices as they are only defined for "int" so raise a syntax error when supplied with a byte. Next to these type casting annoyances bytes both function and are packed in memory as expected.
Unless you plan to store a lot of player values so space is an issue, you really should not concern yourself about packing them in a byte rather than an int. SC2 capable systems have so much memory that the maximum heap size of the Galaxy virtual machine is insignificant so memory optimizations are only a concern if the heap limit is a concern.
reasonable. I had no idea struct references and function references were even possible. I use the GUI only because I have a LOT of trouble learning new languages and the GUI just makes it so much easier. I know the purists will hate it but with shortcut keys I think I can program even quicker with the GUI than writing it out.
Writing pure Galaxy is not about productivity, it is about performance and functionality. For example my Imperial Bank system used in the new versions of Undead Assault 3 was written with probably a thousand or so lines of pure Galaxy script because it involved implementing both an AES style encryption and SHA-1 hashes which require a lot of bitwise operations.
Quote:
It really sucks that NONE of this kind of stuff is documented or made easy. Without hearing other people talk about it I would probably have no idea that half the things in the editor even existed or were possible. For example is there somewhere I can learn about the syntax of function references?
Well I was planning on slowly updating the Wiki about it. However I was told that they were in the process of migrating so doing so might result in changes being lost.
I'm only arguing for pointers because they are more basic and would probably require less work to implement. If we could have references then I would be over the moon and the majority of arguments pro-pointer would be removed.
We already do have references... They were added probably over 2 years ago. The only problem is that struct and array references cannot be returned or allocated as a global. The reason for that limitation was to stop a reference to a local existing after function return, something that was possibly overlooked initially when references were implemented.
The solution is (that we all hope for) that it is illegal to assign a global to a reference to a local array or struct and that it is illegal to return such a reference. For safety it could even mark local variable references as dangerous so not able to be returned or copied to global references (to stop people assigning it to a reference to a local and then returning it). There is hope that this will be in SC2 LotV.
Function references are already perfect. Since they are static references they have no issue of invalidation so you can create globals and return them.
You would only disallow user made code. Not the whole engine lol. After all the engine was written in c not galaxy. They could even not include standard libraries and just allow what they have built. Yes pointers could point to invalid stuff, however it would be restricted enough not to be dangerous.The worst that would happen is a possible game crash. In such a case, nobody would play the map. But, I guess playing it safe is usually better.
That entirely depends on what happens with the value. It could propagate a random pointer into the engine which is eventually executed which hackers have engineered to point at the stack which happens to be their virus code etc.
Quote:
I could probably name a list of 25 things that can only be done with pointers, however more than half of them are useless in making a map. Pointers are only used whenever they are required.( at least if they know what they are doing )
Which is what we are talking about. We are not talking about the uses of pointers in C/Cplusplus. We are talking about the uses of pointers in SC2 if you had working references.
Quote:
Personally, I feel they should allow restricted pointers and restricted type casting. Putting a huge warning label on it to only use if you know what you are doing. They could probably even write a script to test the safety of your map before allowing you to publish.
Or they could have disabled pointers like they did. Far easier for them and considerably more safe inherently.
There is hope that the references will be improved in SC2 3.0. It is unclear if the reference test cases in Heroes of the Storm are from when references were first added or if they have revised them so that global and returned references will be allowed.
DISALLOW including anything but standard libraries and remove file access.
I fail to see how SC2 will still operate under those conditions... I mean SC2 needs to read and write files otherwise it cannot load game content, download maps or save banks.
Galaxy is not standard C, it has none of the C standard libraries. Include is only used for trigger libraries and is important for mods I believe.
Quote:
This would prevent any kind of virus from being made.
So would not running SC2. We need to be practical here. You cannot stop SC2 doing file I/O as it needs to do file I/O to work.
Quote:
Sc2 was written in c and therefore, they could make a userCode class and hide all sc2 core data from the user.( several ways of doing it )
For speed the triggers have to run in the same process as the game core. As such they share the same virtual memory address space. As such pointers could threaten to bleed out. Also the main reason against pointers was to stop dynamic code modification to generate galaxy virtual machine instructions that were invalid and themselves could inject invalid and dangerous values into the core. This reason no longer exists however as the code now uses a separate memory bank from data. It could however still be used to generate invalid object references which might not be expected by various natives (violates their contracts).
In any case there is limited use for pointers in SC2. The main ones I hear are for dynamic memory allocation systems but that is really about it. The rest can be done with references if global returned references were supported.
They only do bad things if written badly. Which is easy to do but shouldn't we bear that responsibility?
If they wanted to ensure that we didn't accidentally mess with any of the core SC2 data/code then couldn't they just check the location every time a pointer is dereferenced to make sure it is within the memory section allocated to our own code and data? Better a child safe dumned down pointer than no pointer at all.
Except you could still write nonsense data everywhere inside that space. This would then result in garbage arguments (such as invalid units, strings etc) which might cause all kinds of nonsense. I agree that they do not need to be so strict however I think they were playing it safe after the disaster that happened in WC3. We all remember the type cast exploit and its arbitrary code execution problem.
Quote:
Thanks for the reply. Guess I will just typedef fixed as float. I have used pointers for years and have never had any real issues. Pointers are only bad in the hands of bad programmers( in the case they shouldn't be programming in the first place ) I would be perfectly fine with pointers and am disappointed they aren't supported.
A float is not a fixed for the reasons I highlighted earlier. I would recommend not type casting it to avoid confusion (tread fixed as its own type, float should be for real floats).
The issue is that unlike real software where you never download it if you do not trust it, SC2 maps are quite the opposite. People join a map expecting it to be safe so if someone turns a map into a Trojan which infects their PC with key loggers (to steal credit details and WoW password, what else?) they will be very surprised. Pointers are one of the most notorious exploits for doing malicious stuff with which is why as a good programmer you should rather use references or make sure that the pointer is always valid and that array indices never exceed the array maximum size.
Quote:
No that would give very poor performance, what they could do is set compile time restrictions on pointers, like prevent accessing pointers or taking address of sc2 core data.
Not possible since pointers are naturally dynamic in nature. If a pointer is constant then it should compile to a static reference anyway to save on the dereferencing overhead.
The main issue was that you could alter trigger code dynamically since back then they had both code and global heap sharing the same address space. God knows what errors you could have done with that and I doubt they wanted anyone to find out since it may have lead to another WC3 situation.
Quote:
Pointers very much do help with those things. No body would be forced to use them. I'm sure if Blizzard put a warning on them in the GUI telling them that it is an advanced tool and that they need not be touched unless you know what you're doing.
Actually pointers are not recommended due to them being inherently unsafe. This is why Cplusplus introduced references which are considerably more safe and recommended for use when possible.
The only time you really should be using pointers is if you actually need low level data manipulation. Compilers can often convert complex pointer typecast messes that convert data formats into highly optimized assembly code. An example being for endian conversion or for I/O of a struct from an input buffer. C uses pointers only because it has nothing else to use since it is not really a safe object orientated language.
Well it feels like a waste of space to typedef an int[2] to use it as a float/double
You typedef int as float and int[2] as double. The source code space wastage and compile time is of no concern (creating actors and preloading assets usually takes most of the load time). No space is wasted as far as compiled memory goes floats are as long as an int and doubles twice as long as a float.
Quote:
It also takes more cpu to do the math this way.
In order for the game results to remain deterministic across different platforms the floating point units of CPUs cannot be used. WC3 is an example of when they were not used and it is one of the reasons why desyncs between MAC and Windows versions of WC3 occur so much. Since software emulation is the only deterministic alternative that supports multiple platforms they choose not to support the float type for the reason you mentioned.
Quote:
If I recall the editor had floats, are they just an int[2]?
SC2E does not have floats. It has "fixed" which is called "real" in GUI. WC3 had single precision floats in the form of a "real".
Quote:
Also what is the fixed type?
A fixed point number type that automatically re-adjusts precision after every native operation. The type itself is 32bits (same length as int) with a precision that I am unsure of (guessing either 8 or 10 bit?). For precision I am guessing 64bit "long int" intermediates are used with the result being sifted to appropriate precision and high 32bits truncated.
Fixed point numbers are an alternative to floats for representing fractional units on computer systems. As the name implies, they are what you get if you remove the exponent component from floats so that the scale is always "fixed" (hence the name). The main difference is in the division of numeric numbers since floats have them spaced with a semi-exponential difference where as fixed have them all spaced evenly across the range. Further more floats have a number of "special" values that are useful for advanced mathematics such as infinity and undefined that are not supported by fixed point. In theory fixed point numbers should always compute faster since they use standard integer operations with less complex logic however on x86 systems with 32bit long fixed point fields this requires the use of a 64bit field which probably slows it down.
Quote:
How are strings defined?
As complex objects outside of the virtual machine. Similar to Java.
Quote:
How are strings done here?
Complex objects that are automatically managed. Recycled when no references to them exist.
Quote:
Are the strings NULL terminated?
Yes they are. Although it is only of concern if you are constructing strings with them.
Can I still do pointer arithmetic with arrays?((an array is practically a pointer) get a new array starting at an index without copying)
EX: int* i = new int[50];
(i+2)
or
&i[2]
I will repeat what I said. Pointers are disabled for security reasons although the virtual machine must use them internally. Arrays are special typed structures (not pointers) so behave differently (they are also size checked as a result). It is not possible to get a subset of an array due to the inability to typecast. Also the code you gave is Cplusplus code as classic C does not have "new" keyword (you need to malloc new memory space).
Quote:
Getting pointer to array at element possible?
I will repeat what I said earlier. Pointers are disabled for security reasons. They used to be usable in the WoL Beta but were disabled by the time the editor arrived. The main issue back then was you could use them for dynamic code manipulation due to code and heap sharing the same address space. Now they are separate but still disabled because you can do all manner of buggy things (array bounds checking obviously comes from the type and a pointer would have no bounds). They have provided references for you to use however (Cplusplus style).
Quote:
No dynamic memory allocation? Run out of memory?
All memory must be statically allocated on the main heap. This heap is limited to several megabytes so in practice is pretty much impossible to fill unless you do silly or bad things. Since there is no malloc and no generic pointers it is not possible to allocate memory dynamically. You can simulate dynamic memory using the data table natives which act as massive hashtables but be aware that this drives down speed to interpreted levels.
Quote:
How are you supposed to do any sort of math?(float,double)
What does a lack of float/double have to do with the inability to do maths? As far as I can tell int works perfectly. This gives you many ways.
Use the fixed type for numbers in a small range.
Use ints for whole numbers.
Create an extended int type from an int array with special function calls for operators for higher range whole number computations.
Create an extended fixed type from an int array with special function calls for operators for higher precision and range fractional computations.
Create a set of functions that manipulate ints treating them as floats. The mathematics involved is the same as used by embedded systems which lack floating point units to do floating point calculations.
Create an int[2] array called double and a set of operator functions to manipulate it as if it were a double precision floating point.
Create an int[4] array of type longdouble and a set of operator function to manipulate it as if it were a quad precision floating point.
Create a set of operator function that take strings representing variable length and precision numbers in decimal form and returns a new string of the result. This is probably the slowest but most dynamic precision you get since there is no issue with allocating large numbers of strings thanks to garbage recycling.
Quote:
Are enums, ctors, dtors supported?
There are no enums as the concept of an enum is generally something refined in Cplusplus. I have no idea what a ctors and a dtors is and Google returns no meaningful results. If you meant "constructors" and "destructors" then clearly not as those are Cplusplus features and as I already stated Galaxy is based on classic C with only simple Cplusplus style references being added as an alternative to pointers..
Quote:
Does the this pointer exist?
Yes it does exist. I have a feeling it is even used internally as part of the virtual machine. However it is disabled from use and trying to use it will throw a specifically created syntax error informing you that pointers are not supported. They were in WoL beta and is why much old Galaxy documentation still references them as a language feature however since the time the editor was added into the WoL beta they have not worked.
Is there some kind of documentation on all the different functions/methods there are in galaxy?
Yes and no. GUI offers some documentation for some of the calls (as GUI actions/functions often map 1:1 with natives). The native declaration file also has some documentation including some of the language mechanics. However at least half of the natives are undocumented entirely and have unexpected behaviour for their arguments.
Quote:
Some documentation on syntax and comparisons to other programming languages would be nice.
Galaxy is basically a tamed down version of C. Learn C and you learn Galaxy. There are a few exceptions however.
Due to the lack of unsigned type bitwise right shift is always signed.
Bitwise left and right shift modulus the shift amount by the underlying type size so it is impossible to shift an "int" to be clear.
For security reason pointers are disabled. They do exist inside the code and did work back in WoL beta but were removed due to their ability to do bad things to data and code.
Explicit typecasting is not supported. This is especially important if you use bytes to save memory as you cannot use them as array indices or perform arithmetic operators on ints with them.
Arrays are defined as a type. This is different from C where they are defined as part of the name.
Type references are supported which function similar to Cplusplus references. This allows structs, arrays and functions to be passed as arguments to some extent. Do note that struct and array references cannot be declared globally or as return arguments for security reasons.
There are no C standard libraries. The only functions you can call are natives. This means that dynamic memory in the form of malloc is not supported.
Some bitwise operators have been reported to behave incorrectly on fixed point type. I have not tried this personally however as generally you use int when using bitwise operators.
Multiline comments are not supported.
The revision of C that galaxy is based on is old. As such you can only declare locals at the start of a function (like JASS in WC3).
It is not possible to have implicit single line blocks. All blocks like if, while and for must fully open/close their block and place the code inside.
There is no short (2 byte) and long (8 byte) types.
There is no native floating point support. This is probably to avoid the platform dependant nature of floating points.
I meant that the reason they are filled with junk is because it was the wrong patch file. Somewhere should be ones which allow you to extract a non-garbage native list. I think I told you the wrong path to look but I am sure you tried looking for other patch files in other paths right?
They are not all filled with junk, you must just be looking in the wrong place.
I had a similar issue, keep trying different latest patch file MPQs until you find one that works.
You need "natives.galaxy". This is in "TriggerLibs" of the "base" mod.
For the latest version of the native list at time of posting get it from \StarCraft II\Updates\base\s2-update-base-33553.MPQ where "StarCraft II" is the installation folder.
You can use the native list (extract from the MPQs (CASC in version 3.0 onwards)) for all the native functions to call. Do note that AI natives are declared in separate files from the general trigger natives although they exist in the same pool of available functions for you to call.
Galaxy seems to have use Java style meanings regarding "char" and "byte".
The "char" type represents a single character of a string. It does not evaluate numerically and appears to be a type that was intended for string manipulation purposes but never fully implemented (it appears to have no purpose). It might be used internally by various string natives.
The "byte" type is a non standard C/C
++
type representing a 8 bit signed numeric value. It appears to operate similar to the byte type from Java except slightly more restrictive.There appears to be no 16bit signed type unfortunately meaning you need to waste 2 bytes using an "int". If space is a concern for 16bit types you could always use bit operators to pack 2 different 16bit values into a single int in bitfield style.
Galaxy has very poor implicit type casting. Mixing byte and int with an operator results in a syntax error as only int on int or byte on byte operators are defined. There is also no explicit type casting to get around this. The only way to typecast mid-function appears to be an implicit typecast as a result of variable assignment (int a; a = byte;, byte b; b = int;). This is crucial for array indices as they are only defined for "int" so raise a syntax error when supplied with a byte. Next to these type casting annoyances bytes both function and are packed in memory as expected.
Unless you plan to store a lot of player values so space is an issue, you really should not concern yourself about packing them in a byte rather than an int. SC2 capable systems have so much memory that the maximum heap size of the Galaxy virtual machine is insignificant so memory optimizations are only a concern if the heap limit is a concern.
Writing pure Galaxy is not about productivity, it is about performance and functionality. For example my Imperial Bank system used in the new versions of Undead Assault 3 was written with probably a thousand or so lines of pure Galaxy script because it involved implementing both an AES style encryption and SHA-1 hashes which require a lot of bitwise operations.
Well I was planning on slowly updating the Wiki about it. However I was told that they were in the process of migrating so doing so might result in changes being lost.
It basically goes as follows.
We already do have references... They were added probably over 2 years ago. The only problem is that struct and array references cannot be returned or allocated as a global. The reason for that limitation was to stop a reference to a local existing after function return, something that was possibly overlooked initially when references were implemented.
The solution is (that we all hope for) that it is illegal to assign a global to a reference to a local array or struct and that it is illegal to return such a reference. For safety it could even mark local variable references as dangerous so not able to be returned or copied to global references (to stop people assigning it to a reference to a local and then returning it). There is hope that this will be in SC2 LotV.
Function references are already perfect. Since they are static references they have no issue of invalidation so you can create globals and return them.
That entirely depends on what happens with the value. It could propagate a random pointer into the engine which is eventually executed which hackers have engineered to point at the stack which happens to be their virus code etc.
Which is what we are talking about. We are not talking about the uses of pointers in C/Cplusplus. We are talking about the uses of pointers in SC2 if you had working references.
Or they could have disabled pointers like they did. Far easier for them and considerably more safe inherently.
There is hope that the references will be improved in SC2 3.0. It is unclear if the reference test cases in Heroes of the Storm are from when references were first added or if they have revised them so that global and returned references will be allowed.
I fail to see how SC2 will still operate under those conditions... I mean SC2 needs to read and write files otherwise it cannot load game content, download maps or save banks.
Galaxy is not standard C, it has none of the C standard libraries. Include is only used for trigger libraries and is important for mods I believe.
So would not running SC2. We need to be practical here. You cannot stop SC2 doing file I/O as it needs to do file I/O to work.
For speed the triggers have to run in the same process as the game core. As such they share the same virtual memory address space. As such pointers could threaten to bleed out. Also the main reason against pointers was to stop dynamic code modification to generate galaxy virtual machine instructions that were invalid and themselves could inject invalid and dangerous values into the core. This reason no longer exists however as the code now uses a separate memory bank from data. It could however still be used to generate invalid object references which might not be expected by various natives (violates their contracts).
In any case there is limited use for pointers in SC2. The main ones I hear are for dynamic memory allocation systems but that is really about it. The rest can be done with references if global returned references were supported.
Except you could still write nonsense data everywhere inside that space. This would then result in garbage arguments (such as invalid units, strings etc) which might cause all kinds of nonsense. I agree that they do not need to be so strict however I think they were playing it safe after the disaster that happened in WC3. We all remember the type cast exploit and its arbitrary code execution problem.
A float is not a fixed for the reasons I highlighted earlier. I would recommend not type casting it to avoid confusion (tread fixed as its own type, float should be for real floats).
The issue is that unlike real software where you never download it if you do not trust it, SC2 maps are quite the opposite. People join a map expecting it to be safe so if someone turns a map into a Trojan which infects their PC with key loggers (to steal credit details and WoW password, what else?) they will be very surprised. Pointers are one of the most notorious exploits for doing malicious stuff with which is why as a good programmer you should rather use references or make sure that the pointer is always valid and that array indices never exceed the array maximum size.
Not possible since pointers are naturally dynamic in nature. If a pointer is constant then it should compile to a static reference anyway to save on the dereferencing overhead.
The main issue was that you could alter trigger code dynamically since back then they had both code and global heap sharing the same address space. God knows what errors you could have done with that and I doubt they wanted anyone to find out since it may have lead to another WC3 situation.
Actually pointers are not recommended due to them being inherently unsafe. This is why Cplusplus introduced references which are considerably more safe and recommended for use when possible.
The only time you really should be using pointers is if you actually need low level data manipulation. Compilers can often convert complex pointer typecast messes that convert data formats into highly optimized assembly code. An example being for endian conversion or for I/O of a struct from an input buffer. C uses pointers only because it has nothing else to use since it is not really a safe object orientated language.
You typedef int as float and int[2] as double. The source code space wastage and compile time is of no concern (creating actors and preloading assets usually takes most of the load time). No space is wasted as far as compiled memory goes floats are as long as an int and doubles twice as long as a float.
In order for the game results to remain deterministic across different platforms the floating point units of CPUs cannot be used. WC3 is an example of when they were not used and it is one of the reasons why desyncs between MAC and Windows versions of WC3 occur so much. Since software emulation is the only deterministic alternative that supports multiple platforms they choose not to support the float type for the reason you mentioned.
SC2E does not have floats. It has "fixed" which is called "real" in GUI. WC3 had single precision floats in the form of a "real".
A fixed point number type that automatically re-adjusts precision after every native operation. The type itself is 32bits (same length as int) with a precision that I am unsure of (guessing either 8 or 10 bit?). For precision I am guessing 64bit "long int" intermediates are used with the result being sifted to appropriate precision and high 32bits truncated.
Fixed point numbers are an alternative to floats for representing fractional units on computer systems. As the name implies, they are what you get if you remove the exponent component from floats so that the scale is always "fixed" (hence the name). The main difference is in the division of numeric numbers since floats have them spaced with a semi-exponential difference where as fixed have them all spaced evenly across the range. Further more floats have a number of "special" values that are useful for advanced mathematics such as infinity and undefined that are not supported by fixed point. In theory fixed point numbers should always compute faster since they use standard integer operations with less complex logic however on x86 systems with 32bit long fixed point fields this requires the use of a 64bit field which probably slows it down.
As complex objects outside of the virtual machine. Similar to Java.
Complex objects that are automatically managed. Recycled when no references to them exist.
Yes they are. Although it is only of concern if you are constructing strings with them.
I will repeat what I said. Pointers are disabled for security reasons although the virtual machine must use them internally. Arrays are special typed structures (not pointers) so behave differently (they are also size checked as a result). It is not possible to get a subset of an array due to the inability to typecast. Also the code you gave is Cplusplus code as classic C does not have "new" keyword (you need to malloc new memory space).
I will repeat what I said earlier. Pointers are disabled for security reasons. They used to be usable in the WoL Beta but were disabled by the time the editor arrived. The main issue back then was you could use them for dynamic code manipulation due to code and heap sharing the same address space. Now they are separate but still disabled because you can do all manner of buggy things (array bounds checking obviously comes from the type and a pointer would have no bounds). They have provided references for you to use however (Cplusplus style).
All memory must be statically allocated on the main heap. This heap is limited to several megabytes so in practice is pretty much impossible to fill unless you do silly or bad things. Since there is no malloc and no generic pointers it is not possible to allocate memory dynamically. You can simulate dynamic memory using the data table natives which act as massive hashtables but be aware that this drives down speed to interpreted levels.
What does a lack of float/double have to do with the inability to do maths? As far as I can tell int works perfectly. This gives you many ways.
There are no enums as the concept of an enum is generally something refined in Cplusplus. I have no idea what a ctors and a dtors is and Google returns no meaningful results. If you meant "constructors" and "destructors" then clearly not as those are Cplusplus features and as I already stated Galaxy is based on classic C with only simple Cplusplus style references being added as an alternative to pointers..
Yes it does exist. I have a feeling it is even used internally as part of the virtual machine. However it is disabled from use and trying to use it will throw a specifically created syntax error informing you that pointers are not supported. They were in WoL beta and is why much old Galaxy documentation still references them as a language feature however since the time the editor was added into the WoL beta they have not worked.
Yes and no. GUI offers some documentation for some of the calls (as GUI actions/functions often map 1:1 with natives). The native declaration file also has some documentation including some of the language mechanics. However at least half of the natives are undocumented entirely and have unexpected behaviour for their arguments.
Galaxy is basically a tamed down version of C. Learn C and you learn Galaxy. There are a few exceptions however.