ZenHAX

Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Wed Mar 20, 2019 5:15 pm

All times are UTC




Post new topic  Reply to topic  [ 67 posts ]  Go to page Previous 1 2 3 4
Author Message
PostPosted: Sat Dec 08, 2018 2:00 am 

Joined: Sat Nov 12, 2016 4:29 pm
Posts: 3
Is it possible to add the possibility to create an archive containing only the edited files?
I mean, if the process of reimporting works it's ok and all, but if someone wants to release only a small patch it becomes a bit strange if the patch is larger than the original archive.
If someone edits only a few MBs worthy text files it would be good to be able to reimport only them. There are games which natively supports patches, so it would be cool if the reimporter could simply create a new archive containing only the edited files and ignore the untouched ones. As of now, if I delete the unused files, the program will simply keep the original ones and add the others.
I don't know how hard this feature could be to implement, I'm just making a suggestion of improvement. Thanks.


Top
   
PostPosted: Sun Dec 09, 2018 10:14 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 9946
If you want to distribute a patch you can use those tools that create delta patches. Basically you are going to distribute only the "difference" between the old archive and the new one.
Quickbms can only reimport the files.

There is an experimental option that allows to set the content of the files in the archive to zeroes, it's an idea for various possible usages, but it's totally useless in this case because the game is going to read the references to the zeroed files.


Top
   
PostPosted: Sun Dec 23, 2018 11:32 am 

Joined: Thu Sep 04, 2014 9:34 pm
Posts: 24
Just use u4pak (https://github.com/panzi/u4pak).
Basically it can make a new .pak file with only the edited files in it, and the game reads from it (so if you only edit the .locres file, just pack it into a .pak file, and the game will use that).


Top
   
PostPosted: Sun Dec 23, 2018 11:19 pm 
User avatar

Joined: Mon Apr 09, 2018 11:09 pm
Posts: 124
lostprophet wrote:
Just use u4pak (https://github.com/panzi/u4pak).
Basically it can make a new .pak file with only the edited files in it, and the game reads from it (so if you only edit the .locres file, just pack it into a .pak file, and the game will use that).

Doesn't work on Darksiders III.


Top
   
PostPosted: Thu Jan 24, 2019 11:41 am 

Joined: Wed Jan 23, 2019 9:50 am
Posts: 5
I want some files to be deleted from .pak file, so I made files with the same filename but with zero size (0 byte), and when I use reimport2 to add them instead of the original files, it fails. How can I do that?


Top
   
PostPosted: Tue Feb 26, 2019 8:55 am 

Joined: Tue Feb 26, 2019 7:14 am
Posts: 2
Hello .,
I have a suggestion.

Can we keep TOC and all asset chunks SEPARATED in real device
(when the game engine accepts uncompressed/unencrypted asset chunks),
and make a virtual file which (virtually) merges them together?
(that means, for example, copy /b TOC.0+chunk.1+chunk.2+...+chunk.999 arc.bin on REAL device, is same as that VIRTUALIZED arc.bin)

The reason is,
most game archives nowdays are made to stuff bluray disc, they're very unfriendly to PC storage.
If we keep asset chunks separated, we can hardlink all the duplicates and apply OS native compression on specific type of asset.


For example,
In Yakuza0, all archives (*.par) sums up 13.9GB,
after unpack, hardlink the duplicates, and apply "compact /C /I /S /EXE:LZX", it results 6.7GB.
Also many Unity indies have a lot duplicated large textures in their game archive.

I know this can be done with a kernel32 proxy dll, with CreateFile, ReadFile, SetFilePointer etc. hooked,
But I am looking for a more generalized solution like Dokan/Dokany (github.com/dokan-dev/dokany) , pfmap (pismotec.com/download) or CBFS (http://www.callbacktechnologies.com/cbfsconnect).


I actually made a QuickBMS-fs with Dokan before, which similar to: github.com/dorvan/chunking-filesystem,
for random accessing without extracting the whole archive (lost those codes as my old laptop hard drive broke).

Now I hope this can be supported natively. (in reverse way)









In conclusion,
I think keep separated/split chunks on real hard disk, and feed the game executable with a virtually merged archive,
can fulfill these two purposes:

1. Reduce disk space waste on PC due to the console/BD disc-affiliated archiving.
(duplicated asset across archives, both compressible and incompressible type of resource in one archive ,etc)

2. Avoid repeatedly packing/unpacking when moding, which can actually harm your hard drive.


Last edited by moiennepe on Tue Feb 26, 2019 11:58 am, edited 1 time in total.

Top
   
PostPosted: Tue Feb 26, 2019 11:04 am 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 9946
quickbms works sequentially on the archives and doesn't maintain a "status" for each entry.
In that situation quickbms should first work in "list" mode (like -l) for collecting all the files entries.
Then maintain this tree for the virtual filesystem.
When the user selects the file try to "recover" the status of the file entry (that isn't available) for reading the file.

It's a huge work on which I already tought various times years ago, last time was when I implemented the ISO and ZIP file output.

Best solution is having a PC with 32Gb RAM and creating a ramdisk of 24Gb where extracting the files, problem solved :D


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 67 posts ]  Go to page Previous 1 2 3 4

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