GGPK Defragmenter

"
Jonathan wrote:
"

The hashes are murmurhash2 on a lowercase'd copy of the entry's name, i think


The hashes for each filename entry in a directory is a lowercase Murmur2 hash. This is used to do fast traversal when looking up a file by path.
Minor correction/elaboration: it's a Murmur2 hash of UTF-16 bytes of the lowercase filename.

(was scratching my head wondering why hashing the filename from the data wasn't working)
I Googled "ggpk" out of curiosity/boredom and stumbled across this tool. I saved "only" about 100 MB but load time increased noticeably, from, say, one minute to less than thirty seconds.
"
I Googled "ggpk" out of curiosity/boredom and stumbled across this tool. I saved "only" about 100 MB but load time increased noticeably, from, say, one minute to less than thirty seconds.

I think you mean reduced.
Computer specifications:
Windows 10 Pro x64 | AMD Ryzen 5800X3D | ASUS Crosshair VIII Hero (WiFi) Motherboard | 16GB 3600MHz RAM | MSI Geforce 1070Ti Gamer | Corsair AX 760watt PSU | Samsung 860 Pro 512GB SSD & WD Black FZEX HDD
I am wondering if this is still safe to use or is there potential for getting banned now with the open beta and the new anti cheat prevention?
it worked for good 10minutes for me but im not entirely sure what im supposed to do with content2.ggpk, is it ok to remove it ? it takes ~5.4k gb 100mb less than Content.ggpk
IGN Crakk
Last edited by maryn on Feb 5, 2013, 9:19:28 AM
This thread got me thinking about file efficiency in the game.

This is regarding the shader cache files ...

Would it be true that if GGG limited the maximum size of these files to 1,024 bytes or less and if they were larger then spilt them ... that when the OS that reads the files from disk (NTFS) when it reads the MFT entry for the data .. it gets all the data at the same time and doesn's have to round trip the disk to do an actual file read.

e.g.

cache file 1 ( less than 1,024 bytes )

--> Read MFT
<-- All data returned with the MFT entry

cache file 2 ( greater than 1,024 bytes )

--> Read MFT
<-- Location of data returned (MFT Entry)
--> Disk Read to gather remaining data
<-- Remaining data returned
"
FcknGroovin wrote:
This thread got me thinking about file efficiency in the game.

This is regarding the shader cache files ...

Would it be true that if GGG limited the maximum size of these files to 1,024 bytes or less and if they were larger then spilt them ... that when the OS that reads the files from disk (NTFS) when it reads the MFT entry for the data .. it gets all the data at the same time and doesn's have to round trip the disk to do an actual file read.

e.g.

cache file 1 ( less than 1,024 bytes )

--> Read MFT
<-- All data returned with the MFT entry

cache file 2 ( greater than 1,024 bytes )

--> Read MFT
<-- Location of data returned (MFT Entry)
--> Disk Read to gather remaining data
<-- Remaining data returned
Why would dozens of reads to the MFT be faster than one and then a read elsewhere?
Tried multiple times to use this, seems my game likes to crash with it. Anyone else?
"
Nituvious wrote:
I am wondering if this is still safe to use or is there potential for getting banned now with the open beta and the new anti cheat prevention?


No, as this program (as I understand it) is simply moving the files around in the package, and deleting unnecessary blocks of data.

The game devs have commented about this program, so I doubt they would ban something that they use themselves.
"Minions of your minions are your minion's minions, not your minions." - Mark
This program is great, it reduced my loading time from 2 mins down to 30 secs. And saved 100 mb which I really dont care much about.

Report Forum Post

Report Account:

Report Type

Additional Info