SC2Mapster

I didn't know that you could use char or handle.. I haven't found any methods or fields from the library that use them... do they actually have any practical use?

It should still be valid to use of course. Just seems silly that they added them if they are unusable. (Not talking about the byte here)

When using string obfuscation, the string is not decoded each time it is used, only once when the map is loaded. Of course this leads to some overhead when loading the map, but after that, the difference is loading a field instead of a string constant.
In the compiled script you see that the strings are moved out into fields of the form

const string Galaxy_pp_stringO0 = Galaxy_pp_Deobfuscate(" roie?t esxr:al2t31nIKy Vshr sra");

If you are worried about the size of the output file in terms of bytes, then I really don't think there are much to be gained here. With a 10 mb map size limit, 2k lines saved, and lets say 2 bytes pr line break, you save 0.04% of the total map size by removing line breaks.. And if it's the compiled code you are worried about (after the galaxy compiler), then I don't see how line breaks should have an effect on that.

But it still servers as an extra obfuscation technique.

If it's only about obscuring the code further, I can make an option to make as long lines as possible in the output

It's just because I think the code is easier to read if there is a line break between declarations (functions, fields, includes and struct declarations)

It might be possible for me to add support for chinese symbols in strings, but right now I got a lot to do and no time. Next on my list is the runtime checks of pointers. But right now I got some courses at school that are coming to an end and thus demand a little more time. But once exams are over, there's the holiday period. Should have good time to work there. :)

In the mean time, like mr. Fl4m3Ph03n1x suggested. You should be able to just use the proper escape sequences.

Edit: Hmm. I just tested it a bit in the normal editor. Maybe it's just because I got the European version of SC II, but the highest value I can enter without getting an error is \377 (0xFF).

Quote from Kueken531: Go

String obfuscation throws warnings for every constant string? Even if it does not work for constant strings, I would probably remove the warning, since the user did nothing wrong, esentially. Same for the not renaming trigger functions. I would include this information in the documentary, but not in warning messages (maybe add a differend kind of message, like a notification in some other message area, which could probably be hideable and could contain other useful information, like amount of renamed strings or whatever... just thinking loud here ;). I would remove the 'warning' character for these messages in any case, just not sure, how)

Are you referring to the warning about strings in fields? Because they should be made so you can just hide all but the first. I could change all the other warnings to behave in the same way.

Quote from Jonanin: Go

Hi, I really like your editor, it's really been speeding up my development time and ease. I have just a few requests: - an option to use tabs instead of spaces - when making a new project, choose the path where it is created - the ability to move the file tabs around, re-order them.

Of course, if you are willing to open source your project I could definitely help!

I don't know about tabs - currently pressing tab results in 1-4 spaces (up to the next multiple of 4 characters). What is your reason for wanting tabs instead? Perhaps I could do something else.

The others I can put on my todo list ;)

I don't think I will go opensource - I like to be in control of the language.. I haven't really thought about bringing others in to help on the project. I'm not sure how I feel about it. The code is not nearly commented enough for other eyes than mine, and I would probably not have as good an overview of the code. But on the other hand, I don't have as much time to spend on it as I would like at the moment. I'll have to think about it.

Quote from Jonanin: Go

I have another suggestion, about triggers. The process of writing triggers is extremely repetitive and often requires the same basic code. Why not condense that into a single declaration (...)

I have been thinking about this myself actually. I was thinking about doing it something like this

#trigger foobar
{
    #events //Optional
    {
         TriggerAddEventMapInit(foobar);
         YourFavoriteEvent(foobar, args);
    }
    #conditions //Optional
    {
        //Return true if the trigger should be run

        //I initially didn't think too highly about this section, but I suppose it does
        //make a diffrence, since it must be guarded by testConds and return false in the trigger.
    }
    #actions
    {
        //Insert trigger code here. 
        //References to variables runActions and testConds are possible.
        //Return type is void, and will be changed to boolean by the compiler.
    }
}

Refferencing foobar will then either be the global trigger variable, or the trigger method - depending on the context. The initializer function will be called automatically at map init.

Uploaded 1.8.0 with the following changes

• Added pointers - see documentation for details
• Fixed a crash that occured when scrolling the editor with the suggestion box open.
• Fixed a crash that occured when obfuscating strings, and using the invoke expressions, or initializers.
• The compile and save button is now grayed out when no project is loaded
• Fixed a bug that caused pasting and undoing to not display the following lines correctly.
• Fixed a bug where blocks were not correctly updated.
• Using tab or shift+tab with no text marked now indents from the caret position.
• The suggestion list now scrolls down if the selected item is not visible.
• If the mouse is over the suggestion box, and you scroll, it will now scroll in the list.
• The editor now remembers closed blocks when closed.

Note that as mentioned above, some runtime checks are not yet implemented for pointers.

Quote from Axarion92: Go

Also this tool actually needs a good icon.

I did my best with the current icon, although I admit 2d imaging is not one of my strong sides.. :)
Is it really that bad?
Edit: Ah, I see that the icon is for some reason wrong in the task bar in the released version.. Ill look into that.

I want to make an advanced algorithm for analyzing when it's needed to check for null pointers, so I avoid placing a runtime check every time a pointer is used. It is proving a bit difficult though, and I decided to rewrite and expand it to include array indexes. It has been some time since the last release though, and I think it's about time I address some of the bugs.. So, I think I'll get to work on those, and then release it with the pointer features that are currently implemented - you just need to keep in mind then that the runtime behavior of the code may change in a future version, if you happen to reference a null pointer, or index a dynamic array out of bounds.

Well, I'm getting pretty close to finishing it.. just need to implement the runtime checks for null pointer and array index out of bounds errors. And then of course fix some of the bugs.

The problem with fixing the bugs first is that I already changed much of the code to facilitate pointers.. My code is basically built in stages - parsing, checking and then converting. The parsing and checking is done, so I would have to go back and undo that to make the compiler reject pointer code, if I want to fix bugs before making pointers.. It's not impossible, but it will slow down the overall process, and I might miss somethings, thus creating new bugs.

I don't think I announced it in this thread, but I released a v 1.7.7 before I started on the pointers - you did see that one, right?

Hmm.. okay - I might need some files to debug that. Don't expect a new version until I got pointers to work though.. Progress is a bit slow at the moment since I don't have much time to spare, but I will get it done.

Alright, then I think it should be something like this

//Struct types
Foo* foo;
if (foo == null)
    foo = new Foo();
foo->bar = 2;
//Or do this. either way works
(*foo).bar = 2;
delete foo;


Foo** bar;
(*bar)->bar = 2;

//Arrays
string[] strings = new string[8];
delete strings;//I'm tempted to make this delete[] just to go closer to c++ for those familiar with that (if any)

//Arrays of pointers
Foo*[] fooAr = new Foo*[2];
fooAr[1] = foo;

int[] intAr = new int[10];
int[8] normalIntAr = intAr;//Syntax error - must copy each element individually regardless of array sizes

//Convert pointer to regular
Foo* foo1 = new Foo();
Foo foo2 = *foo1;

//Convert regular to pointer
foo1 = new Foo();
*foo1 = foo2;
//So, make a new element and copy it into that

int* i = new int(2);//At least for primitives, I would like this syntax
int* i2;
i2 = i;//Set i2 to i. Changing i2 will change i, and vice versa
*i2 = *i;//Copy i to i2. Changing i2 will not change i1 or vice versa.

string* s;
if (s == null) //Check for if the pointer is null
if (*s == null) //Check for if the string is null
string s2 = "foobar" + *s;//For consistency, one will need to do the star before the variable if they want the value

One problematic thing I have noticed is that I will have to check for array index out of bounds errors.. The way I see it, I will have to check it pretty much before every attempt to index it - might not be very efficient.

I have been thinking about implementing dynamic types..
Im thinking something like c++ with pointers, but since you guy(s) will probably use it more than me.. what do you think?

//Struct types
Foo* foo;
if (foo == null)
    foo = new Foo();
foo.bar = 2;//c++ uses -> rather than . for pointers. It's not really needed here though.
delete foo;

//Pointers to pointers?
Foo** bar;//I can't think of any useful applications for this. It's possible in c++, but is it needed here?
*bar.bar = 2;//If we start down this road, -> is probably better.. or **bar.bar

//Arrays
string[] strings = new string[8];
delete strings;//c++ use delete[] for arrays. it's not really needed here though.

//Arrays of pointers
Foo*[] fooAr = new Foo*[2];
fooAr[1] = foo;//I can think of applications for this.

int[] intAr = new int[10];
int[8] normalIntAr = intAr;//What to do here? copy the 1st 8? give an error?

//Convert pointer to regular
Foo* foo1 = new Foo();
Foo foo2 = foo1;//Implicit conversion (changes to foo2 will not change foo1). Another posibility is foo2 = *foo1, to make this more clear.

//Convert regular to pointer
foo1 = foo2;//Implicit conversion not good - a new element must be created (the user must be aware of it so he can delete it)
foo1 = new Foo(foo2);//Restricts the possibilities for constructors
foo1 = new Foo<foo2>;//Possible.. might look a bit wierd?
foo1 = &foo2;//Another possibility.. but it's not very clear that a new element is created.
//Note, it doesn't make sense to get the address of a non-dynamic element. this is why a new dynamic element must be created when doing this.

int* i = new int(2); //This is really also a conversion from regular to pointer. Should keep it the same syntax as above.

string* s;
if (s == null) //Disambiguation.. strings are nullable.. what if we want to check if the actual string is null?
if (*s == null) //Perhap

Im quite conflicted about the -> vs . notation. On one side it's probably not really needed, but on the other side, it sets dynamic types apart from regular ones(an extra reminder that there are something special here that must be deleted to avoid memory leaks).

Are this kind of functionality even needed or desired?

Well, actually that crash was unrelated to the speed optimization.. I just suck at making test cases it seems.. I fixed it an uploaded a new version.

Something like that really shouldn't happen. I'll do my best to make sure it won't happen again.

• Added a status bar
• Fixed a crash that occurred when referencing a local inside an if (sry :( - I should have caught this before release.)

I uploaded a new version with these changes

• Optimized the editor (for speed).
• Added undo (ctrl Z and ctrl Y)
• The compiler now properly shows the suggestion box after a return.
• The compiler now gives an error if a local variable is used before it is declared.
• The compiler now gives an error if two locals of the same name is created within the same scope.

I hope that solves your slowdown problems.

I got a bad feeling about bugs in this one - I have done some changes which might have ramifications in seemingly unrelated parts of the code, so as always - save often and make backups ;).