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.
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.