Heavy Locker

The thing they changed in the RoK trailer, right?
To point it out: It's the texture that is used by the trigger Cinematic - Fade Filter (and others with filters).
BTW, this is a bit offtopic, but it would be great, if we can change the WE to enter a path for this texture in this trigger instead of a dropdown with some textures (predefined). If someone wants to make really many of these, he maybe run out of textures to replace.
I'll try to look into it. While it is possible to enter the texture via custom text, a GUI option would also be nice.

Great! Thx BD for the speedy update.

It seems that the pb isn't fully fixed. I got it again.

I have done some tests and I can tell you that the cameramask isn't the reason.
I have removed it and also removed some action I do at the beginning of the map but War3 still crashes.

I don't know the reason why this happens but it is at map initialization and I do a lot actions at initialization.

Edit: War3 crashes on all maps with my modded/compressed mpq. This means it is not a trigger issue but something in the mpq get corrupted.

BTW I have noticed another little issue, when I compress a mpq, War3 interface is all in english. emote_sweat

I had a question about the buffer level..

this higher the level, the more the file size is reduced correct?
the higher the level, the more memory is needed to run the map or simply to load it?

does higher buffer level have any other negative effects?
is there anyway to lower it from 11 on the full lock mode to avoid any of these effects?

The loading time is not much higher. I am sure you will not even sense it. Technically it needs more memory to compress (when you heavylock the map) and to decompress (when the game loads it). But the slight delay is so short that it will not interupt you. After the LOADING, Warcraft III doesn't load anything out of your map during a game.

cool

Krakou the first problem is caused coz my tool doesn´t handle files with diferent language IDs inside the MPQs. Take a look on ScFreak article for more help here: http://scfreak.0catch.com/articles/article5.html

Sorry, but handling language files would make the things even more harder to me and the user.

I also think the "corruption" is being caused due to special characters of your language. When I´m "optmizing" TXTs and SLKs I search for special chars like "//" to remove some stuff. Maybe your TXTs have some chars that my tool can´t handle and is causing this error. Not sure what is really hapening. I need to take a look on your file (MPQ,W3M) to see what´s happening. What´s the size of this file? Can you send it to me?? I can also receive it by ICQ/FTP if this turns to bee large enough to a simple e-mail.


XP, as ScFreak explained the "time increase" due to the lvl 11 is reaaaally small, you don´t even notice it. I see no reason to stop using lvl 11 on Maps and even on MPQs. ;) Of course, due to another reasons my War3.mpq re-packed with lvl11 actually increases the size instead of reducing it. It is hard to explain but "sometimes" the new file can get bigger than the source, but this is really rare to happen.

hey this be kewl.

but uh, BlacKDicK... how'd you get your name? emote_sweat

Ok that should not be a pb.



Now I understand why I don't have this pb on the english version of my mod that I am doing.

My MPQ is 15 Mb big this why I need your Heavylocker. ;)
I will upload it on a ftp.

K, I got it (removed the link).
We have some problems here coz you´re probably developing a French version of your MOD. I need to know if your mod is going to be French or English, coz as you might have seen, this can have weird effects with MPQs. I have a "special" version of WINMPQ here (I changed some things) that implements the "buffer lvl" scheme I use with HeavyLocker. Of course, the Map Optmizations are specific for the HeavyLocker, but this "special" version of WINMPQ can pack files within MPQs with lvl 11 for an example.
Just to give you some numbers, using this WINMPQ your file reduced from 16.015.165 to 8.510.786 bytes.
The best solution for your problem is work with WINMPQ, coz you can select wich languageID you´ll be using when adding files to your MOD.

This is what I did to reduce your MOD size:

1) Extracted all files to a FOLDER.
2) Erased (listfile) from that folder since WINMPQ auto-builds listfiles for us
3) Created a new MPQ using MAXFILES = 1024 and BUFFER LVL = 11.
4) Added all files from that folder to the new MPQ.
I´ll talk to ShadowFlare and ask her to see if I can release this "special" WINMPQ version I created here.

My mod has been developed in french but I am now doing an english version and all future developments will be done on the english version.
But this enhanced Winmpq could be very interesting for the non english communitie.

It´s my nick not my name, I´m not even black. It´s a long story, let´s just say that my friends here in Brazil call me "Braulio Negão", wich turns to be BlacKDicK in english. Altough sometimes it may sound "offensive", it´s unique. Never found another "BlacKDicK" on the net over the past 8 years. Nobody seem to be that dumb as I am :D

There we go the WINMPQ MOD (bin+src) ...

i dont know what happened but suddenly this program is causing my map to crash when i try to host it again. 0.1.5 fixed it last time but now 0.1.5 is doing it too? which maybe means there is something in the map that the program doesn't like. Unprotected works fine.. i dunno what the deal is.

edit: also crashes if i use map optimizations and no lock.

ok i think i found the problem.
Heres whats wrong:

In my code I have a string variable that is run through a loop that adds new text to the string. The problem is i wanted each new text to be on a new line so my code looks like this:

with the closing quote on the next line. This is syntactically correct, and it runs fine unprotected. However I think one of your optimizations kills the close quote because its on its own line...

For now I will see if I can get around this but maybe you could fix it to allow for this ?

Heh... That's an interesting little hack you've made for SFmpq. ;) It works because SFmpq writes the header every time the mpq is modified and it uses that one from memory. ;) Also, as you probably noticed, SFmpq has no problems using archives with different block sizes. There is actually only one place the block size is hard-coded in the entire dll file, where it creates the archive. This means that I could add support for creating ones with different block sizes with little modification.

There is another way of getting different block sizes other than what you did, and I think it would probably be a little more reliable. You could have the code close the archive after creating it, modify the block size in the actual mpq archive, then reopen it. This should work with any version of SFmpq.

BTW, why are you using 1 MB block sizes?!