SC2Mapster

Bug: Backup folders are not removed in a relocated project with a component list as input map.

Today I learned something new about Galaxy Script. You can only use ints as array indices and no bytes/shorts. This results in errors with enum -> int conversions:

text[1] enumToTextArray;

Initializer {
	enumToTextArray[(int) Enum.ENUMVALUE] = "ENUMVALUE Description";
	
	// class only there so it does not get inlined
	FooBar* f = new FooBar();
	Enum e = f->e;
	TriggerDebugOutput(1, enumToTextArray[(int) e], true);
}

enum Enum {
	ENUMVALUE
}

class FooBar {
	Enum e = Enum.ENUMVALUE;
}

Turns into:

string f;
    enumToTextArray[0] = StringToText("ENUMVALUE Description");
    f = CreateNewObject();
    DataTableSetByte(true, f + ".e", 0);
    TriggerDebugOutput(1, enumToTextArray[DataTableGetByte(true, f + ".e")], true);
    return true;

This throws an error when starting sc2 "Array index require an integer value". I guess the easiest way to fix it would be to only use ints when converting from enums and no bytes/shorts... Sucks, but is not too bad.

Quote from SBeier: Go

@Slarti: Go Hmm.. wouldn't really call it a bug. It's meant to overload binary operators, and it's not syntactically correct to write 2*3; Still, I might be able to relax that for custom operators.

Yeah, you're right. My usecase is more like a "+=". Maybe I should wait for unary operator overloading. Also on the same note: do you have any plans for operator overloading via class methods? Problem is: I would like to overload an operator for a generic class but I don't think that's possible right now.

Also, a new Bug that throws an exception:

const int HEIGHT = 500;
const int OFFSET = 32;
const int BUGGEDVALUE = -(HEIGHT - (OFFSET + 32 - 5));

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

Operator overloading bug:

Initializer {
	playergroup pg = PlayerGroupEmpty();
	pg << 1; // ERROR here: <excpecting ";">
	pg = pg << 1; // does work
}

// changing this to void does not help
playergroup operator<<(playergroup pg, int player) {
	PlayerGroupAdd(pg, player);
	return pg;
}

Hey, I just noticed that the autocompletion in version 3.0.5 does not work for custom types anymore (atleast for me). Crazy thing as it works with some types but not for others. Autocompletion for the default sc2 types is still working. There were some exceptions when I started the editor, which I have sent with the build-in report method.

Wow, awesome. I'm just coming back from Easter holiday and what do I find? A whole lot of new features!

Also wanted to let you know that my map still compiles fine with the new version (3.0.2). As always, much appreciated.

Edit: The new version (3.0.5) has a bug with enrichments:

enrich unit {
	fixed hp {
		get {return UnitGetPropertyFixed(this, c_unitPropLife, true);}
		set {UnitSetPropertyFixed(this, c_unitPropLife, value);}
	}
}

Initializer {
	unit u; // null doesnt matter
	u.hp += 5;
}

generates:

    unit u;
    u = null;
    UnitGetPropertyFixed(u, c_unitPropLife, true);
    UnitSetPropertyFixed(u, c_unitPropLife, );
    return true;

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?