SC2Mapster

Quote from sleipnirphant >>

I'll be sure to post some screenshots as soon as I get back to my computer, also I know you can post map links, how does that work?

 

 see the 'upload an image' button at the bottom of the post? just drag and drop your map in that zone, it'll add it to your post.

also I had the same problem for a while but found the solution - in your attack actor, find the field "Launch Attachment Query - Methods" and using the cutscene editor, find an attachment point that suits you where the missiles can be fired from. By default, it uses the Origin (I think), which is basically the absolute center, on the ground, of the model.

Update: I found out how to get it to work.

For the summoned unit, look at its Timed Life Effect when it summons a unit. It should have a behavior for the duration of the unit.

Edit that behavior’s “Stats: Kill Credit +” field where it says “Value” with a drop down box, and select “Caster”.

Tldr: I changed the behavior “swann - Turret Timed Life” -> stats: Kill Credit + -> Value -> Caster

In reply to MaskedImposter:

 What can I say, I'm foreign, I'm allowed to make mistakes. XD

Thanks for pointing it out, though!

Encryption adds no protection. It just obfuscates the data. Even when data is encrypted, by randomly mutating the data one will load different results.

You want to store a cryptographic hash of the data using a proven secure algorithm which is seeding in a unique non-standard way with reversible operations like bitwise rotation, addition and bitwise exclusive or. The protection comes from the random like nature of the output of cryptographic hashes combined with custom unknown logic, resulting in something that is hard to guess especially for someone without a computer science degree.

When the bank is loaded it re-computes the cryptographic hash of the stored data using the same algorithm and compares it with the stored hash. If there is a disparity the data has been tampered with and the load fails.

A strong cryptographic hash like SHA-256 combined with xoring with a map specific key, the SHA-256 of the user account identifier and some arbitrary but constant rotations will be more than secure enough to stop people modifying the banks directly. It will only be cracked by someone modifying/reading the triggers. It could technically be cracked without by an expert, but orders of magnitude more people will crack it by using the triggers directly so one can ignore those as a threat.

Do not try to invent a cryptographic hash algorithm. Chances are you will do it wrong since there is a reason millions of dollars are spent every year on developing them. The people who create them are extremely mathematically gifted and have years of experience with computer security. Best you can do is take a standard algorithm and modify it slightly using non destructive operators so that it produces non standard output which exponentially increases the complexity of solving the algorithm with respect to the number of transformations you apply. Hence the weakest point of security quickly falls to everyone being able to read the map script itself, so anything more extreme like encrypting the data as well becomes pointless.

As such encrypting the data on top of that is pointless unless you want to obfuscate what you store from the people themselves, which clearly is not the case for achievements when people know they have them.