aluigi, posted Tue May 08, 2018 9:39 pm (34778)

---

That's impossible because you can only edit the existent information.
Adding new files require the full 100% knowledge of the specific target format (and version) and a whole rebuilder.

unominhtuan, posted Mon Jun 25, 2018 4:25 pm (36208)

---

I used the reimport with a sequential file .... after the file was translated even though the new file = the original file size (uncompress size) .... but I was told "compress size bigger". If I make the smaller volume, my reimport file gets inserted "null" characters at the end and the game can not read ... do i have any solution for this?

aluigi, posted Wed Jun 27, 2018 3:23 pm (36230)

---

reimport2 can't be used for files stored in sequential way.
You need to use reimport.bat and being sure that your compressed/uncompressed files is smaller/equal than the original file.
Remember to use the backup copy if you already tried reimport/reimport2 and it failed, just to be sure it didn't corrupt the file.

unominhtuan, posted Sat Jun 30, 2018 1:00 pm (36306)

---

aluigi wrote:

reimport2 can't be used for files stored in sequential way.
You need to use reimport.bat and being sure that your compressed/uncompressed files is smaller/equal than the original file.
Remember to use the backup copy if you already tried reimport/reimport2 and it failed, just to be sure it didn't corrupt the file.

i use reimport.bat The size of the text file is smaller than the original file, file gets inserted "null" characters at the end, and the game can not read this file... only text file. model, font, video...do not have this problem

aluigi, posted Sun Jul 01, 2018 3:35 am (36319)

---

That's exactly how it must work so it's perfect from my side.
Your file is short and therefore it fills the difference (old size - new size) with zeroes.
If you want to avoid that make a file with the same size of the original putting maybe spaces at the end if it's a text file.

unominhtuan, posted Sun Jul 01, 2018 12:02 pm (36337)

---

Thanks aluigi, I'm also using this way

unominhtuan, posted Mon Jul 02, 2018 2:30 pm (36369)

---

aluigi wrote:

That's exactly how it must work so it's perfect from my side.
Your file is short and therefore it fills the difference (old size - new size) with zeroes.
If you want to avoid that make a file with the same size of the original putting maybe spaces at the end if it's a text file.

sorry for bothering me many times, i really have a problem. After "add spaces" to new uncompress size = old uncompress file, but only a number of files active ... some files are still quickbms automatically added "null" ... my game can not load the file containing the signature self "null" ....
I add spaces with hex editor, and make sure the new file = the original file
You can modify my quickbms.exe file. Instead of adding "null", it will automatically add "spaces" if the size is smaller than the original file. I wait for help from you
This is the image depicting the problem

aluigi, posted Mon Jul 02, 2018 10:04 pm (36378)

---

If quickbms adds null bytes it means that the size of the file is not the same of the original one. Simple.

Do you have script and archive for doing a test? Upload them.
I can't promise nothing because if quickbms does that it means it's perfectly correct, I just want to do a check in case there is a rare bug.

unominhtuan, posted Tue Jul 03, 2018 2:45 am (36386)

---

aluigi wrote:

If quickbms adds null bytes it means that the size of the file is not the same of the original one. Simple.

Do you have script and archive for doing a test? Upload them.
I can't promise nothing because if quickbms does that it means it's perfectly correct, I just want to do a check in case there is a rare bug.

i use this script http://aluigi.zenhax.com/bms/qq_sfc.bms

I have made the uncompress size = uncompress size of the original file. But, "compress size" is not equal, compress size is smaller than original file can reimport .... I have no way to both "uncompress size" and "compress size" = original file ... I use hex editor only Can edit uncompress size = original file

Or you can check this script so that it can get names, folders (not sequentially). Then I can freely reimport the file using reimport2.bat

aluigi, posted Tue Jul 03, 2018 9:56 pm (36407)

---

You can't use the reimport feature with that script for various reasons:
- sequential files require reimport.bat (no compressed/uncompressed size field modification, so no reimport2.bat)
- lz4 requires that the specified compressed/uncompressed size perfectly match the available data

Obviously it's rare that the compressed size matches the original one since it depends by the entropy of the file and the various settings and implementations of the compression algorithm.
Long story short: there is no solution except for manual hex editing or just writing a rebuilder from scratch.

unominhtuan, posted Thu Jul 05, 2018 2:42 pm (36509)

---

aluigi wrote:

You can't use the reimport feature with that script for various reasons:
- sequential files require reimport.bat (no compressed/uncompressed size field modification, so no reimport2.bat)
- lz4 requires that the specified compressed/uncompressed size perfectly match the available data

Obviously it's rare that the compressed size matches the original one since it depends by the entropy of the file and the various settings and implementations of the compression algorithm.
Long story short: there is no solution except for manual hex editing or just writing a rebuilder from scratch.

I still have to do you again ...
After using the hex editor, edit the size = the original file by "add spaces"
this is the original file:


file editing:


file after reimport:


? I think there was a bug in the script or quickbms that caused quickbms to auto-fix, adding "null" to make it bigger than the original file. from 16,777 to 16,813 bytes

Here are 3 files: original, my edit, after reimport:
https://drive.google.com/open?id=1HuEBcsYq-OBQC8vswJhNN5GPDgrOo3Gn

You can check it again
thanks

aluigi, posted Thu Jul 05, 2018 5:17 pm (36516)

---

Uhmmm no, there is no bug.

You can use only reimport.bat, NOT reimport2.bat as I said.

You didn't provide the original archive but I made a simple test here because the format is very simple so I created an archive from scratch and everything (extract->reimport->reextract) worked perfectly as expected.

If you have that wrong result with reimport.bat and quickbms 0.9.0 then upload the original archive.

unominhtuan, posted Thu Jul 05, 2018 6:22 pm (36523)

---

aluigi wrote:

Uhmmm no, there is no bug.

You can use only reimport.bat, NOT reimport2.bat as I said.

You didn't provide the original archive but I made a simple test here because the format is very simple so I created an archive from scratch and everything (extract->reimport->reextract) worked perfectly as expected.

If you have that wrong result with reimport.bat and quickbms 0.9.0 then upload the original archive.

i use reimport.bat and quickbms 0.90, not reimport 2.
Why reextract files (after reimport.dev) are resized?
original archive https://drive.google.com/open?id=1JAwJ7wKo7O_JA8W85YOUJYKviwBzVXtW

aluigi, posted Fri Jul 06, 2018 1:01 am (36530)

---

Finally I can replicate the issue with the archive and I confirm what I wrote few posts above:

Quote:

- lz4 requires that the specified compressed/uncompressed size perfectly match the available data

Now the technical explanation:

quickbms uses the following code for performing the decompression:

Code:

size = LZ4_decompress_safe_partial(in, out, zsize, size, *outsize);

where size is the expected decompressed size (for example 0x4189 in your case) while *outsize is the size of the output buffer that can be any number bigger than size (for example 0x41ad).

lz4 doesn't have a termination bit so it continues to extract data till the result is:

Code:

targetOutputSize >= result < dstCapacity

Code:

/*!
LZ4_decompress_safe_partial() :
    This function decompress a compressed block of size 'srcSize' at position 'src'
    into destination buffer 'dst' of size 'dstCapacity'.
    The function will decompress a minimum of 'targetOutputSize' bytes, and stop after that.
    However, it's not accurate, and may write more than 'targetOutputSize' (but always <= dstCapacity).
   @return : the number of bytes decoded in the destination buffer (necessarily <= dstCapacity)
        Note : this number can also be < targetOutputSize, if compressed block contains less data.
            Therefore, always control how many bytes were decoded.
            If source stream is detected malformed, function returns a negative result.
            This function is protected against malicious data packets.
*/
LZ4LIB_API int LZ4_decompress_safe_partial (const char* src, char* dst, int srcSize, int targetOutputSize, int dstCapacity);

Your reimported file DOES NOT have the matching compressed size 0xa97, it has something smaller like 0xa8d but still lz4 will decompress bytes which means also all the padded data between 0xa97 and 0xa8d till the dstCapacity is full.
That's why you see the zeroes in your reextracted file.

quickbms is perfectly correct in what it does, indeed your game isn't able to load the edited file due to the unmatching compressed size.

End of the technical explanation.

unominhtuan, posted Fri Jul 06, 2018 3:03 am (36532)

---

aluigi wrote:

Finally I can replicate the issue with the archive and I confirm what I wrote few posts above:

Quote:

- lz4 requires that the specified compressed/uncompressed size perfectly match the available data

Now the technical explanation:

quickbms uses the following code for performing the decompression:

Code:

size = LZ4_decompress_safe_partial(in, out, zsize, size, *outsize);

where size is the expected decompressed size (for example 0x4189 in your case) while *outsize is the size of the output buffer that can be any number bigger than size (for example 0x41ad).

lz4 doesn't have a termination bit so it continues to extract data till the result is:

Code:

targetOutputSize >= result < dstCapacity

Code:

/*!
LZ4_decompress_safe_partial() :
    This function decompress a compressed block of size 'srcSize' at position 'src'
    into destination buffer 'dst' of size 'dstCapacity'.
    The function will decompress a minimum of 'targetOutputSize' bytes, and stop after that.
    However, it's not accurate, and may write more than 'targetOutputSize' (but always <= dstCapacity).
   @return : the number of bytes decoded in the destination buffer (necessarily <= dstCapacity)
        Note : this number can also be < targetOutputSize, if compressed block contains less data.
            Therefore, always control how many bytes were decoded.
            If source stream is detected malformed, function returns a negative result.
            This function is protected against malicious data packets.
*/
LZ4LIB_API int LZ4_decompress_safe_partial (const char* src, char* dst, int srcSize, int targetOutputSize, int dstCapacity);

Your reimported file DOES NOT have the matching compressed size 0xa97, it has something smaller like 0xa8d but still lz4 will decompress bytes which means also all the padded data between 0xa97 and 0xa8d till the dstCapacity is full.
That's why you see the zeroes in your reextracted file.

quickbms is perfectly correct in what it does, indeed your game isn't able to load the edited file due to the unmatching compressed size.

End of the technical explanation.

I understand, sad that there is no solution. thank you

Qnoops, posted Thu Aug 30, 2018 9:59 pm (37961)

---

Im getting this error with unreal script, do you have any solution?

aluigi, posted Fri Aug 31, 2018 5:34 am (37968)

---

If quickbms gives that error then it means there is nothing to do.
Anyway what's the script you are using?

Qnoops, posted Fri Aug 31, 2018 5:40 am (37970)

---

Unreal tournament 4.bms

aluigi, posted Fri Aug 31, 2018 5:54 am (37972)

---

Honestly I don't know and I can't check now but you correctly used the 4gb_files version so that's excluded (because reimport.bat uses quickbms.exe and it causes conflicts).

aluigi, posted Fri Aug 31, 2018 6:08 am (37974)

---

Ah right, UE4 has the TOC located at the end of the archive and therefore you can't use reimport2 with it.
Yeah quickbms is perfectly correct returning that error

Qnoops, posted Fri Aug 31, 2018 6:40 pm (37988)

---

So it's mean there is no current solution for now, right? : D

aluigi, posted Sat Sep 01, 2018 12:33 am (38001)

---

It means that there will be no solution forever since it's a logic problem due to the fact that no new content can be appended to the archive.
Sure, it would be possible to "prepend" the new content but that causes big troubles and it's technically a mess (moreover with huge files like the UE4 paks)... so it will never be available.

Shokoniraya, posted Sat Sep 15, 2018 7:10 am (38398)

---

QuickBMS cant import2 a script with such tag and stuck in importing2

Code:

math OFFSET - 1024

Tomb-Rider9_(2013).bms

aluigi, posted Sat Sep 15, 2018 7:45 am (38400)

---

I don't see any problem, I created a file and a script with OFFSET - 1024 and in fact reimport2 works perfectly.

Do you have a game sample file?
What's the output of quickbms?

Shokoniraya, posted Mon Sep 17, 2018 5:42 am (38545)

---

aluigi wrote:

I don't see any problem, I created a file and a script with OFFSET - 1024 and in fact reimport2 works perfectly.

Do you have a game sample file?
What's the output of quickbms?

sorry, my archive was corrupt
i tested again and no problem, sorry, my bad.