FFXII .vbf format

[EcheloCross]

Yeah, it does take some time when moving the 30gb the first time. After that its smooth sailing though. I don't see why your method would have issues with the files that contain more 64kb chunks though. If you move just the first few files to the end, it gives plenty of space to re-write the compressed chunk sizes so your method should be good. I was only suggesting to move the 30gb because you mentioned that files that when modded contain more 64kb chunks than the original may cause an issue.

[ffgriever]

Yeah, it does take some time when moving the 30gb the first time. After that its smooth sailing though. I don't see why your method would have issues with the files that contain more 64kb chunks though. If you move just the first few files to the end, it gives plenty of space to re-write the compressed chunk sizes so your method should be good. I was only suggesting to move the 30gb because you mentioned that files that when modded contain more 64kb chunks than the original may cause an issue.

Ah, ok. Now I get it. You were just trying to solve a problem that doesn't exist. Sorry, I probably wasn't clear enough. The tool works perfectly and as intended. There is no problem with rebuilding the TOC nor anything I know about. It's been tested quite thoroughly and only problem I know about was someone trying to modify vbf archive in program files directory without admin privileges (which obviously failed).

I wasn't updating it because it was all I actually needed to complete the task I had.

There is one problem that might occur, though - if a user completely rebuilds the archive with another tool and doesn't remove the vbf_extra.bin file, there will be a mismatch between offsets and sizes in the extra file and real files, so that could cause some issues - the check is done by offset, so it's still very unlikely to cause issues. I could make a check for such a scenario, but it's very unlikely to happen, tbh.

I wasn't describing the problem I had, rather explaining the solution to a problem, things I've done to make it work. You see, I'm that kind of person that you'd rather not ask for a technical advice. I will give you a solution, but then I'll feel obliged to teach you how to get to that solution yourself, then how to solve any similar problems... and probably how solving a problem works at all. After half an hour you're wondering why won't he shut the F. up, because you don't actually need to know how to solve the problem, you just need a solution.

TL;DR;
Thank you and sorry, it was just a misunderstanding.

[ffgriever]

Just to get the PC version on par with the tool I made for nintendo switch.

https://ff12.pl/down/ff12-vbf-20190517.7z

Code: Select all

FF12 Zodiac Age (PC) vbf tool v1.4 by ffgriever

Usage: ff12-vbf option input output

Options:
        -c              creates output vbf from files in input dir
                        (output defaults to {input}.vbf)
        -a              replace or add new files in output vbf with files in input dir
                        (output defaults to {input}.vbf)
        -i=pattern      semicolon separated list of patterns to ignore
                        (defaults to: "*/desktop.ini; */thumbs.db;")
        -r              replace files in output vbf with files in input dir
                        (output defaults to {input}.vbf)
        -u              unpack vbf into output dir
                        (output defaults to {input}_dir)

So since the last version:
- minor fixes
- option to create a new archive
- option to both replace already existing and add new files to an archive
- option to define a pattern for files that have to be ignored during creation/adding
- I've also made the compression multithreaded. It operates on blocks within one file, so on files smaller than block size (64kB) you won't see any dfference and the best speed will be achieved on files greater in size than "number of cores/threads" x "block size". With some intermediate buffers it could work for smaller files, but I don't think it's really worth it, considering, that people usually just replace small amounts of files, so it wouldn't save more than a few seconds. Anyway, compressing back all 50GB of game files takes now ~4 minutes on my machine instead of 25-30, so it quite a nice time saver (not that I compress the archive very often, only for testing, there is a reason I made the replacement tool).
- I significantly decreased file i/o operation count, so it should work a little bit faster with HDDs.

Also, I've changed compiler from gcc to ms vcc, so instead of the previous dlls, it needs vc++ redist, but most people already have it installed.

For more info regarding usage and reasons for some workarounds see post on the first page: https://forum.xentax.com/viewtopic.php? ... 48#p137847