Is there some kind of documentation on all the different functions/methods there are in galaxy? Some documentation on syntax and comparisons to other programming languages would be nice.
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.
Thanks for the reply. I still have a few questions though.
For security reason pointers are disabled.
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]
Explicit typecasting is not supported
Wow...
Arrays are defined as a type.
Getting pointer to array at element possible?
There are no C standard libraries.
No dynamic memory allocation? Run out of memory?
There is no native floating point support.
How are you supposed to do any sort of math?(float,double)
Are enums, ctors, dtors supported?
Does the this pointer exist?
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.
What does a lack of float/double have to do with the inability to do maths?
Well it feels like a waste of space to typedef an int[2] to use it as a float/double. It also takes more cpu to do the math this way. If I recall the editor had floats, are they just an int[2]? Also what is the fixed type?
How are strings defined? In C it is just an array of characters: char buffer[255];
How are strings done here? Are the strings NULL terminated?
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.
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.
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.
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.
"They only do bad things if written badly. Which is easy to do but shouldn't we bear that responsibility?"
Agreed.
"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."
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.
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 )
"They only do bad things if written badly. Which is easy to do but shouldn't we bear that responsibility?" Agreed.
Problem is... most people who mapmake are NOT programmers. And most of the point of the GUI editor in the first place is so that you have to know as little as code as possible (same with data editor). There is a reason managed languages were created and are fairly popular. Pointers are purely for performance reasons (less memory usage, faster execution, smaller code), but for a large number of applications, performance is last on the list. Things like modularity, readability, maintainability are all just as important. Few will care about good performance if the cost to change the code is significant, and many have run into that issue.
For that reason, along with security, pointers are basically unnecessary in SC2. From what I've seen, most maps would benefit from basic code refactors, and data abstraction (placing stuff in User Types, rethinking algorithms, better modularity),
Things like modularity, readability, maintainability are all just as important.
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.
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.
Yes references are safer than pointers, I use references if possible. However, there are many cases were pointers are required. I am not going to through the list of how many things you cant do without pointers, but it is long. About the trojan thing, that is a very easy fix. DISALLOW including anything but standard libraries and remove file access. This would prevent any kind of virus from being made. 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 ) There would be no way to exploit the user, other than possibly crashing the game. DLL injects, windows libraries, COM, writing to memory addresses, and everything particularity dangerous would be hidden and unusable.
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.
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.
"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."
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 )
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.
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.
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.
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.
I'm not pro-pointer, I'm pro- being able to properly pass around handles for data.
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.
Alright I guess this is manageable. The biggest things for me is going to be the explicit type casting and pointers. However, I should be able to adjust and get much better performance doing galaxy. Also, I hate browsing through those dumb dialogs lol. I will begin to try to understand galaxy and how implement it.
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.
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.
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?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Is there some kind of documentation on all the different functions/methods there are in galaxy? Some documentation on syntax and comparisons to other programming languages would be nice.
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.
Thanks for the reply. I still have a few questions though.
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]
Wow...
Getting pointer to array at element possible?
No dynamic memory allocation? Run out of memory?
How are you supposed to do any sort of math?(float,double)
Are enums, ctors, dtors supported?
Does the this pointer exist?
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.
Thanks for the reply.
What does a lack of float/double have to do with the inability to do maths?
Well it feels like a waste of space to typedef an int[2] to use it as a float/double. It also takes more cpu to do the math this way. If I recall the editor had floats, are they just an int[2]? Also what is the fixed type?
How are strings defined? In C it is just an array of characters: char buffer[255]; How are strings done here? Are the strings NULL terminated?
I feel like many of your questions will answer themselves once you spend 10 minutes in the editor and take a look and the resources already provided.
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.
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.
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.
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.
"They only do bad things if written badly. Which is easy to do but shouldn't we bear that responsibility?" Agreed.
"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."
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.
Problem is... most people who mapmake are NOT programmers. And most of the point of the GUI editor in the first place is so that you have to know as little as code as possible (same with data editor). There is a reason managed languages were created and are fairly popular. Pointers are purely for performance reasons (less memory usage, faster execution, smaller code), but for a large number of applications, performance is last on the list. Things like modularity, readability, maintainability are all just as important. Few will care about good performance if the cost to change the code is significant, and many have run into that issue.
For that reason, along with security, pointers are basically unnecessary in SC2. From what I've seen, most maps would benefit from basic code refactors, and data abstraction (placing stuff in User Types, rethinking algorithms, better modularity),
@ArcaneDurandel: Go
Things like modularity, readability, maintainability are all just as important.
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.
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.
Yes references are safer than pointers, I use references if possible. However, there are many cases were pointers are required. I am not going to through the list of how many things you cant do without pointers, but it is long. About the trojan thing, that is a very easy fix. DISALLOW including anything but standard libraries and remove file access. This would prevent any kind of virus from being made. 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 ) There would be no way to exploit the user, other than possibly crashing the game. DLL injects, windows libraries, COM, writing to memory addresses, and everything particularity dangerous would be hidden and unusable.
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.
@ImperialGood: Go
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.
"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." 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 )
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.
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.
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.
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.
I'm not pro-pointer, I'm pro- being able to properly pass around handles for data.
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.
Alright I guess this is manageable. The biggest things for me is going to be the explicit type casting and pointers. However, I should be able to adjust and get much better performance doing galaxy. Also, I hate browsing through those dumb dialogs lol. I will begin to try to understand galaxy and how implement it.
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.
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.
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?