SC2Mapster

@SoulTaker916: Go

I hope you have permission to use that zergling art...!

@MaskedImposter: Go

Yeah, I was really disappointed by that. I was like, wow, are they going to actually do something for the Arcade?

NOOOOOPE.

@Vanished131: Go

No thanks - we need a fixed terrain.

@Nebuli2: Go

Looks awesome.

Given the gloomy atmosphere it could use some more/stronger light sources.

@Mille25: Go

Excellent! Thank you.

@ErynO: Go

Are you asking how they get the image or how they are using it as a doodad? Or both?

As for getting the image, they aren't doing it by any actual trigger functionality - they're literally just importing it into their custom tournament maps.

As for using it as a doodad, I assume they are using a splat model for a doodad actor and using texture declaration to swap the texture out for the image of the clan logo.

Hey all,

Does anybody know if it is possible to make a trigger library using galaxy script where the actions/functions are available to those who import it but the code is not visible simply by selecting the action/function?

In other words, in the same way you can see a list of native galaxy actions/functions but selecting them doesn't show you their code.

Thanks

@b0ne123: Go

That's a rather limited and tedious way of doing things that I really don't recommend.

One thing you have to be careful of when using Epsilon's method is whether or not the damaging unit is actually the caster. In the case of skillshot abilities where you have a missile searching for targets around itself to do damage to, the missile will actually end up being the damaging unit in all likelihood.

To give you some additional information:

You can define structs, as stated above. However, you can't have functions that return structs, therefore you can't dynamically create new instances of structs. You can declare a struct locally, but since you can't return it, this more or less means it only lasts the duration of that function. Therefore, any structs you want to use in more than one trigger need to be declared globally.

Structs can't be saved in the Data Table. You could, however, declare in advance a large array of your struct, and make use of them as necessary by passing around integer indexes into this array. Depending on what you plan to use this for, this can be quite expensive.

You can pass structs to functions using structref. Example:

struct thing {
...
};

typedef structref<thing> thing_r;

void initThing(thing_r t)
{
   //do stuff to t
}

@DimitarK: Go

Kueken is mostly correct. However, structs are entirely capable of holding methods - using the funcref type.

Example:

void doSomething();
typedef funcref<doSomething> doSomething_r;

struct thing {
    doSomething_r do;
};

thing aThing;

aThing.do();

@fishy77: Go

Make it an ability.

Edit: To clarify, I mean: do not make it a weapon. Make an ability with a hotkey of A that looks and feels like an attack.

@Necromoni: Go

There are plenty of topics already about accessing the galaxy script of locked maps. It's not something people get banned for. People have the tools to do it so there's no point to being in denial.

Edit:

I should add that obfuscation is easily achievable by saving the encryption key in the data table instead of just as a variable name. Then they have to look it up by the key you save it into the data table with, but you can break up the key into separate pieces to obfuscate further so that it can't just be searched.

In fact, even better: put the encryption key in some data value, the field of some unit or something, and use catalog triggers to look it up and save it into the data table. Then they can't find the encryption key unless they have the data for your map too.

@NoblePandaPower: Go

The values generated by Starcode already look incomprehensible. You wouldn't want to make anything look like java or binary because that would limit the characters you can use in the encryption, reducing the base of the values from something around 85 to much less, 2 in the case of binary. In other words, your bank wouldn't be able to hold as much information.