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.
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.
Sweet. I thought this project was abandoned. For some reason, when I try to compile, it gives me an error for all the built-in constants, such as c_fixedPrecisionAny.
Actually, after some testing, it won't let me compile at all. I created a new project and tried to compile it without any changes, and it gave me this error: MapScript[5, 18]: Unable to find a matching method. It would give me this error even even when I practically erased everything in that file.
After the update I can't open the editor\game and Galaxy++ at the same time.
If I open the editor first, then Galaxy++ can't get the functions.
If I open Galaxy++ first or trying to test, then the editor\game is stuck on "Preparing game data".
Oh well, going back to 3.0.8. Also, the "PreLoadBank" function doesn't get reconized, parameters do, but the function doesn't. Without the preload, I get a new bank every time.
I'm not 100% positive those will work, and I don't currently have access to a compiler so I can't check. But I think the second one would probably work, it is the C-style method for initializing arrays. The only difference would be that the memory isn't dynamically allocated. But, since you presumably don't intend to ever delete that array (and it's pretty tiny) it shouldn't make a difference.
If I continue to create an entry and store it in the array this will be translated using the DataTableSet... function. This is not really what I want. How can I define an array so it will be used as an array?
For the resize array functions, is it worth using even if the array can go into hundreds? I was using a series of variables to set data for my units, but creating thousands of variables is taxing on the memory. I figured resizing the array would allow the map to allocate however much memory is necessary based on how many units are actually in the map rather than pre-creating so much. Looking at the code, however, it just creates a string variable, which I presume just becomes longer as I increase the array length. Is this still a viable option even with potentially hundreds of arrays?
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.
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.
Ah, alright, that makes sense. Is it possible for dynamic arrays to crash the game through memory overload, or would it stop creating new variables once the limit is reached? Either way, the game would become unplayable at that point, so it doesn't really matter all that much. But theoretically, what would happen?
Thanks Slarti, that worked well. This way of initializing the array does not originate from c, does it? It looks funny ;)
I have another troublesome matter. How do you effectively work with the galaxy++ editor and text? The StringExternal function makes the code so unreadable and I didn't even figure out how to add a text element to the map using the original editor...
Also, group initialization of variables of the same kind woul be nice. Like: int a, b, c;
@Elunder, you actually can declare multiple local variables in one line: int a = 2, b, c = a + 1;
As for the StringExternals, it's how GUI writes strings and texts. Check in the Text Editor and you'll see the strings there. I think if you leave the StringExternals as they are, your galaxy + + script will be able to refer to it (not sure if the GUI deletion will delete the Text Editor files too). If that doesn't work, you'd have to go back and copy-paste all of your strings and texts. :/
Right, declaring multiple variables works. I tried it before and it didn't. No clue what happened. Awesome when problems solve themselves!
Edit: Declaring multible variables only works inside functions, not for global variables.
Bugreport: I have accidentially overwritten the "Color" function which is probably defined in some native library. After I removed my function the compiler couldnt find the original anymore. Had to restart to fix it.
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).
To add colors to text, what I did was define the borders in the text editor and call them using ExternalString. (You can add new ones by copying and pasting, and then editing its contents. You can't change its Data name, so it'll stay something funky.) Then you can concatenate the strings with your texts inside the borders. It's similar to how you would add styles in a forum post like this. It is kind of annoying, so you should create a custom function for this method should you choose to use it.