GGPK Defragmenter
|
Using russian/ggc version.
Starting the game takes like 2 minutes, I see the process size growing VERY slowly, by 3-5MB at certain seconds. Did some extra testing, to check if it's my HDD going dead/funky: http://imgur.com/Z3OLHJj . Starting PoE slows HDD to crap. Will solutions from page1-2 of this topic help me? Last edited by soprof#5136 on Aug 21, 2015, 6:45:56 PM
|
|
|
Any way of defraging the game on the Steam version?
Steam- squurellkiller
IGN- Sir_Loots (Standard) |
|
|
1133,79 MB
22 minutes. Thank you! |
|
|
Didn't even take note from beginning. But has already cut at least 5 gb of. :O
|
|
|
Why won't GGG run a defrag after each patch? At least for the non-steam version? Also, I wonder why aren't the files inside the ggpk archive compressed?
|
|
|
My ggpk in my ssd , isit ok to use this tool to defrag the ggpk?
IGN: OP_Split
GMT +8 |
|
|
First Question: GGG can't defrag the content file because it would break how patching works and make it more like Steam and all-at-once and not file-at-a-time. They also don't compress most of files because it would take more CPU resources to decompress them before usage every time. You think asset loading is slow now, try again once you have to perform MORE steps to load them.
Second Question: you can use this with an SSD. It's not the same as a drive defrag. This cleans up and compresses the content file only. |
|
"More quick steps instead of less slow(no, SLOW) steps? Count me in! And worst change is putting almost all bosses in new version of maps into fucking small areas, where you can't kite well or dodge stuff. What a terrible idiot invented that I want say to him: dude flick you, seriously flick you very much.
|
|
|
What are you calling less slow and more quick?
The assets have to load regardless. Having them compressed means additional decompression steps during asset load. Decompression is very CPU intensive. That's why unzipping a large file that was compressed at max compression takes a lot longer than unzipping an archive with no compression. Compression makes the files smaller at the expensive cost of CPU time to decompress. In this case, the speed to space tradeoff, speed wins at the cost of space. |
|
" Except that algorithms exist for extremely quick decompression that do not use much CPU resources. These algorithms are even smart enough to do an "early abort" for stuff that the compressor detects is uncompressible or not worth compressing. Spending 1 IOP to read a 1 MB file then decompressing it is much faster than spending 1 IOP to read 2MB of data. |
|
