ZenHAX

Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Fri Nov 24, 2017 2:44 pm

All times are UTC




Post new topic  Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Fri Nov 10, 2017 3:46 pm 

Joined: Thu Mar 02, 2017 1:54 pm
Posts: 13
Hey, fairly new to all this.

I was unpacking a bunch of .ARCH05 archives from Shadow of Mordor (Using New_Fear.bms) and wanted to keep duplicate files. So when the dialog (or whatever you call that. Prompt?) came up, I pressed r, to have quickbms automatically rename duplicate files.
However, this landed me with a bunch of duplicate files with 0000000x at the end of their names, and NO file size.

I have looked through this document, which was all I found on google, and cannot quite decide if this is the intended behaviour of this function.
Does the zero file size mean that there is zero diference between the first file and the duplicate?
And in that case, what does QuickBMS do if there is a difference - does it store a file with only the difference?

I'm certain theres a system to all this, but I am a little confused...


Top
   
PostPosted: Fri Nov 10, 2017 5:38 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 7145
You get zero-sized files because they have no size. The renaming feature is not involved in that.


Top
   
PostPosted: Fri Nov 10, 2017 10:18 pm 

Joined: Thu Mar 02, 2017 1:54 pm
Posts: 13
aluigi wrote:
You get zero-sized files because they have no size. The renaming feature is not involved in that.


I have fiddled around with the goal of understanding, and you appear to be quite correct.
As always, sorry for the rudimentary questions, and thank you for prompt support!


Top
   
PostPosted: Sat Nov 11, 2017 9:21 am 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 7145
When you see something weird like may zeroed files remember to check the final value displayed by quickbms: "coverage file 0 " followed by a percentage.
If that % is bigger than 95% then it's all ok.
Remember that the coverage depends by the format, in some formats you can have a coverage of 100% while in others even 70% (small file and lot of padding) and both are correct.


Top
   
PostPosted: Sat Nov 11, 2017 10:15 am 

Joined: Thu Mar 02, 2017 1:54 pm
Posts: 13
aluigi wrote:
When you see something weird like may zeroed files remember to check the final value displayed by quickbms: "coverage file 0 " followed by a percentage.
If that % is bigger than 95% then it's all ok.
Remember that the coverage depends by the format, in some formats you can have a coverage of 100% while in others even 70% (small file and lot of padding) and both are correct.


I'm not sure that I understand this completely after running a second test.

When unpacked seperately using New_Fear.bms, two files, hosted here (sorry for size, they don't come smaller), will each produce an instance of the example file:
[Export Directory]\model\weapons\player_weapons\player_sword01\player_sword01_d.tex0
both have a size of 4.097 KB

However, when exported together, and hitting r when prompted, the files will produce two files in the same location: Good old player_sword01_d.tex0 and a second file player_sword01_d_00000001.tex0
The first has a size of 8.193 KB and the second has a size of 0 KB

Once again, sorry if I keep asking stupid questions, but I don't understand, is this the intended behaviour?


Top
   
PostPosted: Sat Nov 11, 2017 11:10 am 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 7145
Even without downloading the sample I think I understand what's happening.

I bet the samples have a "LTAR" magic at their beginning (you can check it with a hex editor), that means it uses the append mode with the compressed files, so it creates an empty file which already exists (it was generated by the previous archive) and you choose 'r' so this empty file will have the _00000000 suffix, then it will append the various chunks of the file but the output is the original filename and not the new _00000000.
Result: the old file contains both the old and new file while the new _00000000 file is still the empty one.

I have not checked the source code yet but I bet this is the bug, I will check and fix it in the next version of quickbms.
Good catch :)

Now, back to the original problem, you must use the -d option to handle multiple files from the command-line.
As far as I remember, from the GUI (double-click on quickbms.exe) when you select multiple input files the output files will be placed in a folder having the name of the input.
In command-line mode that doesn't happen by default and you have to specify this -d or -D option to do that, so you will no longer have duplicate files.


Top
   
PostPosted: Sat Nov 11, 2017 11:15 am 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 7145
Ah, regarding -d and -D.

Very quickly:
if you have many input files placed in various sub-folders, use -D
if you have some input files placed just in the same folder, use -d


Top
   
PostPosted: Sun Nov 12, 2017 4:35 pm 

Joined: Thu Mar 02, 2017 1:54 pm
Posts: 13
aluigi wrote:
Even without downloading the sample I think I understand what's happening.

I bet the samples have a "LTAR" magic at their beginning (you can check it with a hex editor), that means it uses the append mode with the compressed files, so it creates an empty file which already exists (it was generated by the previous archive) and you choose 'r' so this empty file will have the _00000000 suffix, then it will append the various chunks of the file but the output is the original filename and not the new _00000000.
Result: the old file contains both the old and new file while the new _00000000 file is still the empty one.

I have not checked the source code yet but I bet this is the bug, I will check and fix it in the next version of quickbms.
Good catch :)

Now, back to the original problem, you must use the -d option to handle multiple files from the command-line.
As far as I remember, from the GUI (double-click on quickbms.exe) when you select multiple input files the output files will be placed in a folder having the name of the input.
In command-line mode that doesn't happen by default and you have to specify this -d or -D option to do that, so you will no longer have duplicate files.


aluigi wrote:
Ah, regarding -d and -D.

Very quickly:
if you have many input files placed in various sub-folders, use -D
if you have some input files placed just in the same folder, use -d


Alright, this works great.
Thanks again (:


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 8 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited