It would seem as if the new "output map" doesn't really work as it should, if source and output are the same. It errors with saying that the "attributes"-file cannot be accessed. Although I'm not sure why it needs to access it anyway (for output)?
Fixed an error that apeard if the project input and output map was the same.
Removed a warning about string obfuscation not working in some cases.
Recoded the Search and replace feature
Just in case some of you feels overlooked.. If you posted here, or in a PM, then I have seen your request/report. I might not respond to it unless I need more info though. So if I don't respond to you explicitly, then I have added your request to my todo list.
v2.1.6
Fixed an error that apeard if the project input and output map was the same.
Removed a warning about string obfuscation not working in some cases.
Recoded the Search and replace feature
Just in case some of you feels overlooked.. If you posted here, or in a PM, then I have seen your request/report. I might not respond to it unless I need more info though. So if I don't respond to you explicitly, then I have added your request to my todo list.
Works flawlessly now!
Like I mentined in a previous post, your editor does not support "point + point" and "point - point", whereas plain galaxy does (or should according to the docs). Just mentioning in-case you missed it.
For completeness, specifying a point as const, will cause script error when testing the map (I'm guessing galaxy doesn't support that).
Oh yeah, also, galaxy supports typedef I believe, your editor does not (although, obviously, galaxy wouldn't even need to support it), it would be nice to be able to typedef various types so that one would be able to give more meaning to especially ints (e.g., team=int, dialog=int, etc, etc).
Minor thing, when pressing CTRL-F, to start a search, it would be nice if it would select the content of the "search"-field, so that it can be easily replaced.
Whats the point of selecting an output map? Shouldn't it just create an output map with a specified name? Why would you need to select a file instead of a name?
I looked at how you implement functions in structs (as well as classes) and realized that you use DataTables for that, it seems rather inefficient and pointless, but perhaps I missed something. Point being that, you can pass structures by reference in galaxy, as well as of course creating references to structures... however, it is not possible to create references(&) to structures in your editor (http://www.sc2mapster.com/api-docs/galaxy-language/structs/).
I would expect functions defined in structs to simply be put outside the struct and be reasonably prefixed, and then use the struct reference as the first parameter/argument [e.g.: void test(mystruct* this, int arg1) {...}].
Also, it would be very nice if creating references (&) was made possible too as it is in regular galaxy.
Whats the point of selecting an output map? Shouldn't it just create an output map with a specified name? Why would you need to select a file instead of a name?
Not sure if you are referring specfically to "files as map", or the option itself... I personally use it to compile the scripts back into my source-map folder, so that I can then test from the sc2editor without having to manually copy the output files.
It has been a long time since pointers were avalible in galaxy. On the site you linked there is a comment from Sun, 20 Jun 2010 saying
Quote:
Pointers were taken out completely in patch 9. Way to go, Blizzard.
So there are no * or & in regular galaxy. If you would want to do something like
MyStruct*foo(){MyStructstr;return&str;}
Then my only option is to create a new dynamic type(in the data table), and copy the struct there. I have two issues with that. First, any changes to that dynamic type would not change the variable from the method, and second, it is not apparent that a new variable is created, and thus need to be deleted aswell.
The file or folder you specify doesn't have to be an actual map. If it is a folder, you do need to create it, but it doesn't have to contain any files.
Not sure if you are referring specfically to "files as map", or the option itself... I personally use it to compile the scripts back into my source-map folder, so that I can then test from the sc2editor without having to manually copy the output files.
This would only be an advantage, if you could inject the script, while the map is already open in the SC2 editor, because you could test the map instantly. But thats not possible, it seems, so there is no difference between selecting a map to inject code and creating a new one, at least for map files.
For component lists, this is possible, it seems, so makes sense for folders.
BTW why do you need to specify an output file every time you save (aka press okay another time)? Can't you just use the already saved one?
And please add a "Don't show this again" checkbox for the "Do you want to start the map now" message.
The file or folder you specify doesn't have to be an actual map. If it is a folder, you do need to create it, but it doesn't have to contain any files.
I tested it for a file, and it would not accept a random file name. You cannot even type in a name anywhere; you need to select an actual map.
It has been a long time since pointers were avalible in galaxy. On the site you linked there is a comment from Sun, 20 Jun 2010 saying Quote:
Pointers were taken out completely in patch 9. Way to go, Blizzard.
So there are no * or in regular galaxy. If you would want to do something like
MyStruct*foo(){MyStructstr;returnstr;}
Then my only option is to create a new dynamic type(in the data table), and copy the struct there. I have two issues with that. First, any changes to that dynamic type would not change the variable from the method, and second, it is not apparent that a new variable is created, and thus need to be deleted aswell.
Yay Blizzard.
So, I take it structs now have no actual purpose other than being able to bunch variables together? Or have I missed something vital? They can't be copied, can't be referenced, can't be used as an argument, can't be dynamically allocated.
EDIT: Ok, they can be copied... but I'm not sure what that's actually good for though, other than for creating new immutable types?
Not sure if you are referring specfically to "files as map", or the option itself... I personally use it to compile the scripts back into my source-map folder, so that I can then test from the sc2editor without having to manually copy the output files.
This would only be an advantage, if you could inject the script, while the map is already open in the SC2 editor, because you could test the map instantly. But thats not possible, it seems, so there is no difference between selecting a map to inject code and creating a new one, at least for map files.
For component lists, this is possible, it seems, so makes sense for folders.
BTW why do you need to specify an output file every time you save (aka press okay another time)? Can't you just use the already saved one?
And please add a "Don't show this again" checkbox for the "Do you want to start the map now" message.
Yeah, componentlists was per my request, for sc2maps I'm not sure what the point would be.
Specifying a new output file every time you save seems to be a bug, if you select an output-folder, and restart galaxy, and use "compile and save", it stops asking, but if you ever touch "compile and save as", it won't stop asking until you restart it again.
It has been a long time since pointers were avalible in galaxy. On the site you linked there is a comment from Sun, 20 Jun 2010 saying Quote:
Pointers were taken out completely in patch 9. Way to go, Blizzard.
So there are no * or in regular galaxy. If you would want to do something like
MyStruct*foo(){MyStructstr;returnstr;}
Then my only option is to create a new dynamic type(in the data table), and copy the struct there. I have two issues with that. First, any changes to that dynamic type would not change the variable from the method, and second, it is not apparent that a new variable is created, and thus need to be deleted aswell.
I thought a bit and did a few benchmarks.
Setting a boolean 100.000 times using DataTables, using a one char string suffixed with an integer index... 360ms (slower for larger strings)
Getting a boolean 100.000 times using DataTables, using a one char string suffixed with an integer index... 320ms (slower for larger strings)
Setting a boolean 100.000 times using a global bool, using an integer index... 20ms
Getting a boolean 100.000 times using a global bool, using an integer index... 10ms
Crunching the numbers, first off, using DataTable is more than 18x slower for writing, and 36x slower for reading (note, I have not compensated for the for-loop overhead).
Now, let's assume that every other operation to the DataTable is get/set, that would yield an average of 340ms per 100.000 operations, or 300.000 per second. May seem like a big number... so let's see how many operations that would be for a normal framerate, 300.000/60 = 5.000 operations per frame.
That is not alot considering that there may be a lot of data per struct, as well as reading and writing! Doing a total of 5 operations would yield 1.000 iterations per frame... just for getting and setting the data, NOTHING else. Now of course, we're not doing everything per frame, but exceeding the frame time too much will noticeably affect gameplay.
--
The sad truth about globals is though that Blizzard decided that in the age of wide-spread use of 2GB memory, that 2MB is enough. But it's not really as bad as it sounds, that would equate to 500.000 integers, say, 400.000 to give room for the scripts and everything else.
Native types are 4 bytes, types that are objects consume additional memory depending on their type, but can also share this additional memory if referencing the same data. So, let's say we have a struct with 40 bytes worth of data (that is a lot), that would give us 10.000 objects to work with... a lot more than is needed for most uses. SC2 usually buckles under the pressure of a 1.000 fighting units.
So what I'm proposing is to be able to create struct-pools (user-defined size), each variable in a struct would expand to separate global prefixed variables, each instance in the pool would also be subject to a 1 bool/byte overhead (whether it is allocated or free, or possibly even a handle-count, could also be removed for pools without deallocation). Instead of passing around a struct, an integer is passed around as a makeshift pointer into a pool. All attempts to access a property in a struct would be substituted as "object.property" => "global_struct_pool_property[object_id]".
A pool could work in 3 ways:
Allocation and deallocation is handled entirely by the user (1 byte overhead), can be hard to manage, but could work sufficiently for large-scale but inherently simple housekeeping (which most is in SC2).
Acquire and release increment and decrement a per index-counter (1-4 byte overhead), basic garbage collection, when a struct reference is set, increment, when the reference is reset or leaves the scope, decrement.
No deallocation (faster, no overhead), useful for things like keeping track of players, where an index is never reused, although actual usefulness is debatable.
"Not-really-a-pool", to simply be able to benefit from having struct-integer-ids resolve to global variable arrays, "object.property" => "global_struct_pool_property[object_id]", and let the user deal with allocaton and such. This would be a nice and likely rather simple addition.
EDIT: Crap, posted before I was finished :P
--
I merely propose the implementation of this, if it is wortwhile is up to you. It could be manually implemented right now, but inclusion into the editor would hugely simplify accessing the properties of a struct (and functions inside a struct). Do note, if large amounts of data is intended to be stored in a struct, one could manually use DataTable to do so (perhaps a handy id-helper could be made available, also note that constructors/destructors are available), or it could potentially even be possible to be able to specify specific properties as "DataTable properties".
So, I'm a programmer myself obviously so I'm aware of the work that might go into something like this, I'm merely suggesting it as an improvement.
That is not alot considering that there may be a lot of data per struct, as well as reading and writing! Doing a total of 5 operations would yield 1.000 iterations per frame... just for getting and setting the data, NOTHING else.
What do you mean by iterations? Iterations of what?
My main reason for using the data table is that objects that are not allocated will not take up memory, but if performance is really an issue for people, I can make an option for using arrays instead. I would probably need the user to specify the size of these arrays, since it's impossible to make an algorithm that gives an upper bound of how many objects will be created during computation.
It is no small task though, so I probably wont look into it before my next exam :)
It seems like i cant close the Options dialog by clicking on the X in the top right corner.
It's not a bug, it's a feature.. Nevertheless, to make life a little bit more boring, I'll hide the X in next version ;)
Usually, the X makes people think they can exit without saving changes.. they can't.
What do you mean by iterations? Iterations of what?
My main reason for using the data table is that objects that are not allocated will not take up memory, but if performance is really an issue for people, I can make an option for using arrays instead. I would probably need the user to specify the size of these arrays, since it's impossible to make an algorithm that gives an upper bound of how many objects will be created during computation.
It is no small task though, so I probably wont look into it before my next exam :)
First off, I should note that galaxy-structs should be avoided for something like this, they consume more memory than the sum of their properties. Most likely because they act as references. So, inlining the properties and prefixing them would be beneficial.
1.000 iterations of doing 5 read/writes ;) Aka, if it took 5 read/writes to "update unit data", then you could "update unit data" 1.000 times every frame... with a big if; being that's all the function does... it's very likely to do a lot of other stuff as well, so the real number would be lower. This is mostly an issue during intensive triggers, say, when creating the map, spawning waves, checking win conditions, etc, etc.
Anyway, yeah, fixed pool-size is obviously a must because of how galaxy works. However, you really don't have to implement the hard stuff I wrote there, I'm not even sure all that is necessary.
My point is, if you only simply implement the syntactic sugar, say something like this (just as an example, I haven't thought too deeply about the syntax):
Then that would provide the foundation, allocation/deallocation, etc could be built by the user on-top of that as allocators. And even your allocators could be provided on-top of that (worthless example syntax, but just as an illustration):
pool alloc g_mypool
pool refgc g_mypool
pool basic g_mypool
pool index g_mypool
EDIT: stupid wikicreole not working as it should it seems, there should be a # in-front of each of the lines, and you're meant to use ONE of them.
That would then create an allocator of the specified type bound to the pool, exposing the necessary functions as well (lbasically copy-paste functions). The only one that would really require special attention would be "refgc" if it would "make the cut". Basically, it would require that you monitor the construction and destruction of pool pointers (but even that shouldn't be overly complicated unless I'm mistaken).
As an example, [alloc] would expose "new(...)" and "delete(p)", [refgc] would expose "new(...)", [basic] would expose "new(...)" and "delete(p)" (calls destructor), [index] would expose "get(i)" and "index(p)" (as well as perhaps "construct(i/p)" and "destruct(i/p)", or something like that). Although I'm not sure how useful [index] really is if the others are available, the idea would be to be able to design your own allocator... but not sure if there are good reasons for actually doing that in SC2.
So again, I'd just like to make it clear that I'm not aggressively pushing for this to be implement, simply trying to discuss its usefulness and possibilities.
EDIT: It should be noted that these would actually simulate classes, they would support constructors and optionally destructors.
It appears that your search function doesn't find the last occurance of a match in a file.
I released version 2.1.5.
There were also a couple of minor versions
v2.1.2
v2.1.1
Awesome!
But it won't stop asking to update to 2.1.5.
EDIT: Ah, it updates to 2.1.2, not 2.1.5. It seems that your 2.1.5-release on the FTP is actually 2.1.2.
HI,
what also would be great, if it would be possible to open files outside of your projects.
@syranide2: Go
Err.. I wonder how that happened. Anyway, the correct version should be there now.
@SBeier: Go
It would seem as if the new "output map" doesn't really work as it should, if source and output are the same. It errors with saying that the "attributes"-file cannot be accessed. Although I'm not sure why it needs to access it anyway (for output)?
I made a small upgrade..
v2.1.6
Just in case some of you feels overlooked.. If you posted here, or in a PM, then I have seen your request/report. I might not respond to it unless I need more info though. So if I don't respond to you explicitly, then I have added your request to my todo list.
Works flawlessly now!
Like I mentined in a previous post, your editor does not support "point + point" and "point - point", whereas plain galaxy does (or should according to the docs). Just mentioning in-case you missed it.
For completeness, specifying a point as const, will cause script error when testing the map (I'm guessing galaxy doesn't support that).
Oh yeah, also, galaxy supports typedef I believe, your editor does not (although, obviously, galaxy wouldn't even need to support it), it would be nice to be able to typedef various types so that one would be able to give more meaning to especially ints (e.g., team=int, dialog=int, etc, etc).
Minor thing, when pressing CTRL-F, to start a search, it would be nice if it would select the content of the "search"-field, so that it can be easily replaced.
Some of the string obfuscation stuff is fixed; I can see most of the images and text fields now. Still the obfuscation causes triggers to fail:
The map works partly; some stuff works perfectly fine, other doesn't even show up. None of these problems exist without string obfuscation.
I can not select my codes at the end of my script , which contains Chinese charactres .It happens in v2.16,but not happen in v2.10.
Whats the point of selecting an output map? Shouldn't it just create an output map with a specified name? Why would you need to select a file instead of a name?
I looked at how you implement functions in structs (as well as classes) and realized that you use DataTables for that, it seems rather inefficient and pointless, but perhaps I missed something. Point being that, you can pass structures by reference in galaxy, as well as of course creating references to structures... however, it is not possible to create references(&) to structures in your editor (http://www.sc2mapster.com/api-docs/galaxy-language/structs/).
I would expect functions defined in structs to simply be put outside the struct and be reasonably prefixed, and then use the struct reference as the first parameter/argument [e.g.: void test(mystruct* this, int arg1) {...}].
Also, it would be very nice if creating references (&) was made possible too as it is in regular galaxy.
Not sure if you are referring specfically to "files as map", or the option itself... I personally use it to compile the scripts back into my source-map folder, so that I can then test from the sc2editor without having to manually copy the output files.
@syranide2: Go
It has been a long time since pointers were avalible in galaxy. On the site you linked there is a comment from Sun, 20 Jun 2010 saying
So there are no * or & in regular galaxy. If you would want to do something like
Then my only option is to create a new dynamic type(in the data table), and copy the struct there. I have two issues with that. First, any changes to that dynamic type would not change the variable from the method, and second, it is not apparent that a new variable is created, and thus need to be deleted aswell.
@Kueken531: Go
The file or folder you specify doesn't have to be an actual map. If it is a folder, you do need to create it, but it doesn't have to contain any files.
This would only be an advantage, if you could inject the script, while the map is already open in the SC2 editor, because you could test the map instantly. But thats not possible, it seems, so there is no difference between selecting a map to inject code and creating a new one, at least for map files.
For component lists, this is possible, it seems, so makes sense for folders.
BTW why do you need to specify an output file every time you save (aka press okay another time)? Can't you just use the already saved one?
And please add a "Don't show this again" checkbox for the "Do you want to start the map now" message.
I tested it for a file, and it would not accept a random file name. You cannot even type in a name anywhere; you need to select an actual map.
Yay Blizzard.
So, I take it structs now have no actual purpose other than being able to bunch variables together? Or have I missed something vital? They can't be copied, can't be referenced, can't be used as an argument, can't be dynamically allocated.
EDIT: Ok, they can be copied... but I'm not sure what that's actually good for though, other than for creating new immutable types?
Yeah, componentlists was per my request, for sc2maps I'm not sure what the point would be.
Specifying a new output file every time you save seems to be a bug, if you select an output-folder, and restart galaxy, and use "compile and save", it stops asking, but if you ever touch "compile and save as", it won't stop asking until you restart it again.
Think i found 2 bugs.
After updating, i cant edit the project setting for a existing project, only works for new ones.
It seems like i cant close the Options dialog by clicking on the X in the top right corner.
I thought a bit and did a few benchmarks.
Crunching the numbers, first off, using DataTable is more than 18x slower for writing, and 36x slower for reading (note, I have not compensated for the for-loop overhead).
Now, let's assume that every other operation to the DataTable is get/set, that would yield an average of 340ms per 100.000 operations, or 300.000 per second. May seem like a big number... so let's see how many operations that would be for a normal framerate, 300.000/60 = 5.000 operations per frame.
That is not alot considering that there may be a lot of data per struct, as well as reading and writing! Doing a total of 5 operations would yield 1.000 iterations per frame... just for getting and setting the data, NOTHING else. Now of course, we're not doing everything per frame, but exceeding the frame time too much will noticeably affect gameplay.
--
The sad truth about globals is though that Blizzard decided that in the age of wide-spread use of 2GB memory, that 2MB is enough. But it's not really as bad as it sounds, that would equate to 500.000 integers, say, 400.000 to give room for the scripts and everything else.
Native types are 4 bytes, types that are objects consume additional memory depending on their type, but can also share this additional memory if referencing the same data. So, let's say we have a struct with 40 bytes worth of data (that is a lot), that would give us 10.000 objects to work with... a lot more than is needed for most uses. SC2 usually buckles under the pressure of a 1.000 fighting units.
So what I'm proposing is to be able to create struct-pools (user-defined size), each variable in a struct would expand to separate global prefixed variables, each instance in the pool would also be subject to a 1 bool/byte overhead (whether it is allocated or free, or possibly even a handle-count, could also be removed for pools without deallocation). Instead of passing around a struct, an integer is passed around as a makeshift pointer into a pool. All attempts to access a property in a struct would be substituted as "object.property" => "global_struct_pool_property[object_id]".
A pool could work in 3 ways:
EDIT: Crap, posted before I was finished :P
--
I merely propose the implementation of this, if it is wortwhile is up to you. It could be manually implemented right now, but inclusion into the editor would hugely simplify accessing the properties of a struct (and functions inside a struct). Do note, if large amounts of data is intended to be stored in a struct, one could manually use DataTable to do so (perhaps a handy id-helper could be made available, also note that constructors/destructors are available), or it could potentially even be possible to be able to specify specific properties as "DataTable properties".
So, I'm a programmer myself obviously so I'm aware of the work that might go into something like this, I'm merely suggesting it as an improvement.
What do you mean by iterations? Iterations of what?
My main reason for using the data table is that objects that are not allocated will not take up memory, but if performance is really an issue for people, I can make an option for using arrays instead. I would probably need the user to specify the size of these arrays, since it's impossible to make an algorithm that gives an upper bound of how many objects will be created during computation.
It is no small task though, so I probably wont look into it before my next exam :)
It's under options->Compiler->Never ask to open in the normal editor after save
It's not a bug, it's a feature.. Nevertheless, to make life a little bit more boring, I'll hide the X in next version ;)
Usually, the X makes people think they can exit without saving changes.. they can't.
First off, I should note that galaxy-structs should be avoided for something like this, they consume more memory than the sum of their properties. Most likely because they act as references. So, inlining the properties and prefixing them would be beneficial.
1.000 iterations of doing 5 read/writes ;) Aka, if it took 5 read/writes to "update unit data", then you could "update unit data" 1.000 times every frame... with a big if; being that's all the function does... it's very likely to do a lot of other stuff as well, so the real number would be lower. This is mostly an issue during intensive triggers, say, when creating the map, spawning waves, checking win conditions, etc, etc.
Anyway, yeah, fixed pool-size is obviously a must because of how galaxy works. However, you really don't have to implement the hard stuff I wrote there, I'm not even sure all that is necessary.
My point is, if you only simply implement the syntactic sugar, say something like this (just as an example, I haven't thought too deeply about the syntax):
would translate into
Then that would provide the foundation, allocation/deallocation, etc could be built by the user on-top of that as allocators. And even your allocators could be provided on-top of that (worthless example syntax, but just as an illustration):
pool alloc g_mypool
pool refgc g_mypool
pool basic g_mypool
pool index g_mypool
EDIT: stupid wikicreole not working as it should it seems, there should be a # in-front of each of the lines, and you're meant to use ONE of them.
That would then create an allocator of the specified type bound to the pool, exposing the necessary functions as well (lbasically copy-paste functions). The only one that would really require special attention would be "refgc" if it would "make the cut". Basically, it would require that you monitor the construction and destruction of pool pointers (but even that shouldn't be overly complicated unless I'm mistaken).
As an example, [alloc] would expose "new(...)" and "delete(p)", [refgc] would expose "new(...)", [basic] would expose "new(...)" and "delete(p)" (calls destructor), [index] would expose "get(i)" and "index(p)" (as well as perhaps "construct(i/p)" and "destruct(i/p)", or something like that). Although I'm not sure how useful [index] really is if the others are available, the idea would be to be able to design your own allocator... but not sure if there are good reasons for actually doing that in SC2.
So again, I'd just like to make it clear that I'm not aggressively pushing for this to be implement, simply trying to discuss its usefulness and possibilities.
EDIT: It should be noted that these would actually simulate classes, they would support constructors and optionally destructors.
PS. Good luck with the exam.
This is the script .I can not edit the end part.