"This patch need 55 Gb to be installed"

[Arcafonk]

Please, no. This have to change.

OR at least tell this in the minimum requirements : 77GB for the game + 10000 Gb for the installation. I had to uninstall hundreds of little games for you.

1. stop compressing your stuff like that
2. why are you delivering a whole pack on each patch, for "so few" corrections.

 

[yota71]

why this big? mi patch was just 8GB

 

[Gamebusters]

strange, I have this:

 

[yota71]

strange, I have this:
View attachment 11152493

first part was 1.2 gigs the second part is 8 gigs at least on gog

 

[Gamebusters]

first part was 1.2 gigs the second part is 8 gigs at least on gog

oh f**k I need to wait more

 

[Arcafonk]

Now I'm blocked with the previous version , I'm seriously considering uninstalling CP77 until 1 year, since I can't patch it now. I can't miss a patch and install the first that can install. The mess you made with the game at release makes you need 200GB forever !

Minimum requirements are not made for lulz !

I'm really disapointed, because this will fix only surface stuff and the game needs at least 5 or more times that amount of corrections, and 200 GB forever on my relativly small SSD : this is not cheap GB you can "steal" without telling it in min reqs !

And all of this is due to CDPR's compression algorithm, because your "real" patch must be 40 GB or something.
I know perfectly what is happening there. CDPR don't want to have micropacks for patches to optimize the streaming so they deliver wholes packs each time they touch a hairstyle of this NPC in a pack, so the game can profit AAA perf.

- DO TELL THIS IN THE MIN REQ ! "Hello, we screwed the release so this game need to be patch forever, and on top of these 77 GB, it will need extra 100 GB to be patched, well, like, forever".
- DO NOT DELIVER 5 PACKS IN THE SAME PATCH : DELIVER ONE BY ONE. IF YOU DO, DO NOT DECOMPRESS PACKS 5 BY 5 (!!!!!!!!)
- UNCOMPRESSED OR STOP TO ASK SSD FOR YOUR GAMES. We don't have infinite I/Os on these, esp with next gen consoles. I/Os may be one of the reasons Sony don't want you to infiny patch that game before selling it.

I don't perfectly know if the game tries to recompiles packs or not, but CP77 should have small packs if done rigth. Overwrite them instead of doing what you do. And maybe the game needs 1.1.1 then 1.1.2 then 1.1.3 then 1.1.4, and to be patched each day. But save the I/Os, or at least provide a solution instead of creating problems !

 

[RagnaBreaker]

Steam, right? It sometimes downloads all the previous updates instead of just the ones you're missing. Restarting the launcher fixes this for me when it happens (and it happens with other games as well).

 

[Arcafonk]

No, that's GOG.
The game already needs 200Gb+ to be installed with no patch.

Reason "must be" (not "should be") :
- the patch downloads, store on disk
- then install goes like this :
1. decompression of the whole *.pack and other files games are made (*)
2. decompressed .packs are temp stored in the disk => takes something like +22.5Gb on the disk in that 1.1 patch
3. when everything is uncompressed, overwrite old *.packs and other files of the game to patch it.
4. throw the patch file and temp files in the garbage bin.

Files being compressed makes the OS also needing virtual RAM to decompress it. So 22.5 of stored place on the disk + those 22.5 in virtual ram to work on + 10Gb the patch is made of = 55Gb.

That's :
a- because they use either a virtual ram decompression algorithm (which are common) instead of a ram one. The game is supposed to work on 8Gb systems though.
b- because they have a dumb instalation process which waits each file to be uncompressed before actually overwrite stuff on disk.

b is not cool here, but "easy to program" : error handling is easy (compressing an archive gives better results than having an archive of compressed stuff. But you gain what. 3% ? 5% tops ?).
a is uncompressing for noobs also.

This is a bad programming job imo (more like a typical software dude job, imo. Those cats can't handle hardware problems.)

---

(*) *.pack or *.file or *.... are just a low-compression/low-encryption format games can read. Like a tranformation in Z format : something unreadable by humans, but easy to read once you change the way you read it. It must be a no-loss transform (so any transform like jpeg/mp3 algorithms are forbid. If i remember my 20-years ago math course, Z-transform were no-loss, while Fast Fourier have loss
-edit- after a little documentation to remove 20 years of brain rust, the most commo of these transforms are Fast Discrete Fourier Transforms, where, I guess, the losses is set to be under half a bit so they can approximate results by the nearest bit.).

I then "think" they work that way :
In 32bits OS era, those files were ~1-3Gb long, so one can be stored in ram, adressed with 32bit long adresses and streamed to the GPU (1.9 or 2 were nice options, so you can swap one with another one, while one is still active. For "level games", you could have 3.5 ones, load one then next level, load another one. 500Mb left in RAM for drivers was okay at these times).
In those 64bits OS, these stays 2-4Gb usually, but they can load more than one at once : the texture one and the game logic are usually set on two different *.pack. CP77 recommends 8Gb+ so those files must be a littleless than 4Gb long (a little place have to be reserved for drivers). Or 2 Gb long and the game juggles with 3 packs with one loading.
When models pops up, games usually have trouble replacing *.packs from HDD / SSD with one to another. >>Like a bad 3-ball juggler when he have to 3 balls coming to hands and having only 2 hands, the third ball have to wait for another ball to be thrown before coming to hands creates an "hicup".

 

[dworsky]

Well my patch has 62Gb so far so WTF where is this 1,2Gb patch

 

[Arcafonk]

-update- "nice try" patching GOG to prompt we can switch temp folder in GOG. I did not know that, and I had not that prompt before.

I mean, yup, that's nice, quick, reactive, informative and "nice job". It should solve the native problem with most people.

Unfortunually, I'm not directly in that half.
(I have a SSD with 380GB where D:'s 100GB is eaten by Ubuntu, and on C:, 60GB-ish is eaten by GOG, 55GB-ish is eaten by AC:Valhala, Steam eats another 55GB-ish. Windows eats 25GB, then stuff like User, Program files & other folder makes me left 35GB.

But at least, it's on my side to find a 55GB usb key.

Thx for the message and the quick reaction and sorry for being grumpy.

 

[GZulu]

I also had a small 1.1gig patch before the BIG one on GOG.

On ps4 the update was over 40Gigs. That's a whole new game download right there.

 

[Arcafonk]

I ended throwing games I wanted to keep in the garbage bin.

Anyway : it's strange, because on GOG I also had 1.1 GB dl, not those 10GB something from steam. I don't understand the need for 55GB then.
They don't use KGB-like compression rates, since the install was almost instant.

This must mean the game is set in a special archive format, have to open it, replace one .pack by the one in the patch then reformat/close it, and that archive should be somewhere 54GB long total so the disk needs 54GB of virtual mem + patch length.

Why this is demanding 55GB ?????????

-edit- ok the reply is in C:\Program Files (x86)\GOG Galaxy\Games\Cyberpunk 2077\archive\pc\content
Things I called *.packs are called *.archive in CP77.

It weigths 58.9GB so if patching needs 55GB, this proves two things :
- the patching process is not made in sequence but at once. The patch installer needs to be able to open one *.archive, patch it, then close it (freeing virtual mem in the process), then open the next one, instead of opening everything, patch everything, then close everything.
- .archives's cryptography is easy to read / write for CPU (since patching is almost instant). So the algorithm is either super optimized or a well-known algorithm (I'd say FDFT for 70%).

With this, patching would "weigth" 11GB (biggest .archive) + size of the patch max. And if the user doesn't have those 12-15GB, well, he would have other problems coming from swap mem and this demand should be one of the cures to his problems.

OK, I agree this whole-at-once process simplifies the error handling (because you can roll back if something bad happens), but the user can always verify their games and then dl sain-up-to-date *.archive. In GOG and Steam, I guess.

Same with installation. For some strange reason, day1 at release you needed 120GB free disk instead of those 60GB. Was the day 1 patch process allready doing 60GB+55 ? Wasn't it easier to patch the mirror version ? (ok, """"""""""""""""""""""risky"""""""""""""""""""""", but come on are you professionals or not ? can the big guys in CDPR trusts their techies for once ?)

CDPR have to change that, esp for PS5 / XSX (where SSD upgrading is not a "so easy" option). So if they does bursts of patches, the PC needs to profit from that kind of deployement too.
CDPR have luck to patch these atm, when they are new consoles where +/- 2-3 games are installed.

 

[Valethaar]

GOG has always been terribly sloppy and slow with installs and patches.

I've read that they have servers in several locations, but I sincerely doubt it. The time it takes to download anything is ridiculous, much less the painfully slow decompress/install process. They definitely need an infrastructure upgrade, and some competent hires on the development team responsible for their installer coding. It shouldn't take nearly 2 hours for an 8GB download and install.

Edit: For comparison, I downloaded and installed Metro: Last Light Redux using GOG. It took 30 minutes start to finish, and clocked in at 8.4GB. Roughly the same size the 1.1 patch was on PC. Most of the 90 minutes for CP2077 v1.1 was 'installing', the files downloaded in roughly the same amount of time. The installer process for CP2077 is definitely lacking some polish or something, for it to take as long as it does.