I get flooded with error messages for not recognized constants.
The current version 3.1.0 is bugged in that regard as it does not function while the sc2 editor is open (this was my fault). If the sc2 editor is open, the 3.1.0 version has absolutely no information about any sc2 functions or constants making it bug out. I fixed this for the next version, but Beier has not released it yet (like he said: he is busy at the moment).
So, either:
Revert to the version before that and the errors about the missing constants should be gone. But you won't be able to use any new sc2 1.5 features.
Use the Galaxy++ editor only when the sc2 editor is closed. This would make developing pretty annoying.
Apart that, I must say this tool is awesome! I definantly like the namespace feature most.
Well, sorry to say it but Galaxy++ will, most likely, not receive any new features (at least not in the near future). But if you really want them, have a look at the Galaxy++ source, implement them and send them to Beier :)
@Slarti Could you add a new type of compile without the generation of MapScript.galaxy.It takes too long time (always more then 5 min) to generating MapScript.galaxy,. Time maybe waste in assignment of variables` initial values in function.
thanks.
Ps: Do you know the function ref ,struct ref ,and array ref ? these are addied in v1.5 of SE.But there is no GUI for them . You can find script about them in SC2Mapster.
Sorry for my poor English.
Please note that I'm not the one who developed Galaxy++ or the Editor. That credit goes to Beier. I only made a small change to the source. I'm sorry compiling takes so long. You could try to disable the optimization flags in the editor but it is not guaranteed to work. About the "ref" types. You can already use pass-by-reference functionality in Galaxy++. You can find the documentation here or use pointer types.
Basically Galaxy++ emulates many features of 1.5 (see also: function pointers).
I found another function that doesn't work: libNtve_gf_SetDialogItemToggled. The program doesn't recognize it as a valid method (It doesn't highlight it, can't compile it, etc.) It seems to work in 3.1.0, but that version doesn't let me inject. I tried using the native, but the native uses the constant c_triggerControlPropertyToggled, which for some reason is also unrecognized by galaxy + +. :/
I hope that when my patch for 3.1.0 is merged with the Galaxy++ source, those errors will be of the past.
Yeah, working with texts is a little bit fuzzy. You can add localizable text to a map by editing the .txt files (for example "GameStrings.txt") in the "LANGUAGE.SC2Data"/LocalizedData" folder of your map. You can give them any key that you want (not such cryptic names that are autogenerated by the trigger editor) and the editor will not delete them (well at least I have not encountered such a thing happening). Once added to the files, they will also be editable with the wysiwyg Text Editor Module.
Another solution would be to use the new user data types. They can use text, are auto managed by the editor as all the other texts and are readable by triggers (you have to wait until the new galaxy++ version for this).
@elunder: Go
There are two things to account for here. The struct and the array. You can convert your struct (or class, don't know if it has any effect on a struct...) to an array struct by appending [amount] after "struct".
But the array would remain a string since its a dynamic array (has no specific size). If you give it a specific size, it is converted to a real array.
@DieHappy1234: Go
Not exactly sure on what the problem is. Dynamic arrays are using the DataTable, thats why it is a string. Making a dynamic array bigger is pretty much a no op while making them smaller removes entries in a loop which could take time if it's made much smaller so you should avoid that.
Of course having a static array with a predetermined size will be faster than using the datatable but you should only worry about this when you are getting performance problems. Converting a dynamic to a static array is also not that hard so I would go with the dynamic first and see how well it runs.
Functions and Constants are getting parsed and added to the editor. I tried to compile my map with it and it works. The new natives are also available. There are some more things left to do but the basic functionality is done.
But I have a question left. What script files need to be parsed? Right now I parse every ".galaxy" file inside every "Base.SC2Data" mpq inside the "StarCraft II/Mods" folder. Is it enough - is it too much? For example, are the ai galaxy files needed?
Another thing is that map dependencies are ignored right now, so functions from the Liberty.SC2Mod and LibertyMulti.SC2Mod are always added, regardless of whether they are included in the map. I don't think that it's a big problem but a task for the future.
I'm currently editing the Galaxy++ source so that functions are automatically gathered from the various starcraft 2 script files inside the game mpq's. As SBeier said, right now the available functions are hardcoded, so there may be some missing ones. Functions added with 1.5 are also not available yet.
I'm not sure when I will finish this but it's going well so far. So reading the script files and parsing them for functions/constants works already but the integration with the editor is missing. Since I don't really have a good understanding of the project yet, this may take some time.
I haven't worked on it for a long time. I am busy with a new job, another project, and some exams, but truth be told, part of it is probably also that it is not as interesting anymore as it used to be. I think it's time to make the project public. I'm not really sure how is the best way to go about that, but I will keep the server components and the actual server private. One of these days I will look at publicizing it. I don't think I will stop working on it, but if someone else has more time to fix bugs or add features, then they can look at it, and send the changes to me. Then I might decide to include them in an "official" version.
Sad to hear that but it's good that the tool is already in a pretty advanced stage, so it stays usable and I will continue using it. Also I'm really glad that it will not simply get abandoned like Andromeda before this. Making it easy to add native functions would definitely add to its life-span. I will try to take a look at the tool if/when you will make it publicly available and send in some patches but I'm in a similar spot where I don't have that much time.
One way of making it publicly available would be to upload it on bitbucket/github/googlecode/... Then you would have an issue tracker and people could fork your project.
If this tool wouldn't exist, I would have left sc2 mapping already.
Thank you very much for the work you have already done :)
Hey, is there any way to use the new script functions from the arcade beta with g++? I have gotten the editor to start the map with the new version but I'm not able to use the new trigger functions as the editor cannot find the function definitions.
Cool, Thanks. The function references really look like a 1:1 replacement for delegates (they even have a similar syntax..). Btw is there some kind of null check for function references?
The struct references look kind of meh. The <> syntax is pretty verbose and typedef'ing every struct seems like double the work. I think I like the galaxy++ classes and pointers more.
Some interesting tidbits from the alpha 1.5 patch:
Quote:
- Added support for passing structure, array, and function references as function parameters
So there are going to be function references. I Guess this replaces the delegates. I would also be interested to know if the structs are passed by value or by reference when used as parameters (maybe pointers from the beta make a return?). They could make array-based classes/structs more efficient.
The current version 3.1.0 is bugged in that regard as it does not function while the sc2 editor is open (this was my fault). If the sc2 editor is open, the 3.1.0 version has absolutely no information about any sc2 functions or constants making it bug out. I fixed this for the next version, but Beier has not released it yet (like he said: he is busy at the moment).
So, either:
++
editor only when the sc2 editor is closed. This would make developing pretty annoying.Hey, I'm currently not online very often as I don't have internet at home.
Well, sorry to say it but Galaxy
++
will, most likely, not receive any new features (at least not in the near future). But if you really want them, have a look at the Galaxy++
source, implement them and send them to Beier :)Please note that I'm not the one who developed Galaxy
++
or the Editor. That credit goes to Beier. I only made a small change to the source. I'm sorry compiling takes so long. You could try to disable the optimization flags in the editor but it is not guaranteed to work. About the "ref" types. You can already use pass-by-reference functionality in Galaxy++
. You can find the documentation here or use pointer types.Basically Galaxy
++
emulates many features of 1.5 (see also: function pointers).I hope that when my patch for 3.1.0 is merged with the Galaxy
++
source, those errors will be of the past.See here
@elunder: Go
Yeah, working with texts is a little bit fuzzy. You can add localizable text to a map by editing the .txt files (for example "GameStrings.txt") in the "LANGUAGE.SC2Data"/LocalizedData" folder of your map. You can give them any key that you want (not such cryptic names that are autogenerated by the trigger editor) and the editor will not delete them (well at least I have not encountered such a thing happening). Once added to the files, they will also be editable with the wysiwyg Text Editor Module.
Another solution would be to use the new user data types. They can use text, are auto managed by the editor as all the other texts and are readable by triggers (you have to wait until the new galaxy
++
version for this).@elunder: Go There are two things to account for here. The struct and the array. You can convert your struct (or class, don't know if it has any effect on a struct...) to an array struct by appending [amount] after "struct".
But the array would remain a string since its a dynamic array (has no specific size). If you give it a specific size, it is converted to a real array.
@DieHappy1234: Go Not exactly sure on what the problem is. Dynamic arrays are using the DataTable, thats why it is a string. Making a dynamic array bigger is pretty much a no op while making them smaller removes entries in a loop which could take time if it's made much smaller so you should avoid that.
Of course having a static array with a predetermined size will be faster than using the datatable but you should only worry about this when you are getting performance problems. Converting a dynamic to a static array is also not that hard so I would go with the dynamic first and see how well it runs.
I'm really sorry for the problems :(
The new Bugs are a result of my changes and right now it really is the best to revert to 3.0.8. I will work on a bugfix the next days.
@DieHappy1234: Go
Have you opened the Galaxy
++
editor after the sc2 editor? The Galaxy++
editor can't parse for constants while the editor as open.Try to open the Galaxy
++
editor before the sc2 editor.Ok, it works so far.
Functions and Constants are getting parsed and added to the editor. I tried to compile my map with it and it works. The new natives are also available. There are some more things left to do but the basic functionality is done.
But I have a question left. What script files need to be parsed? Right now I parse every ".galaxy" file inside every "Base.SC2Data" mpq inside the "StarCraft II/Mods" folder. Is it enough - is it too much? For example, are the ai galaxy files needed?
Another thing is that map dependencies are ignored right now, so functions from the Liberty.SC2Mod and LibertyMulti.SC2Mod are always added, regardless of whether they are included in the map. I don't think that it's a big problem but a task for the future.
@DieHappy1234: Go
I'm currently editing the Galaxy
++
source so that functions are automatically gathered from the various starcraft 2 script files inside the game mpq's. As SBeier said, right now the available functions are hardcoded, so there may be some missing ones. Functions added with 1.5 are also not available yet.I'm not sure when I will finish this but it's going well so far. So reading the script files and parsing them for functions/constants works already but the integration with the editor is missing. Since I don't really have a good understanding of the project yet, this may take some time.
Sad to hear that but it's good that the tool is already in a pretty advanced stage, so it stays usable and I will continue using it. Also I'm really glad that it will not simply get abandoned like Andromeda before this. Making it easy to add native functions would definitely add to its life-span. I will try to take a look at the tool if/when you will make it publicly available and send in some patches but I'm in a similar spot where I don't have that much time.
One way of making it publicly available would be to upload it on bitbucket/github/googlecode/... Then you would have an issue tracker and people could fork your project.
If this tool wouldn't exist, I would have left sc2 mapping already.
Thank you very much for the work you have already done :)
Hm, my map works fine on the arcade and uses G
++
. Works as always.Hey, is there any way to use the new script functions from the arcade beta with g
++
? I have gotten the editor to start the map with the new version but I'm not able to use the new trigger functions as the editor cannot find the function definitions.Yeah, that makes sense... Wait what? Hopefully a bug, and with even more hope that gets fixed.
Wondering if there is something similar with structrefs/arrayrefs...
Cool, Thanks. The function references really look like a 1:1 replacement for delegates (they even have a similar syntax..). Btw is there some kind of null check for function references?
The struct references look kind of meh. The <> syntax is pretty verbose and typedef'ing every struct seems like double the work. I think I like the galaxy
++
classes and pointers more.Some interesting tidbits from the alpha 1.5 patch:
So there are going to be function references. I Guess this replaces the delegates. I would also be interested to know if the structs are passed by value or by reference when used as parameters (maybe pointers from the beta make a return?). They could make array-based classes/structs more efficient.
Using enums as array indices is still bugged:
Results in
Save as byte <-> load as int