Wc3 Map Optimizer 3.0b

Ya I only get about 5%.

The % is affected by how small/big your map is, if you imported any files, etc.

It only affects strings, not binary.

I just noticed my map became unplayable when I used v2.2. So I turned off all the options I could and optimized my map, then I took a look inside it with WinMPQ. I noticed that it writes the war3map.j file to the path "scripts\war3map.j". Isn't it supposed to be just "war3map.j"? It's probably a bug, 'cause the actual file works. It's just the path that screws everything up.

EDIT: Now it's magically not doing that anymore and works properly after its optimized? Hmm...

The path Scripts\war3map.j works fine.

consider a big map like 3.0MB , even 5% is a big space reduced, I think I am going to use kilobytes instead of percentages in next versions.

I found that certain maps with sounds may grow in size a lot and this is actually an issue that happens with heavy locker too, for some reason Zlib on certain compressed wavs is evil.

I get 25% smaller filesize on a 800KB map and a 7% smaller filesize on a 2MB map.

But in actuality the 800KB map only became like 650KB and the 2MB map became 1.7MB or something.

Yes the WAVE compression (IMA ADPCM) works better on those files but they also have problems. With the "standard level 3" block level they work fine but with larger levels they do not work fine, coz we need to pad the WAVE. The first block can use the binary compression methods but the remaining blocks use the WAVE comp. method and binary methods. The trick is to inject dummy data on the first block to make the real data section of the wave ALWAYS start at block n# 2. To do this we need to handle the wave header, changing some offsets. Of course the extra data will make the first block larger but since it is mostly dummy data it will also get good compression rates. The tradeoff worths the effort: the other blocks will beneffit from the wave comp. method. By parsing the wave we can also remove some unused sections like comments and another padding sections. Finally, we can also use wave + zlib compression instead of wave + huffman compression,saving the mpq some more bytes. This is one of the features I wanted to implement on HeavyLocker altough I never managed to get time and the mood to finish it.

I just used v2.2 on my map AFTER I added AbilityData.slk and now the map crashes at load screen.

Could there be a connection? I am going to try loading the map with no optimization at all and see if that's the problem.

Edit: Nope, still crashes without any optimizations. Why would it crash in-game but not in WE?

why did you add it? and how does it crash, error message or something? , how did you add the file? probably the file weren't on the listfile or something, try adding that file with the import manager

Well, it's not a problem connected to this tool if it also happens without optimizations.
Also why should it crash the editor?
The editor never creates an ability object, it just lists the stats of all abilities.

I have to use AbilityData.slk because the map is for Reign of Chaos.

I figured out what the problem was, thanks for trying to help anyway. The problem was that I tried to use a TFT ability inside of ROC.

I fixed a major bug with comments that had a " and made the whole map to corrupt. Also fixed a minor bug that inserted ? to the start of j and wts files, and some other bugs that weren't allowing array merge nor antibj to work in certain parts of the script

Vex, I truly love your optomizer. Thank you.

I've been following some map things on dota allstars.

They reduced the maps loading time from 3 minutes to 30 seconds. The problem was fragmented and unorganized string files. I see your opt cleans strings a little.

They suggested deleting the .wts file, and copy-paste ALL the map descriptions back in ( x 10,000) but that seems way impractical!

Do you think this could be part of the script encoporated into a future version of the optomizer? I thought you may be interested. It would be awesome. Just something to consider perhaps. Especially since the LOAP type maps and other RPGs have tons and tons of strings.

Here is what they described as the problem:

Edit: I saw another post somewhere else that explained the thing correctly, I now see that instead of optimizing the strings file I have to get rid of it, though it would add some kilobytes the loading time will be faster

Ignore the rest of this post
//

I doubt that the loading time is caused by the strings file, I am sure they load the strings in an array before loading the other stuff.

The real loading time spike is the fact that the game seems to convert world editor ability files to game ability files before loading, that's the reason pitzermike made a convertor, it works, and it really decreases loading time.

I am currently making a strings file optimizer feature, it is not going to take the strings of the file and put them where they are used, I thought that it would be much better to make sure there aren't duplicates and it makes a strings file without duplicates, it is taking time though because I have to make the optimizer able to open and save every possible wc3 file format.

Odd, they insisted the load time was reduced 2 mins because of the string fragmentation.

Perhaps you can get rid of it in the process.

I'm sure your judgement and experience is best.

Where is this... program.. you mentioned...pitzermike?

Do you plan to encorporate that?

Thanks for the reply. I/we have been fully promoting your program on our tutorial forums now, after using it for a month. The fact we can make it totally not open in the editor, and the opt features, are priceless.

// edit

Not to mention, it stays updated unlike the others :)

I am actuallly in agreement, check my post, i edited it.

I saw another post somewhere else that explains and prooves exactly the fact that Blizzard made a terrible work, Even I would have made the game load the wts in an array before doing anything else.