| 07-08-2003, 04:15 AM | #76 |
Guest | Do you know a site i could get the codec to watch those movies i searched the codec and got a few but the brought up dead links. The codecs 4 letter code is "BLZ0" |
| 07-08-2003, 05:42 AM | #77 |
I guess you have 2 options: 1) Change the FourCC to DIVX 2) Use the "BLIZZARD CODEC" (blizzard.ax). It is on the W3 folder. Btw, the blizzard.ax codec is the same as the divx codec, they just changed the FourCC to BLZ0 instead of DIVX. |
| 07-08-2003, 02:43 PM | #78 |
Guest | How exactly do you change the blzo to divix in the Blizzard.ax??? like i opened it up in hex but i don't know what field to change. |
| 07-08-2003, 03:36 PM | #79 |
No, I mean change the 4cc on the AVI, not on the codec |
| 07-08-2003, 06:05 PM | #80 |
Kinda off-topic. Anyway, I never had problem viewing these files with Windows Media Player (7 or higher) or Real One Player, while I had DivX 5.02 installed. Get DivX at www.divx.com |
| 07-09-2003, 04:47 PM | #81 |
I'm new to this whole map locking thing -- can you clear this up for me? If I use this program with a w3x file, what does it do to stop people from stealing my abilities and triggers, etc? They can still just open the mpq and take anything they want, right? |
| 07-09-2003, 05:49 PM | #82 |
Yes, that's right. Just read the whole thread, BlacKDicK explained somewhere what this name means. I can just tell you that this tool minimizes the space your map needs, which is obviously a good thing, especially for Battle.net maps. |
| 07-09-2003, 06:09 PM | #83 | |
Quote:
It protects the MAP using the "weeddars's method" (the same used with ExtProtect), wich means it will not be open-able on the WE. I can´t prevent users from using MPQ Extractors to grab the stuff that is inside the MAP because: 1)If the game (W3/FT) can read stuff inside the map then any MPQ Extractor can. 2)If I encrypt the stuff then MPQ Extractors will not work, but then the game won´t read the MAP. I´m a little busy coz I´m rewriting my "W3-Reseter" to be compatible with FT and other Blizzard Games such as D2/LOD and SC/BW. Probably tomorrow I will release the new W3-Reseter (it will be known as BlizzReseter) and then I will get back to the HeavyLocker. EDIT: Added a BETA version of the BlizzReseter here: http://www.wc3campaigns.com/forums/s...&threadid=5600 |
| 07-14-2003, 12:02 AM | #84 |
This program is great, BlacKDicK! Eternal thanks. I would just like to make a suggestion. To prevent the average person from reading into the .j-files and snatching code, you could implement an option which makes the program parse through the file, replacing all the variables and function names with obfuscated lines of text which would make no sense to anyone. For example, udg_money would be replaced by var1101001101011011, while udg_lumber would be replaced by var1010110101100101, or something even more confusing. This might seem silly but I imagine it would be very effective. Anyone who ever has tried to disassemble a program will know what I mean. I doubt this would prove a challange to you, as you seem to have succeeded in programming things way more difficult. Regards, Peppar. |
| 07-14-2003, 12:52 PM | #85 |
k, I´ll try to implement this feature asap. |
| 07-14-2003, 05:37 PM | #86 |
But it must be optional! |
| 07-15-2003, 02:03 AM | #87 |
k, uploaded 0.2.0 with some changes: Please note that I had to rewrite lot of things, so this version can be unstable. Test your map/mpq first. Bugs are welcome Version 0.2.0 (07/15/2003) - Improved the AI/J/TXT optmization a bit. - Added an option to Obfuscate the script. Version 0.1.9 (07/14/2003) - Improved the code a bit. - Small GUI changes. - External listfiles can now be used. Note that if the source does not have an internal listfile and no external listfile is given, we´ll get an error. - Non-english LCIDs internal files are supported now. - Added an option to only add the english internal files. - Enabled more buffer-levels (0-2) if ZLIB is off. This was done as a workaround to minimize the WAVE-COMPRESSION "weird-bug?" with high buffer-levels. - I guess the (attributes) generation is finished. Note that by using "include attributes" the average LOCK speed will be slower since I need to do some CRC checks. This will not affect the loading time. - Added a small check to the main compression routine to avoid negative compression rates. If a file turns to get a negative compression rate, we will add it back with no compression. |
| 07-15-2003, 10:20 PM | #88 |
The obfuscating seems to work! Thank you for accepting my (My friend MMads) idea :). Although I have been unable to test it ingame (My RoC WE has given up on me, and FT is on the buylist) I detected some flaws: The obfuscation-program seems to match partial variable names, which leaves the rest of the name unobfuscated. E.g. if udg_one is declared before udg_one_two then udg_one will be replaced by <nonsense> while udg_one_two will be replaced by <nonsense>_two. Local variables are also not obfuscated. One other bug is that when you have maps with long file names parts of the name is appended to the output name if the output name is short. Another very, very small bug is that the Clean TXT/J/AI-option is unconditionally re-enabled (un-greyed) after Lock Map is unchecked, which means you can un-check it while keeping the Obfuscate Script-option checked. (Which you shouldn't be able to do). Good luck. |
| 07-19-2003, 02:46 AM | #89 | ||||
Quote:
What do you mean exactly? Quote:
I was only referring to when you are making new archives, not modifying existing ones. Quote:
The next version will have exactly that. :D (actually, my current build already does) I'm also planning on adding a new feature for MpqCompactArchive (probably will be in a new function named MpqCompactArchiveEx). It will allow changing the block size and recompressing all of the files. Quote:
It's because the first block is not compressed with the wave compression, so increasing the block size increases the size of that block that isn't compressed with wave compression. |
| 07-19-2003, 03:35 AM | #90 |
Hey, thanks for the info SF. I was kinda "lost", that's why i asked some "non-sense" questions here. Nvm. Just 2 small things here: 1) Whenever I add a file and it turns to get a negative compression rate (no compression at all), the file is added as "raw file" but the file flags still retains the "C". SFMPQ is probably already checking if the file is not compressed and then adding the file as a raw file, but the file flags are not updated and the file-blocks header is also there. If I add a 1 byte file (meaning it will not get compressed at all) it will actually take 9 bytes inside the MPQ (1 byte from the file + 8 bytes from the blocks header). 2) Taking a look at Ladislav sources I noticed that MAFA_COMPRESS_WAVE2 is used with "MONO" waves while MAFA_COMPRESS_WAVE is used with "STEREO" waves. SFMPQ already features this, I just think you could use this small improvement with WINMPQ, rename those constants or even split MpqAddWaveXXX to MpqAddMonoWaveXXX / MpqAddStereoWaveXXX. Peppar, I improved it a bit (0.2.1), but i think local variables will not be obfuscated. I think it is pointless do that. It would require a lot of extra coding, wich would turn to be useless. The script is already getting pretty much obfuscated. |