aluigi, posted Sat Oct 18, 2014 11:32 am (1000)

---

I can do nothing else.

anarkad, posted Sun Oct 19, 2014 9:31 am (1051)

---

aluigi can you send me this script in version 1.2 ?

aluigi, posted Sun Oct 19, 2014 3:24 pm (1058)

---

The only different between 0.1.2 and 0.1.2a is comtype:
0.1.2: comtype unzip_dynamic
0.1.2a: comtype deflate_noerror

As already written in my previous post, deflate_noerror is the correct one, unzip_dynamic is wrong for the reimporting.

shadow_lonely, posted Tue Oct 21, 2014 10:34 am (1097)

---

aluigi wrote:

Ok that's probably my fault, I used unzip_dynamic that is not "reimport-friendly" because it automatically handles zlib and deflate compressions so when you reimport the file it chooses the zlib one (the most diffused).

I have updated the script to version 0.1.2a that instead uses deflate_noerror which should work correctly with reimporting.
The link to the script is the same: http://aluigi.org/papers/bms/others/the_evil_within.bms

You do NOT need to re-extract the files, the only thing that changed was the compression algorithm which is 100% compatible with the previous one, so try reimporting one non-modified file with this 0.1.2a script and tell me if you still experience crash problems.

I reimport successfully with .lang file. But with .dat and .bimage (font and coordinates). Game is stopworking:



Thanks!

aden34, posted Tue Oct 21, 2014 4:55 pm (1115)

---

edit: nevermind figured it out! thanks for the script!!

shadow_lonely, posted Thu Oct 23, 2014 5:28 am (1147)

---

aluigi wrote:

http://aluigi.org/papers/bms/others/the_evil_within.bms

Some filenames are duplicate but I don't know why, the script seems correct.

Could you share me first script the_evil_within.bms? Thanks! With current script, I reimport text file successfully, while font file is not!
Thanks!

aluigi, posted Thu Oct 23, 2014 3:49 pm (1151)

---

The current one is the only available, any previous script was wrong and not working.
The same fact you say that you reimported something with success means it works.

michalss, posted Fri Oct 24, 2014 6:05 am (1156)

---

Just for PC for consoles it does not work!

aluigi, posted Fri Oct 24, 2014 8:35 am (1159)

---

If the script works in extraction mode with the console archives, then there is nothing I can do for the reimporting.
If the script doesn't extract the console files, I need to fix it.

michalss, posted Fri Oct 24, 2014 8:52 am (1161)

---

aluigi wrote:

If the script works in extraction mode with the console archives, then there is nothing I can do for the reimporting.
If the script doesn't extract the console files, I need to fix it.

Export work on all platforms, just reimport does not work on consoles that is p... off

shadow_lonely, posted Sat Oct 25, 2014 10:21 am (1184)

---

Here is after reimport 24.bimage without edit with origin common.tangoresource:





Could you help me?

disastorm, posted Sat Oct 25, 2014 7:08 pm (1193)

---

I can also confirm that reimporting most files doesn't work properly. It seems to be the compressing part that doesn't work properly.

Exporting and reimporting the exact same file will cause the game to crash.
However, if you remove the "clog" and use only the "log" (keep the files compressed) you can export and reimport the same exact file fine.

Also, if shadow_lonely says he successfully imported a .lang file but nothing else, perhaps that specific file is not compressed, which would explain why it reimports properly.

aluigi, posted Sat Oct 25, 2014 7:13 pm (1194)

---

I guess that's caused by the non-standard method used to compress the files, that's the reason why I have used deflate_noerror instead of the classical deflate.
It's the only explanation in my opinion.

disastorm, posted Sat Oct 25, 2014 7:15 pm (1195)

---

Is it expected that the number of NAMES are actually alot higher than the number of FILES in the script? For example, When I open some of the tangoresources in notepad I can see that some of the names are .md6mesh files (or something similar to that name) but when extracting them they don't actually get extracted as a file.
This led me to print out the values of NAMES and FILES and there are actually alot more NAMES. Is this normal?

aluigi, posted Sat Oct 25, 2014 7:21 pm (1197)

---

It may be possible, in fact tangoresource has a separate section for the names (2 types of names per entry) and then it continues just like the other archives.

Do you mean that you get filenames like 00000000.dat instead of the real filename?

disastorm, posted Sat Oct 25, 2014 7:40 pm (1198)

---

No I just meant that there were names I saw in the tangoresource that had no file extracted. The example of the mesh name was just an example.

aluigi, posted Sat Oct 25, 2014 8:03 pm (1199)

---

I have just re-verified the tangoresource sample provided in the first post.
I made different tests:

• use the first name in that particular field available only in tangoresource
• use the second name in that particular field available only in tangoresource
• using "i" instead of NAME_IDX when getting the filename, I have done this for both the previous point and the current script

The result is that the names available in that particular field (just like those md6mesh names you have seen) they are wrong because the content of the file don't match the name, so you will have some "decl" files that are text (correct) and others that have binary content (wrong).

The only solution that perfectly match all the files is the current script.

That thing about the duplicated name is correct too, it seems like the archive contains also old copies of the files.

And last note, at the end of the extraction quickbms tells the percentage of file that has been covered, if it's over 95% for file 0 then it's all ok. For tangoresource it's 99%.

I hope the results of these tests are useful.

disastorm, posted Sat Oct 25, 2014 8:26 pm (1200)

---

thanks for testing

shadow_lonely, posted Sun Oct 26, 2014 7:04 am (1203)

---

Thanks. Waiting for you.

disastorm, posted Sun Oct 26, 2014 6:36 pm (1224)

---

I'm not sure if its useful at all, but I noticed the console of the game has a command called compressFile.

However, after compressing a file and adding it back to the tangoresource ( with clog removed ) , it still didn't work, so it would seem the in-game console's compressFile command is still a different compression than what is used in the resource.

btw i think shadow_lonely is waiting to see if you can help him with his 2 screenshots comparing the tangoresources.

shadow_lonely, posted Mon Oct 27, 2014 1:51 am (1229)

---

disastorm wrote:

I'm not sure if its useful at all, but I noticed the console of the game has a command called compressFile.

However, after compressing a file and adding it back to the tangoresource ( with clog removed ) , it still didn't work, so it would seem the in-game console's compressFile command is still a different compression than what is used in the resource.

btw i think shadow_lonely is waiting to see if you can help him with his 2 screenshots comparing the tangoresources.

First, I will upload 2 file console and pc for him! And I will continue testing.

michalss, posted Mon Oct 27, 2014 7:36 am (1230)

---

Im not good with compressions, but i would kill for repack possibility in this game and special on console(x360) Same shi... happend to me with game Call Rage, exact same problem on fonts

chopper2882, posted Mon Oct 27, 2014 8:19 am (1231)

---

tangoresource repack success with zlib. (PC & XBOX360)

here is some result.

michalss, posted Mon Oct 27, 2014 9:14 am (1232)

---

how did you do that ? I was trying to make it work on X360 and no success Can you please share script or tool whatever ?

aluigi, posted Mon Oct 27, 2014 10:11 am (1235)

---

To anyone:
I would like just to clarify that for me the script is currently complete and at the moment there are no new improvements or research to make on it.

It will be updated only if there will be something to update (fix and new research provided by other people).