Heavy Locker

You can lock your map easily if HeavyLocker isn't working for you. Just replace the war3map.wct and war3map.wtg with empty files, and delete the (listfile).

Blackdick, just picked up on another way you could optimize .j files, and I think this will greatly help with map protection because editor should parse this wrong (on the other hand it might be just getting it from the .wtg, but in any case this will cut file size down).

When you give a variable an initial value in the variable editor, when the editor generates the script it makes a big function for setting all of the variables to their initial values. This makes sense for arrays, since loops need to be made, but for individual variables it's unnecessary -- they should be set to their default values when they're declared in the globals block (i.e.: integer hpdamage = 4). This would eliminate having "set variablename" over and over, which for maps with lots of variables, could be a godsend.

If ya REALLY wanted to get messy, you could search for loops that init arrays of the same size and combine them into one loop to save even more space. But I suspect that would be alot more difficult to code.

I know the .j file is a pain to parse, but the smaller the file size the more people get to see the map, so I'll fight for every byte I can get ;)

K, first of all I´m sorry but I couldn´t read all those requests/bugs coz I´ve been away all over this week. Saturday I´ll take some rest and sunday I´ll get back to the HLocker.

I´ll try to add some features to it (dataangel, the first sugestion is not that hard, but the second is harder). Let me check what I can do.

As for the bugged maps, I still need ´em all on [email protected]. Sorry but I can´t fix the bugs with just a small request, I need to check what is going on inside the maps.
I´m 99,99% sure that those bugs are on the obfuscate script feature, but I need to check what is causing it. Plz send me the UNPROTECTED version of the bugged maps to the email mentioned above.

Can you release a version of HeavyLocker that doesn't force Obfuscate Script when you lock a map?

I have a new idea to further reduce the size of maps and increase the protection. I call it Region Implantation, because you implant all of the regions into the map script, instead of the trigger assimilating the coordinates from the region file. You may not know what I'm saying yet, so I'll explain in further details.

• The region file, war3map.w3r, has all the regions placed in the WE which increases the map size and making your map vulnerable to region editing.
• In the region file, it contains the min X, min Y, max X, and max Y of the region in float values.
• In the trigger editor there is an option which is called "Conversion - Convert Coordinates To Region" (that uses min X, min Y, max X, and max Y).
• You could replace all of the triggers that use Region X with the coordinate conversion using the coordinates from the region file, and then delete the region file making it very difficult to edit regions; whilst reducing file size.

edit: What do you think?

I've actually been thinking that this should be done for awhile.

Also, Blackdick: the .wts file (the string file) really just exists so it's easy for blizzard to translate the game into multiple languages (rather than editing the triggers, they just open the string file and start translating). In the .j file, rather than the actual string, it shows TRIGSTR_XXX which is a reference to a string in the .wts file. Seeing as the majority of mappers aren't going to be releasing their maps in multiple languages, it would save file space to replace the TRIGSTR_xxx references in the .j file with their value in the string file, and delete the string file.

I'm not sure how difficult this would be since I haven't messed with the filetypes much, but from what I understand SLKs load ALOT faster than the ability/upgrade files that war3 makes. If it were possible to convert one to the other that could improve map load time and maybe save space.

Blackdick: I think the reason that obfuscate script might be causing problems for people is because it deletes all comments. The game actually uses the comments inside the InitCustomTeams function -- deleting the comments in there stops the game from being able to show teams. You probably need to add code to heavylock to not delete comments within that function. The reason this doesn't effect all maps is because not all of them use custom forces.

Jesus, this thing is getting huge, lol. Ok, 0.2.3 is here with some changes/fixes:

k, now let´s try to answer some questions, the answers are bold.

I don´t remmeber wich version I added the w3r feature, but if you select LOCK map the w3r will removed. It is not needed by the game (just the WE needs w3r). I may place this as a separate option later on.

It probably won´t reduce the size that much. Using the WTS we can actually save space, since we don´t need the whole string on the script file, just the TRIGSTR_XXX reference. Works pretty much as a global variable. I may eventually add a code to remove the wts and then use the TRIGSTR_XXX references as global variables I will also check if the maps has equal strings and remove duplicates, if any. But this feature is future, I need to get the obfuscate thing propely working first and finish some other things.
The 0.2.3 works this way.

I can´t be 100% sure wheter a given TGA is a icon file or not. As I said, HLocker can save space, but it would also be a good idea if the user helps it. It is pointless to take some small efforts to reduce the file size while the user is still using TGAs instead of BLPs. I guess this should be done by th user, not by HLocker.:ggani:

You can already set the dir to any dir you want inside the Options. As for scripting and last used settings, I´ll try to add those as soon as I fix some other things

I guess it is not the comments removal that is doing this. Check that with the new 0.2.3 version. Comments can be safely removed without using the obfuscate feature. The bugs seem to happen only when obfuscate is on.

bludragn, look at a war3map.j from a map with regions (actually they are rects). There is a function CreateRegions, where all coordinates are stored. I think the W3R is only needed by the WE as BlacKDicK said (I think it's for the colors and the names).

If you do that at some time, include an option to replace the TRIGSTR_XXX references with the actual strings too. Sometimes this is better. But your idea with the globals can also be useful.

Yeah, but sometimes it is good that it starts at the last used directory not at a fixed directory.

About the buffer level:
Maybe you can add an auto-detect feature. It should use the next level after the size of the biggest file in the map/MPQ.

Regarding the WTS file, I'm sure BlackDicK tried to replace all the binary returns with ascii returns, and was unsuccessful because you can't replace the ascii returns after the STRING (#). However, you can replace all the other ascii returns, so you should probably go ahead and add this to the next version.

Example of a WTS file before edited (characters in arrows are bytes):
Example of a WTS file after edited (characters in arrows are bytes):
Binary Return = 0D
ASCII Return = 0D0A

Is there a proper name for the bytes? That is just what I call them.

Edit: Save 5 bytes per string, not counting the first.

Small note -- you forgot to update the month in the date. September = 09 ;)

@BlackDick: Great job with new version =) Minimap feature looks promising.

I'm totally lost as to what you're doing here (forgive my lack of hex editing experience). When I open my .wts file it's plain text. And so is the .j file. What is this about binary returns? :P

Also just occurred to me .wts file also stores tooltips and stuff like that... so you wouldn't be able to delete entirely.

@Blackdick: Another method to make the map even more secure maybe to insert an empty string at the end of the .wts file. See, if you have this:


The editor will refuse to open the map because String 133 is missing =) Try it with a blank string instead of "Blackdick's protection" (takes less space). An extra level of protection at a very small sacrifice in file size =)

Should be a simple to implement feature :D

I think you forgot you delete the (attributes) file. WE loads fine with a skipped string #.

What does the (attributes) file do?

WE doesn't load fine with a skipped string on my copy. I removed about 100 strings from my map without renumbering them, and I got an error message that actually listed each individual string number that was missing, and said because of it the map couldn't be loaded. I'm using vanilla TFT WE, no additions. Perhaps there's a minimum number of required strings, you're using an altered version of the editor, or you don't have the latest patch? Or this has something to do with (attributes) that I don't know about? :P

I deleted 5 strings from a map and it didn't affect World Editor. I am using the regular TFT 1.12 WE

Edit: Btw, (attributes) is like an encrypted CRC file for the war3map files in the map. I think the Blizzard signature might be stored in there.