If you are still interested in building a GUI on top of it, do you want to do the MPQ unpacking and repacking? I never used libmpq, though I guess it shouldn't be too complicated.
Names are of course unique ( strictly, it isn't random, more like a non-colliding index rehashing ).
I realize people are far more interested in Galaxy code obfuscation than data! Oh well, that's easy then :). A first version for Galaxy code is ready, just waiting approval for a new asset.
That first version won't do map MPQ unpacking or anything like that. You have to extract the MapScript.galaxy file from the map, run the program, and put the file back using a program like MPQEditor. Data obfuscation will work the same way, I may use libmpq eventually to make things easier.
The program should catch the names of about everything ( except new data types declared with typedef in custom code ), and encode everything given an alphabet and optional prefix. It also strips every space or line break that isn't strictly necessary, etc. Renaming everything with a random combination of the letters i and j, for example, looks pretty nice... :)
@SexLethal:
Quite right, that was just an example of how easy it is to parse MapScript.galaxy. The program is actually a little more clever than that.
Just in case it could help... I noticed that a lot of people modify existing actors rather than creating new ones, and any modified/deleted event is applied in the parent's list of events by "index". The 1.2 patch modified some actor events, and that breaks things for some people.
Moral of the story: if you are going to make an existing actor a parent of your new actor, do not modify or delete any existing event. You can add new events, at the end of the list, but you can't edit or delete the events that come from the parent. If you need to do so, make the parent a simpler actor with less predefined events. Editing/deleting events from existing actors is even worse, don't do that.
What kind of limit in script size is it? Does it get converted fine into galaxy code, but the resulting code refuses to run when loading the map?
I'm just asking because you could potentially reduce the size of your MapScript.galaxy file by around 40%, with a little program/script to strip everything that isn't necessary and renaming all variables to 2-3 letters. It's not entirely clear if that would solve your problem though.
Trigger code is really easy to obfuscate in comparison to the data. If you look at MapScript.galaxy, all local variables begin with lv_, all globals begin with gv_, functions with gf_, etc. Scopes are followed by tracking { and }, so writing a parser for that is most straightforward.
Regarding data, to make the tool work with all maps, the difficult part is really going to be how to manage implicit references with suffixes. For example, if you create an actor named FooBar with GenericAttack as parent, the missile is assumed to be FooBarMissile unless specified otherwise. So if your missile really is named FooBarMissile, there's no explicit reference at all in the data files. The obfuscation code would have to know about parent objects working with such suffixes, be able to figure out when implicit references happens, and create new explicit references... This is a bit messy.
By the way, SoulCarveRR said it, the point isn't really to protect anything... It's more like making it so much trouble to figure things out that the person is better off creating from scratch.
All right, I'll at least put some hours into making it able to recognize modified IDs and new IDs, then SoulCarveRR could make it a fancy GUI :).
@OneTwoSC
I'm not saying you would need to duplicate every data entry that you use, like splash damage. I'm just saying that the current code only works if you create new objects instead of modifying existing ones ; these new objects can link to existing unmodified objects just fine ( including splash damage ). Anyway, That limitation could be removed if the code would be made clever enough to differentiate between object IDs referring to modified stock objects and new objects.
Some maps may have hundreds of new objects defined, I can imagine a desire to obfuscate that stuff as much as trigger code. There's still a quick pass on the MapScript.galaxy file, basically just renaming all functions/triggers and variables ( plus basic stuff like removing comments, extra spaces and line breaks ).
In the end, the program presently does everything I need. It would imply some work to fix the current limitations ( recognizing modified/new object IDs, and dealing with suffixes like ##unitname##Build, ##id##Missile or whatever ), so I was just wondering if there's some demand for such a tool before putting more time on it.
Anyway, here's an example of the conversion made by the program, before and after :
I think Bob is right, a speed up behavior doesn't affect the turning rate of units. The best and safest way would be to write a program/script going through all the core XML files and editing all fields related to time ( and animations ) by the desired factor.
I don't think there's any hope of changing the core speed settings, a map can't override that stuff.
As for Jinxxx123's suggestion, behaviors couldn't work to affect really every aspect of the game : ability preparation/cast/channel/finish times, movers, building/training time, etc. I think your best bet would be to write a program or script reading the core XML files and changing all the fields related to time in one go. I could do it, but writing such a program would probably take about 1-2 days...
I quickly tested, Behaviors can even work for ability casting time, missile movers, etc. This is pretty simple then, just add the behavior to every single unit ( including missiles ) of the game.
I should have mentioned that : it also fixes Galaxy code references to all data objects ( the Galaxy code is what's generated by the GUI-based triggers ). It also fixes references to existing units/doodas placed on the maps, etc. To summarize, it converted flawlessly my map with 550kb of XML data and 5000 lines of Galaxy code.
@EternalWraith:
I certainly could make it configurable and improve the parsing... Still, I don't think I would be bothered into making a graphical user interface, I'm just not that kind of programmer :p. That's why I'm saying perhaps someone else could be interested into building a fancy graphical interface on top of it.
I have lurked around these forums for some time though I never posted before.
As many, I'm slightly annoyed by the complete lack of protection for SC2 "locked" maps. To protect my maps to a certain extend ( still unreleased ), I very quickly wrote a command line program that would parse the files extracted from a map MPQ and obfuscate all references. So for example, an effect that would be previously called "BattlecruiserTornadoDamageSearch" becomes something like "xn9pK2".
There are some limitations :
- It assumes that all the data is new : I mean new units, new abilities, effects, whatever. If you modify existing units instead, the existing code won't work. It would have to compare against lists of detault IDs to figure out what's new and what's not. I personally think it's bad practice to modify existing stuff rather than create new from scratch anyway.
- The code isn't clever enough to manage references by parameters if you append prefixes/suffixes. So, stuff like ##id##Damage or ##unitname##Build wouldn't work without extra parsing.
- It's totally not user-friendly. It very probably requires a programmer to use ( configuring it by editing the source code and recompiling ).
Still, it works pretty well. Resulting maps are also smaller and faster to load.
Is there any interest in that code? I don't think I would be motivated into writing it a friendly and flexible graphical user interface, but perhaps someone else would... It's just some 600 lines of C code, so if there's any programmer who wants to have a look, let me know.
0
@SouLCarveRR:
If you are still interested in building a GUI on top of it, do you want to do the MPQ unpacking and repacking? I never used libmpq, though I guess it shouldn't be too complicated.
Names are of course unique ( strictly, it isn't random, more like a non-colliding index rehashing ).
0
I realize people are far more interested in Galaxy code obfuscation than data! Oh well, that's easy then :). A first version for Galaxy code is ready, just waiting approval for a new asset.
That first version won't do map MPQ unpacking or anything like that. You have to extract the MapScript.galaxy file from the map, run the program, and put the file back using a program like MPQEditor. Data obfuscation will work the same way, I may use libmpq eventually to make things easier.
The program should catch the names of about everything ( except new data types declared with typedef in custom code ), and encode everything given an alphabet and optional prefix. It also strips every space or line break that isn't strictly necessary, etc. Renaming everything with a random combination of the letters i and j, for example, looks pretty nice... :)
@SexLethal: Quite right, that was just an example of how easy it is to parse MapScript.galaxy. The program is actually a little more clever than that.
0
@Aneth0r:
Just in case it could help... I noticed that a lot of people modify existing actors rather than creating new ones, and any modified/deleted event is applied in the parent's list of events by "index". The 1.2 patch modified some actor events, and that breaks things for some people.
Moral of the story: if you are going to make an existing actor a parent of your new actor, do not modify or delete any existing event. You can add new events, at the end of the list, but you can't edit or delete the events that come from the parent. If you need to do so, make the parent a simpler actor with less predefined events. Editing/deleting events from existing actors is even worse, don't do that.
0
What kind of limit in script size is it? Does it get converted fine into galaxy code, but the resulting code refuses to run when loading the map?
I'm just asking because you could potentially reduce the size of your MapScript.galaxy file by around 40%, with a little program/script to strip everything that isn't necessary and renaming all variables to 2-3 letters. It's not entirely clear if that would solve your problem though.
0
Same problem here.
Closing the terrain window prevents the messages from popping up, while you work on data or code.
0
Trigger code is really easy to obfuscate in comparison to the data. If you look at MapScript.galaxy, all local variables begin with lv_, all globals begin with gv_, functions with gf_, etc. Scopes are followed by tracking { and }, so writing a parser for that is most straightforward.
Regarding data, to make the tool work with all maps, the difficult part is really going to be how to manage implicit references with suffixes. For example, if you create an actor named FooBar with GenericAttack as parent, the missile is assumed to be FooBarMissile unless specified otherwise. So if your missile really is named FooBarMissile, there's no explicit reference at all in the data files. The obfuscation code would have to know about parent objects working with such suffixes, be able to figure out when implicit references happens, and create new explicit references... This is a bit messy.
By the way, SoulCarveRR said it, the point isn't really to protect anything... It's more like making it so much trouble to figure things out that the person is better off creating from scratch.
All right, I'll at least put some hours into making it able to recognize modified IDs and new IDs, then SoulCarveRR could make it a fancy GUI :).
0
0
I think Bob is right, a speed up behavior doesn't affect the turning rate of units. The best and safest way would be to write a program/script going through all the core XML files and editing all fields related to time ( and animations ) by the desired factor.
0
I don't think there's any hope of changing the core speed settings, a map can't override that stuff.
As for Jinxxx123's suggestion, behaviors couldn't work to affect really every aspect of the game : ability preparation/cast/channel/finish times, movers, building/training time, etc. I think your best bet would be to write a program or script reading the core XML files and changing all the fields related to time in one go. I could do it, but writing such a program would probably take about 1-2 days...I quickly tested, Behaviors can even work for ability casting time, missile movers, etc. This is pretty simple then, just add the behavior to every single unit ( including missiles ) of the game.
0
@SouLCarveRR:
I should have mentioned that : it also fixes Galaxy code references to all data objects ( the Galaxy code is what's generated by the GUI-based triggers ). It also fixes references to existing units/doodas placed on the maps, etc. To summarize, it converted flawlessly my map with 550kb of XML data and 5000 lines of Galaxy code.
@EternalWraith:
I certainly could make it configurable and improve the parsing... Still, I don't think I would be bothered into making a graphical user interface, I'm just not that kind of programmer :p. That's why I'm saying perhaps someone else could be interested into building a fancy graphical interface on top of it.
0
Hi,
I have lurked around these forums for some time though I never posted before.
As many, I'm slightly annoyed by the complete lack of protection for SC2 "locked" maps. To protect my maps to a certain extend ( still unreleased ), I very quickly wrote a command line program that would parse the files extracted from a map MPQ and obfuscate all references. So for example, an effect that would be previously called "BattlecruiserTornadoDamageSearch" becomes something like "xn9pK2".
There are some limitations :
- It assumes that all the data is new : I mean new units, new abilities, effects, whatever. If you modify existing units instead, the existing code won't work. It would have to compare against lists of detault IDs to figure out what's new and what's not. I personally think it's bad practice to modify existing stuff rather than create new from scratch anyway.
- The code isn't clever enough to manage references by parameters if you append prefixes/suffixes. So, stuff like ##id##Damage or ##unitname##Build wouldn't work without extra parsing.
- It's totally not user-friendly. It very probably requires a programmer to use ( configuring it by editing the source code and recompiling ).
Still, it works pretty well. Resulting maps are also smaller and faster to load.
Is there any interest in that code? I don't think I would be motivated into writing it a friendly and flexible graphical user interface, but perhaps someone else would... It's just some 600 lines of C code, so if there's any programmer who wants to have a look, let me know.
Stragus