Quickbms features doubt

[rabatini]

Buona Notte Luigi!

I have a question, is there any function to update the size of files that were previously in the container by reimport?
Let me try to explain, when we do a simple extract scripts we inform the offset and size of the file and in some cases we use xmath right?
let me give you an example:
I have a "pak" file and I extract several other files from these paks giving the offset and size, so I made my changes and one of the extracted files was smaller than the original, currently quickbms imports everything perfectly, but it doesn't update the size in the header list.
Would it be possible to do that?
Why am I saying this?
There are many games that checksum the size of the file, so if the file is smaller it is necessary to change the header list manually.

Grazie!

[aluigi]

Unfortunately there is no way to update fields that aren't the direct offset/size/compressed size of the extracted file (reimport2 also supports reversed math operations performed on these 3 fields).

It's impossible to instruct quickbms to calculate the new archive/data size field if used in the archive, or the crc of the specific file, and so on.

I can't imagine any way because they are all complex and format-specific operations, like the crc which is madness: many algorithms, some fields referring to the compressed data and others to the uncompressed one, data that needs to blank some parts for crc calculation (like some headers like TAR), algorithms not available in quickbms and so on.

Obviously I'm open to new ideas, even a new bms instruction as long as it's simple to implement, works on almost all the possible situations, and it's easy to understand for the users.

[rabatini]

I thought that I could read the files in the directory and get the size of each one and put it back in the header.

Many people use quickbms to extract the files that are in packs to edit them, some files that are in that pack are compressed and an external program is used for this and what happens is that often the file has a very small change of size. (smaller in the case)

I asked this earlier, because I recently made a tool to decompress and compress fla2 files,
inside a .dat, there are thousands of fla2 so I use quickbms to extract them and use my tool to do the decompression and compression service and some of these files get smaller, when I re-import with quickbms, I have to manually point out the new size in the header, due to a game check, which makes it crash if the pointed size is different from the file size.
I even made a powershell script to get the size of the files in the folder, I use it to update my header, it works in someway, but it would be wonderful if quickbms identified the size of these files and adjusted it automatically.

Anyway, thank's for your time.

[aluigi]

I think I don't understand.

reimport2 already modifies the offset/size/zsize fields of each file.

The case of FLA2 is different because it's a one-file compression so reimporting would have not much sense there, it's more practical to recreate the file because it also has a simple structure.

With my previous post I was talking about other fields unrelated to those used to dump each file from the archive.

[rabatini]

I see, reimport2 do the job, i just did not know that!

thank you Luigi!

have a nice day.

[aluigi]

Oh cool.

Anyway I'm working on the command ImpType that was available in the original MexScript (the original bms language) but wasn't used in quickbms because useless for the reimport feature.

Well, I'm expanding it with some basic features like updating a variable inside the archive, or writing a field at a specific offset, or even updating the crc/hash of a file (a much wanted feature) and the results are very good.
I will announce the new beta in the "Possible next features" topic when it will be available.