Umm .... the linked up parts have to display... or the game couldnt read if....
as an example...
I have and ability and that ability has 15 different data components........
if i had about 100 abilities that all had 15 different data components..... thats 1500 obfuscated data objects
Id buy you a steak dinner if you could manage to rename them all properly( and working) and port them into a different map at that point
The button's "ID" would be obfuscated as well..... so as it appears in game im pretty sure it wouldnt be similiar... i could be wrong on that one though.
The various objects of the data editor must refer to each other to work. The map editor can see the links between the objects just as much as Starcraft 2 can.
So yes, it doesn't protect a map in any sense, it just makes it a hassle to figure things out. Obfuscation of all data and galaxy code is about the best "protection" we can get, until Blizzard adds some real locking one day.
As a side effect, it also shrinks the size of the Galaxy code to about 40% of original size, as well as making all XML data smaller through renaming.
Oh, obfuscating the data converts all references to that data : triggers, Galaxy code, pre-placed objects. Everything.
The only glitch with the data obfuscation program is that it can't make the difference between new objects and modified existing objects... Renaming modified objects will turn them into new objects, but without the implied fields of the parent default object. Anyhow, I'll fix that one day, perhaps just with a very long list of default object names that must not be renamed.
And the Galaxy script obfuscation works perfectly as far as I know.
Well! The command-line is working, and so is the GUI program from SouLCarveRR.
I just thought he would make a small update ( so the GUI program still work even if a backup/ directory doesn't already exist ), but if not, I'll put that shortly as it is.
Karawasa, sorry it took a while. I put up a package which contains SouLCarveRR's GUI : it saves you from having to edit .bat files but you'll still need to extract the .galaxy script from the map MPQ and put it back.
I'm not sure I'll complete the data obfuscation any time soon : it's rather complex to make it fully reliable, due to SC2 data's tendency to have implied suffixes at the end of object names, without any explicit references. It would require quite a bit of extra parsing.
I wouldn't mind putting the current package "as it is". It certainly works, but we would probably get bug reports from people who don't fully understand that suffix limitation or the format of SC2's XML files...
Glad that the trigger portion is updated and uploaded. Thank you for that. In regards to the data, am I correct in saying the limitations are that you must use unique data (duplicate don't modify) and that you must extract the appropriate XML? If so, hell yes release it. I don't need the version that holds my hand. I just need a version that works if you're competent. Hope it has a GUI like the triggers though.
As I have said before in earlier posts, these are the two limitations to the data obfuscation :
1) All objects must be new rather than modified ones, as it just renames everything by default. An user can manually provide a list of object names not be renamed, as the program doesn't have a list of all built-in objects.
2) No implicit references must be used, anywhere. For example, an actor based on the GenericAttack parent assumes that any missile actor will be named ##id##Missile, which means the same name with a "Missile" suffix. If the missile actor is named as such, no explicit reference actually exists in the XML files. The data obfuscation program will not create a new reference, and hence the link will be broken.
The first limitation is not much of a limitation at all. The second I will have to consult one of the data guys I work with to find out more. If it turns out both can be satisfied, then I would very much appreciate the "as-is" data obfuscation. I'll be back.
@Jinxxx123: Go
Umm .... the linked up parts have to display... or the game couldnt read if....
as an example...
I have and ability and that ability has 15 different data components........
if i had about 100 abilities that all had 15 different data components..... thats 1500 obfuscated data objects
Id buy you a steak dinner if you could manage to rename them all properly( and working) and port them into a different map at that point
The button's "ID" would be obfuscated as well..... so as it appears in game im pretty sure it wouldnt be similiar... i could be wrong on that one though.
@Jinxxx123:
The various objects of the data editor must refer to each other to work. The map editor can see the links between the objects just as much as Starcraft 2 can.
So yes, it doesn't protect a map in any sense, it just makes it a hassle to figure things out. Obfuscation of all data and galaxy code is about the best "protection" we can get, until Blizzard adds some real locking one day.
As a side effect, it also shrinks the size of the Galaxy code to about 40% of original size, as well as making all XML data smaller through renaming.
Any idea when the trigger AND data version will be available? How about the GUI? I'm looking to put this to use in a week or so. :)
Dunno when stragus will release....
I know the script bit is done for the most part......
one thing though....
if you obfuscate the data that is referenced in triggers I blieve it will break the triggers...
Will there be a way to exclude things? Otherwise, does this mean that any map that references data in triggers can't use this program?
Oh, obfuscating the data converts all references to that data : triggers, Galaxy code, pre-placed objects. Everything.
The only glitch with the data obfuscation program is that it can't make the difference between new objects and modified existing objects... Renaming modified objects will turn them into new objects, but without the implied fields of the parent default object. Anyhow, I'll fix that one day, perhaps just with a very long list of default object names that must not be renamed.
And the Galaxy script obfuscation works perfectly as far as I know.
Well Stragus did you want the GUI to do something different for the DATA stuff.... only handles the scripts..
Hope I'm not pestering too much. Any updates?
Well! The command-line is working, and so is the GUI program from SouLCarveRR.
I just thought he would make a small update ( so the GUI program still work even if a backup/ directory doesn't already exist ), but if not, I'll put that shortly as it is.
yeah that small fix will be done tonight... been getting side tracked trying to learn galaxy script.
BTW stragus
did you want a GUI component for handling the Data obfuscation....
also when you do obfuscate the data.... how does that effect the script that references any of those data objects?
@SouLCarveRR: Go
well i gave stragus a newer version of the tool now....
The asset page hasn't been updated in a couple weeks...?
Karawasa, sorry it took a while. I put up a package which contains SouLCarveRR's GUI : it saves you from having to edit .bat files but you'll still need to extract the .galaxy script from the map MPQ and put it back.
I'm not sure I'll complete the data obfuscation any time soon : it's rather complex to make it fully reliable, due to SC2 data's tendency to have implied suffixes at the end of object names, without any explicit references. It would require quite a bit of extra parsing.
I wouldn't mind putting the current package "as it is". It certainly works, but we would probably get bug reports from people who don't fully understand that suffix limitation or the format of SC2's XML files...
@StragusMapster: Go
Glad that the trigger portion is updated and uploaded. Thank you for that. In regards to the data, am I correct in saying the limitations are that you must use unique data (duplicate don't modify) and that you must extract the appropriate XML? If so, hell yes release it. I don't need the version that holds my hand. I just need a version that works if you're competent. Hope it has a GUI like the triggers though.
Hola?
As I have said before in earlier posts, these are the two limitations to the data obfuscation :
1) All objects must be new rather than modified ones, as it just renames everything by default. An user can manually provide a list of object names not be renamed, as the program doesn't have a list of all built-in objects.
2) No implicit references must be used, anywhere. For example, an actor based on the GenericAttack parent assumes that any missile actor will be named ##id##Missile, which means the same name with a "Missile" suffix. If the missile actor is named as such, no explicit reference actually exists in the XML files. The data obfuscation program will not create a new reference, and hence the link will be broken.
The first limitation is not much of a limitation at all. The second I will have to consult one of the data guys I work with to find out more. If it turns out both can be satisfied, then I would very much appreciate the "as-is" data obfuscation. I'll be back.
@StragusMapster: Go
I checked and we're clear for both limitations.
Are you willing to release the data obfuscation? I understand it comes "as-is" and I'm ready to work around the limitations.
@StragusMapster: Go
Can you at least reply?