SC2Mapster

Quote from Kueken531: Go

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.

@thedudewithacup: Go

Hey, glad you enjoyed the map. I pretty much agree with your thoughts.

Quote from thedudewithacup: Go

However, we've been stuck now near the alien artifact so I came up with some ideas that will make your map much better. At first, you sould try to make a progress save for characters. We are tired of starting again and again, gaining experience and spec-ing the skills all over again. Could you please try to do something with it?

First of, there are some things currently in the map with which I'm not really happy. The artifact is one of them, so expect some changes to it.

About the progress saving... not sure. I agree that it is a bit annoying to skill everything again, but the idea was that with each new part of the series, the heroes will get stronger (also from the beginning). This does not only include more damage or new skills of the heroes but other systems like items/powerups/whatevericomeupwith. So you could think of the heroes having like 10-15 skillpoints at the start of part 2. I will try to find a way to make the skilling a better experience.

But note that this is not meant to be a full-blown WoW style map (that's what starcraft universe is for). The map is meant to be played from the beginning, and finished in approx. 1 hour (maybe the next parts will take longer, don't know). This makes it easy for new people to get into the map (only having skills in the beginning) and if it was fun for the players, they can play the (not-yet-exisiting) next parts, with every part adding some complexity.

Saving the progress of the heroes will make the balancing much harder. What if a full-level player plays with some new people? Wouldn't that be too easy? I want the first part to be beginner-friendly, not some dota complexity, where when you're a new guy, you get to hear some pretty harsh things about your mother.

Progress saving is maybe something for a later part but would require thorough planning.

Quote from thedudewithacup: Go

And second suggestion: I know that you made a 4-ppl co-op game so the characters must be four in total but this game really lacks of defensive turret-based support characters. We were discussing this with my friends and they agreed.

Agreed. Note that the map is currently a beta. There are currently 2 more heroes planned for the first part (one is a turret/drone kinda guy) and 2 more for the second.

Also, thanks for the input. If you have any more, out with it :) But I have so little time currently that I don't know when I will have the time to continue the work on the map.

Hey, I'm currently not online very often as I don't have internet at home.

Quote from elunder: Go

Another awesome feature would be the foreach loop for unitgroups and playergroups!

Edit: Summing up!

1) declaring multiple GLOBAL variables like "int a, b, c;";

2) initializing string arrays like "string[3] names = { "Hodor", "Brandon", "Robb" };

3) foreach for player/unit-groups

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 :)

Quote from whimsyduke: Go

@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).

Quote from DieHappy1234: Go

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.

Quote from elunder: Go

QUESTION: Why are all trigger initializations run via the "Invoke" function? This feels awefully uneffective...

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.

struct[100] DatabaseEntry
{
    DatabaseCategory Category;
    string Name;
    text Information;
}
DatabaseEntry[100] DatabaseEntries;

@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.

@grim001: Go

Ah, hype much? :)
But really, what is it about? I guess you talk about "cosmos" as you made an equally informative post in the galaxy++ thread.

Any hint on what we can do with it? Regardless, really nice to see that you're doing something for/with sc2

I really like it. Like the other one a nice new theme. Also, the dark yellow/grey fits well with the greenish water.

Now whats left is a map idea where this can be used :)

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.

I'm doing such a thing in my map.
It basically involves a source state (lets say width: 600, height: 600), a target state (width: 10, height:10), a duration for the animation (e.g. 2 seconds) and an easing curve defining the progress of the animation at a specific point in time. For a linear transition this would mean that the animation would be at 50% done at 1 sec but that does not have to be the case for an exponential function. A periodic trigger is then used to run the animation.

If you don't want to go through the trouble of coding such a thing, the transparency of a dialog can already be animated over time, giving a linear "fade out/in" animation.

Quote from FuzzYD: Go

I actually thought of another idea over the last hour. A python class library that buffers code into galaxy, then writes it to a MapScript.galaxy file. It's not quite what I had in mind, but I think it just might work for my little venture. It's a somewhat different principle. Rather than read python script and translate it, it directly uses python to write the file.

Not quite sure what you mean. Something like StringTemplate to define reoccurring structures that directly evaluate to galaxy but easily write them in python? If so ,yes, that would be much easier to implement and could be quite useful as a personal helper tool.

Oh and if its for fun, every solution is good enough :)

Note that writing something like that is a lot of work and you need a lot of time if you want to develop a python->galaxy compiler AND use it to build your maps with.

If you really want to do this you should look for parser/lexer generators. For example ANTLR for java. I don't know if something like this exists for python. For your information Galaxy++ uses SableCC with C# (and if I remember correctly vJass uses GOLD) but there are a lot of other tools for different languages.

With these tools you can define your own language (in form of a grammar and in your case a copy of the python grammar) and use the tools to generate some classes that help you to parse the input language and compile it to something different. But this is not automatically done. You would have to define how the different language constructs are translated which is not that easy with galaxy being the output language.

You would have to think about how to translate classes, ranges, ... to galaxy which does not have these kinds of constructs. You would also have to live without a garbage collector ;)

@EdwardSolomon: Go

Hm, does the UnholyFireGround actor have a wrong alias? Seems to me the selection circle is attaching itself to the model addition actor and not the unit actor and once the UnholyFireGround actor disappears it bugs out. Make sure UnholyFireGround does not have the _Selectable alias or whatever it is called.

@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.