Fresh install on new computer: stuck at checking ressources

You have to understand how the patcher works to know why.

It patches all files based on their hashes. The patch server keeps a master list of all the files as well as their file hashes.

When the patcher starts, it downloads that master hash list, then checks each one against the local system to determine if the file exists, and if its hash is the same or different.

If the file doesn't exist locally, it marks it for download and continues on. It still has to check each file.

Doesn't matter what type of drive/disk it is installed to.. the only thing that affects is the speed at which it can check. The number of files is still semi-prohibitive.

No matter if the file is there or not, it still has to do a disk hit to check for either existence or matching hash. The good news is that the hash is cached as part of the content file and does not need to be recomputed each time.

Apparently, you are reading into my posts more than is intended. There was no "patronal tone" to my post. It was simply meant to be informative.

Since you still don't seem to understand how the patcher works, let me go into a little more detail.

The Content.ggpk file is an "archive" type... similar to zip files, but specific to GGG technologies. It is like a mini filesystem all wrapped up into a single file on disk.

Like a normal filesystem, it has a header block meant to keep track of which files exist in the content.ggpk archive, as well as their saved hash. This is the block that also tracks existence of files or deleted files. When a file is "deleted", much like your hard drive, the data itself is NOT actually removed. It is simply marked as "free". This allows new write operations to re-use that "free" space. In the case of a brand new Content.ggpk file that doesn't have anything in it, it still CREATES the Content.ggpk file and the internal format, but the header block is basically empty at that point.

The slowdown comes in this regard in that there are THOUSANDS (many thousands) of files it has to check for existence. I haven't counted recently how many there are, but each and every client asset you see in-game (including shaders, sound effects, music, bitmaps, textures, etc) are included in this Content.ggpk file. There are a LOT of files to check. The check for existence is also NOT the same as how it checks on-disk for file existence. It's a similar method, but is compounded by both the filesystem (os) check for LOCATING the Content.ggpk file, as well as then the internal header check.

I'm not saying this process couldn't be improved. It certainly could. I'm explaining how it CURRENTLY works. This is not the Feedback/Suggestions forum. If you want to suggest changes to their system, I would recommend doing it there. This is the Technical Support forum where we attempt to assist with issues based on how the system currently works.

Again, this is only part of the slowness as it has to calculate this WHOLE process (except the master hashlist) for every single file listed in that hashlist... which is quite large.

The reason they cannot do a "current image" is that the "clean install" version is quite infrequent in comparison to the other patching methods, and it eats up quite a bit of space and bandwidth. Once that "current image" was installed, it would have to go back to the current process anyway where it only patches the different files.

Another thing to keep in mind for many people is that often times they aren't running as Administrator, so the patcher can't actually access the Content.ggpk file (although it doesn't say this and likely should), and often times people are running ACTIVE antivirus protection which scans EVERY file operation for potential malice. This greatly increases the processing time for EACH file that is needed. EVERY time a program attempts to access the hard disk, antivirus has to check it first. Most people who are running active protection don't remember to disable it (or uninstall) before patching.

There are many reasons why patching can be slow for people... it's also likely very different on a case by cases basis. That's why we like people to create their own threads so we can attempt to figure out which situation is affecting them.

Hopefully I've answered your questions. This is not a Discussion forum, nor is it a Feedback/Suggestions forum. If you would like to further discuss the patching process, I would recommend the Discussion forum. There might already be threads there in which you can discuss it. If you would like to offer suggestions or feedback about the current patching process, I would recommend either the Feedback or Suggestions forum appropriate for your post.

Good luck.