Shokoniraya, posted Thu Sep 20, 2018 7:21 am (38643)

---

Shokoniraya wrote:

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

Code:

math OFFSET - 1024

How can i add exantion in Script?
x\02\xBF == ".rate"

aluigi, posted Thu Sep 20, 2018 8:12 am (38645)

---

@Shokoniraya
you are off-topic, anyway you can't add additional guessed extensions. They are hardcoded in quickbms.

Qnoops, posted Wed Oct 31, 2018 9:11 am (39988)

---

I'm trying to reimport a language file (locres) to .pak.

But the edited locres file is bigger than the original locres file, so it's importing with errors. Half of the texts doesn't show up in the game. I can't delete anything from locres file to make it smaller.


Any solution for that?

im using latest unreal script and latest quickbms.

aluigi, posted Wed Oct 31, 2018 3:37 pm (39993)

---

The reason why reimport2 can't work on archives like those of UE4 is the following: the TOC ("table of content", the information about the archived files) is located at the end of the archive.

For example this is the format of an UE4 archive:

Code:

########################TOC***
|                       |  |
|                       |  tail info with offset of TOC
|                       TOC containing info of the files
archived files

If reimport2 tries to add a bigger file at the end of the archive, UE4 will be no longer able to read the offset of the TOC (it's occupied by the new files).

Quickbms is a generic tool that must work with any type of format, therefore a soluton like copying the *** part at the end of the edited archive is not possible because quickbms does not know where that part starts and if the TOC offset is relative (like negative offset or the "size of TOC") or absolute (like in UE4).

What I can try to do is telling quickbms to check the "goto -OFFSET" instructions and record them as starting offset of ***, then copying that data after the reimport process.
It may work and it costs me nothing to try

aluigi, posted Wed Oct 31, 2018 4:26 pm (39996)

---

I implemented the new code in my quickbms 0.9.1 beta in few minutes and tested reimport2 with an encrypted UE4 archive: apparently everything works great

Qnoops, posted Wed Oct 31, 2018 5:21 pm (39998)

---

thank you brother from another mother father! : - D

hackspeedok, posted Mon Nov 12, 2018 3:58 am (40284)

---

I cant reimport with bigger files. This script: viewtopic.php?f=9&t=644
Can you help me ? Thanks

Qnoops, posted Mon Nov 12, 2018 6:01 am (40285)

---

aluigi wrote:

I implemented the new code in my quickbms 0.9.1 beta in few minutes and tested reimport2 with an encrypted UE4 archive: apparently everything works great

Where can i get the 0.9.1 beta? i need to reimport a bigger file to a .pak folder, thanks!

aluigi, posted Mon Nov 12, 2018 9:19 am (40286)

---

@hackspeedok
because TOC is compressed and therefore the new offset and size can't be rewritten.

@Qnoops
it's a private beta

hackspeedok, posted Mon Nov 12, 2018 9:23 am (40288)

---

aluigi wrote:

@hackspeedok
because TOC is compressed and therefore the new offset and size can't be rewritten.

Here are the files I need to reimport. Can you help me ?
Link: https://drive.google.com/open?id=1eNWl9 ... wZzJAtg2ks

If that is not possible, thank you for your interest

aluigi, posted Mon Nov 12, 2018 10:44 am (40289)

---

Not possible

valgor, posted Sat Dec 08, 2018 2:00 am (41115)

---

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.

aluigi, posted Sun Dec 09, 2018 10:14 pm (41174)

---

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.

lostprophet, posted Sun Dec 23, 2018 11:32 am (41587)

---

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).

ISKA, posted Sun Dec 23, 2018 11:19 pm (41594)

---

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.

torbido, posted Thu Jan 24, 2019 11:41 am (42719)

---

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?

moiennepe, posted Tue Feb 26, 2019 8:55 am (45287)

---

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.

aluigi, posted Tue Feb 26, 2019 11:04 am (45302)

---

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

ferhat78, posted Sun Nov 17, 2019 2:05 pm (52157)

---

hi, i have a problem with compressed file size.

when i use reimport2 it bypass file size problem but at the end it change original file size soo the game don't launch and stay on logo.

.bak file is the original file.

anyone can help me please ? thanks in advance.

ferhat78, posted Sun Nov 24, 2019 12:35 pm (52240)

---

ferhat78 wrote:

hi, i have a problem with compressed file size.

when i use reimport2 it bypass file size problem but at the end it change original file size soo the game don't launch and stay on logo.

.bak file is the original file.

anyone can help me please ? thanks in advance.

anyone please ?

luiscarlosapeu, posted Tue Jan 28, 2020 2:01 pm (53554)

---

ferhat78,

You're repeating editions..? I think you will only find susceptible stages of file corruption.
Did you repack the same file using Reimport 2 more than two/ three times?
Reimport1 I think is more flexible to reimport the main file countless times (although it is restricted to the same size for compression).
But as for Reimport2. I believe. Even if i have a vague experience of version 2. Use with great caution.
Because Reimport2 despite being a luxury tool to recompose all possible, considering the possibility to force the entry of all larger files, Remport2 is still inefficient for multiple reimports of large files to the same location, try to modify all your folders smaller, making last recomposition of all of them only once to the final file.
No Make rectifications of larger compressions several times to the final file, you must resort to the error and consequently to the compromise of your base.

luiscarlosapeu, posted Tue Jan 28, 2020 2:10 pm (53555)

---

Depending on what you are working on, it may not work, even if it is a compression performed only once by Reimport2.
If I'm wrong, correct me. But maybe Reimport 2 does not compensate or modify just once. Because functionally, it must generate many errors due to the disproportionality of the file becoming most of the time so large, which can cause conflicts depending on the root that the original file requires to be supported.
Sorry for the English.

aluigi, posted Sun Feb 16, 2020 3:54 pm (54062)

---

reimport2 is not efficient for multiple reimporting of the same file (like new versions) because the structure of the archive is modified everytime the updated file is longer (longer than the last update, not just longer than the original file), since it gets appended at the end enlarging the archive each time.

Pepita, posted Thu Mar 05, 2020 7:03 pm (54437)

---

I try to reimport Files after modify them into the APOC Client ( Ashes )

When I do so I get the following Message for every file:

Code:

KEY:
< 0000000000000000 0          Store\ItemDefinitions\Armor\Cape\APP_CMN_PLT_M_CPE_A_0.uasset

- Variable 1 ("0") at line 198 is constant but the script tries to edit it.
  Do you want to continue anyway (y/N)?

Doing so, makes the game crash on loading (He cannot read the Pack File at all)

Using the Old Method (Reimport v1) result in the following Error:

Code:

EpicAccountId:

Assertion failed: [File:Unknown] [Line: 3510] Pak Decompression failed. PakFile:../../../APOC/Content/Paks/pakchunk1-WindowsClient.pak, EntryOffset:616272857, EntrySize:161, Method:Zlib, ProcessedSize:393, RawSize:161, Crc32:3952538542, BlockIndex:0, Encrypt:0, Delete:0, Output:0000023B83AAA340, Raw:0000023B80753B80, Processed:0000000000000000, Bytes:[78DA030000000001000000000000000000000000000000000000000000000000...]

aluigi, posted Sun Mar 15, 2020 5:50 pm (54665)

---

unreal_tournament_4.bms is not good in reimport mode.
I guess there is some tool called u4pak that users use and it's discussed on this forum too.