SC2Mapster

Quote from SBeier: Go

So much to do, so little time :( I got some less optional projects demanding time as well..

Hey "haste makes waste", take your time.

Quote from SBeier: Go

@Slarti: Go The reason initializers are in one trigger pr initializer is the limit on the ammount of stuff that can be done in one trigger. With loops and stuff, I have no way of know how much stuff one initializer is doing. Putting them all into one trigger could reach the limit.

Ok this topic is pretty low priority since it works without errors but here is what I mean in more detail:

The following code

Initializer
{
	TriggerDebugOutput(1, "Initializer", true);
}

Trigger TriggerT
{
	events {
		TriggerDebugOutput(1, "Trigger Events", true);
	}
	
	actions {
		TriggerDebugOutput(1, "Trigger Actions", true);
	}
}

Currently translates to this:

trigger InvokeTriggerTInitField = TriggerCreate("InvokeTriggerTInit");
trigger InvokeInitField = TriggerCreate("InvokeInit");

void TriggerTInit();

bool TriggerT(bool testConds, bool runActions)
{
    if(!runActions)
    {
        return true;
    }
    TriggerDebugOutput(1, StringToText("Trigger Actions"), true);
    return true;
}

void TriggerTInit()
{
    TriggerCreate("TriggerT");
    TriggerDebugOutput(1, StringToText("Trigger Events"), true);
    return;
}

void InitMap()
{
    TriggerExecute(InvokeTriggerTInitField, false, true);
    TriggerExecute(InvokeInitField, false, true);
}

bool InvokeInit(bool ranAsync, bool runActions)
{
    if(ranAsync)
    {
        Wait(0, c_timeGame);
    }
    TriggerDebugOutput(1, StringToText("Initializer"), true);
    return true;
}

bool InvokeTriggerTInit(bool ranAsync, bool runActions)
{
    if(ranAsync)
    {
        Wait(0, c_timeGame);
    }
    TriggerTInit();
    return true;
}

While it could compile to something like this:

bool TriggerT(bool testConds, bool runActions)
{
    if(!runActions)
    {
        return true;
    }
    TriggerDebugOutput(1, StringToText("Trigger Actions"), true);
    return true;
}

bool InvokeInit(bool ranAsync, bool runActions)
{
    TriggerDebugOutput(1, StringToText("Initializer"), true);
    return true;
}

bool InvokeTriggerTInit(bool ranAsync, bool runActions)
{
    TriggerCreate("TriggerT");
    TriggerDebugOutput(1, StringToText("Trigger Events"), true);
    return true;
}

void execInitFunc(string name)
{
	trigger initTrigger = TriggerCreate(name);
	TriggerExecute(initTrigger, false, true);
	TriggerDestroy(initTrigger);
}

void InitMap()
{	
	execInitFunc("InvokeInit");
	execInitFunc("InvokeTriggerTInit");
}

The main advantage would be that the triggers required to initialize everything are cleaned up after the initialization is done while also requiring less space. I don't know how much overhead the destruction of triggers costs performance wise but I don't think it's that much.

Maybe the creation of the Galaxy++ Triggers{events{} conditions{} actions{}} could also happen in one function without hitting the execution limit. But again this should be the least of your concerns, since everything is working as it is right now.

OK, here are some more suggestions. Of course everything is subject to discussion and does not have to be useful.

Galaxy++ Language Suggestions

• Operator Overloading: Pretty much as it is used in C++. Maybe there have to be some changes such as the []= operator in vJass for array-assignment.
• Enums: These could be either simple C style enums that are just bytes/shorts/ints (whatever fits) or Java style object enums that are basically classes with predefined instantiations. Behavior for enums would include that they are switch-able. Also using them as array indexes may be useful (requiring a (implicit) enum -> int cast). A cast in the opposite direction should always have to be explicit if it should even be possible. I would vote for the Java style enums so that one can easily associate some data fields with the enums.
• Virtual/Abstract Methods/Interfaces: Allowing to overwrite methods from the superclass. Either allowing to overwrite every method that is defined or having a special keyword (like virtual in C++) to mark methods that they can get overwritten. I'm not sure how it would get implemented (binary if/elses or something like Strilanc has written some pages before this). Also having a better implementation for Delegates would be nice (e.g. binary if/else over ints and not linear if/else over strings).
• Initializers. It seems that a trigger with the default "if (ranAsync) wait" body is created for every Initializer. Since the user can't call these by himself, they could be implemented with only one trigger and a fixed wait(0) at the beginning. The trigger used for the calling of the functions could get deleted after the initialization is done.

Editor Suggestions

Better Navigation/Keyboard Support

Some examples for this (every mentioned key combination is just an example):

• ctrl+arrowkeys to jump over complete words (or over CamelCase word parts as most IDEs are doing it)
• ctrl+shift+arrowkeys to also select the text in between jumps
• Some key to jump up and down between methods (for example: ctrl+alt+up would jump to the previous method/function in the current file)
• Outline support
• "Go To Declaration" support: ctrl+mouse-click on a class/variable/function call and the declaration of it is opened. Of course this would not work for native/libNtve functions.
• Using shift+mousewheel scrolls pages
• Deleting a line: Pressing ctrl+d deletes the lines the are currently selected, if nothing is selected the current line where the carret is, is deleted. Its surprising how useful I find this function in other Editors/IDEs.
• Duplicating content: Pressing ctrl+alt+(up/down) duplicates the currently selected lines above the selection/under the selection. If nothing is selected the line where the cursor is, is duplicated.
• Moving content: Pressing alt+(up/down) move the currently selected lines up and down. If nothing is selected the line where the cursor is, is moved.
• ctrl+Enter creates a new line after the current one

Other

• Templates/Snippets: Allowing to write "for" and the autocompletion would propose to replace it with a for loop. Hitting a special key (like Tab) would jump through specific hotspots like the name of the iteration variable, the loop condition and the loop body. Hard to explain, hope you understand what I mean. Most IDEs have it, the FingerText Plugin for Notepad++ also works like this.
• A Unit Filter Gui: Right now the Galaxy++ Editor is superior to the normal Trigger/Galaxy Editor in nearly every aspect. But when I have to write a unitfilter I am still opening up the Trigger Editor, defining the filter with the gui, and copy pasting the resulting script into the Galaxy++ File. I simply do not know where to put all the c_targetFilterXXX variables. Having a gui like the one for creating Class Constructors would help greatly. But not only should it be possible to crate new filters but also to change existing ones.
• Preprocessor: Well maybe not a full fletched one as the C-Preprocessor but having different compile configurations like release and debug would be nice. When compiling in debug mode, one could disable optimization flags, enable some testing-cheats and debug output.

That should be it for now :)

@Kueken531: Go

Foo[1]* f; would be a pointer to a one dimensional array of Foo structs (not classes). But even if Foo is a struct, that does not work since pointers to fixed size arrays do not exist (pretty much like in C++). Foo[]* f; would work (pointer to a dynamic Foo-struct array).

Arrays with string as index would definitely be useful. I really would like more than strings though, like triggers, units or whatever but I guess the SC2 limitations don't allow for that.

To have a more general way of doing this, I propose Operator Overloading. Then one could write a generic table class with appropriate [] operators taking strings or whatever is wanted. I am also a fan of the << and >> operators in C++ for streams or container classes, (+,-,*,/) for vectors, ...)

Ah ok, misunderstood you there. Yeah, that could be useful, but wouldn't that be a lot of work for something that might not even be used? For me, its a nice-to-have but I can think of a lot of other, more important things.

Quote from Kueken531: Go

Another question: How do I declare and use an array of classes?

For fixed-sized arrays:

Foo*[2] foo;
foo[0] = new Foo();
foo[1] = new Foo();

// if Foo is a struct and not a class this works also
Foo[2] foo;

For dynamically sized arrays:

Foo*[] array = new Foo*[42]();

Quote from Kueken531: Go

Another suggestion: What about showing the injected script in the trigger editor, if you choose to inject the galaxy++ script into the map?

I don't think that looking at the compiled output is of much help since its pretty obfuscated and you can already see that with the import manager.

Quote from Kueken531: Go

You could also include some advertising, like "Want to code like this? Try Galaxy++!" :p This will be helpful for people looking at maps, which use G++

That on the other hand would be quite nice. Maybe you could also let the user define a text that is added to the map, so you could add something like: "If you're looking for the map script source, goto [email protected]"

Quote from SBeier: Go

Woo! Today it is one year since the first release of the editor. :)

Whoo, congrats :)

Btw. is there any kind of roadmap or a list on what you're planning to add to galaxy++ or the editor?

Quote from Kueken531: Go

Quote: The medic heal beam is a huge mess, I don't know exactly, why Blizzard made it the way it is. I am pretty sure, there are easier methods for a similar visual representation.

Oh Yes! It even works differently than the medivacs healing beam. I just had exactly the same problem, and Kueken531 is right, there is an easier way:

• Create a single "Beam (Simple)" Actor based on "Beam Simple Animation Style Continuous". No need for separate "Site" Actors.
• In the "Host Impact" field set the Actor to "Actor Find", the Scope to "Scope Target" and the Subject to "Alias: _Selectable".
• As the "Host Impact Site Ops" choose whatever you want to attach you beam to ("SOpAttachCenter" for example). Do this also for "Host Launch" and "Host Launch Site Ops" but change the Scope to "Scope Source".
• As for the creation event choose "Effect.*YOUREFFECT*.Start" ("Effect.*YOUREFFECT*.Stop" to end it). Remember to set the correct model and it should work.

You can anchor labels to the right of dialogs if you use a style which has a "hjustify" value of "Right" like "RightJustified" (theres also "CenterJustified" if you need it). I see youre using "CreditsPanelLabel" as a style. Thats left aligned. "CreditsPanelValue" is the same, only aligned to the right. You could use that.

@Zarakk: Go looks like the Sons of the Storm webpage. A gallery of the greatest blizzard artists.

@Mogranlocky: Go

I would go for Star Wars as thats a marine frozen in carbonite. So yes, its an Easteregg :D

Another one, does that crashed ship seem familiar? :)

These arent from a particular mission but an easteregg none the less. The "Castanar Monitor Large" has 2 variantions where a blizzard video is played (so it doesnt look very good in a picture...).

That was awesome :D Good find

@38dedo: Go

ah ok that works too :D

One note to the entry of Klishu - "Anakin's Racer": The video is blocked here in germany and we cant watch it because there is music from "Sony Music Entertainment" in there. Would you mind uploading it again without music?