Cyberpunk 2077 Update 1.11 Fixes Game-Breaking Bug Caused by Patch 1.1

News
By
published

A hotfix to fix a patch.

CD Project Red CB2077 Hotfix 1-11
(Image credit: CD Projekt Red)

There's a new Cyberpunk 2077 patch making the rounds, and the sole reason for its existence is to fix the bugs introduced from the previous patch. 

When CD Projekt Red released patch 1.0 for Cyberpunk 2077, it broke a critical mission in the game, introducing a game-breaking bug. During the quest "Down on the Street," those with Cyberpunk 2077 version 1.06 save data and then updated to patch 1.1 had noticed that the dialogue options were missing during the "Wait For Takemura's Call" segment. This prohibited game progression and, as you can imagine, frustrated those making their way through the game. This bug affected all versions of the game.

While hotfix 1.11 was released to fix the game-breaking bug, the item randomization was rolled back to pre-patch 1.1 as well. Visit CD Projekt Red's website for more info for a full list of changes.

Before installing this hotfix, make sure you have enough space to do so. Multiple users have reported that at least 60GB of space is needed during the installation process for the game's GOG version. In comparison, the PlayStation 4 and Xbox One versions need at least 15GB free to install the update.

At this point, I'm just waiting to see what else happens. Fingers crossed that this hotfix 1.11 doesn't introduce any other unforeseen issues.

Cyberpunk 2077 is now available on PlayStation 4, Xbox One, PC, and Google Stadia worldwide.

Keith Mitchell
Keith Mitchell

Keith Mitchell is a Contributing Writer for Tom's Hardware US. He is an IT professional during the day, and a passionate lover of video games and tech after his 9-5 grind. He has a weird affinity for Soulsborne games and plays them non-stop.

11 Comments Comment from the forums
  • Colif
    When is the next patch that fixes the bugs introduced in this patch?

    And they say Windows 10 is bad... at least it worked on release :)
    Reply
  • AgentLozen
    I don't have a ton of coding experience under my belt but I was under the impression that a game engine is a bunch of code segments tied together in a big code network. Then the engine calls in assets like textures, geometry, voices, music, and lighting and directs it where to go and how to act. Is this right?

    If my perception about how a game works is correct then why do I need to download 16GB of data to change the broken logic that causes all the bugs? Can't I just replace the bad code segments?

    Analogy - The windows in my house are drafty and I make an appointment with the window company to have it done. The next day, a construction crew comes to my house, bull dozes half of it, then gradually rebuilds it over three months. This confuses me because it seems like they could have just replaced the windows without bulldozing my house.
    Reply
  • Jesse_20
    I think the problem here resides in the fact that the "new windows" have features that the old ones didn't, and are therefore incompatible with the "old" windows. This could be something like a thicker pane, larger area, different frame material, etc.

    But for whatever reason, the old and new are not just drop-in replacements, except in a perfect world (which we all know Cyberpunk is Not)
    Reply
  • Sumsin
    This is not some 10 people indie studio which doesn't have a separate test team. This is the CD Project RED. They should have at least 25 people testing team if not 50 + independant beta testers. Either they don't know how to test a game and should be fired immediately or they don't have time and can't test patches according to test plan and also quit the job because this is continuously bringing their reputation down as a tester. I wouldn't work in a company which new versions create new bugs and these bugs can't be caught. It would make me look like a very weak tester and damage my career.
    Reply
  • jasonkaler
    AgentLozen said:
    I don't have a ton of coding experience under my belt but I was under the impression that a game engine is a bunch of code segments tied together in a big code network. Then the engine calls in assets like textures, geometry, voices, music, and lighting and directs it where to go and how to act. Is this right?

    If my perception about how a game works is correct then why do I need to download 16GB of data to change the broken logic that causes all the bugs? Can't I just replace the bad code segments?

    Analogy - The windows in my house are drafty and I make an appointment with the window company to have it done. The next day, a construction crew comes to my house, bull dozes half of it, then gradually rebuilds it over three months. This confuses me because it seems like they could have just replaced the windows without bulldozing my house.
    You're assuming that the only thing wrong was some broken logic.
    It reminds me of windows NT4 service pack 3, which was a complete download of the entire operating system when previously service packs only patched what was broken. In this case, it was the c++ compiler that was broken, so the fix actually had nothing to do with the windows code itself.
    This shows a few possible scenarios:
    Their tools that built and packaged the game were broken and thus had to fix the tools, which required all the assets to be rebundled
    rather than having to deal with updates that may or may not patch things depending on exactly which version each person has installed, they just did complete buildsBoth these deal with any cases where the new engine may not be compatible with anything from the old version
    3) They lost track of exactly what changed and where they went wrong and just decided a full install is better than a patch.
    Reply
  • jasonkaler
    Sumsin said:
    This is not some 10 people indie studio which doesn't have a separate test team. This is the CD Project RED. They should have at least 25 people testing team if not 50 + independant beta testers. Either they don't know how to test a game and should be fired immediately or they don't have time and can't test patches according to test plan and also quit the job because this is continuously bringing their reputation down as a tester. I wouldn't work in a company which new versions create new bugs and these bugs can't be caught. It would make me look like a very weak tester and damage my career.
    The testers reported those bugs. Even if it were only a 5 man team they would have spotted them. The tester's job ends at reporting the bug. After that it's managements decision if they fix it or push ahead to meet some deadline.
    To paint a picture of what it's like to work there, I found a quote from 3 years ago from someone working at CDPR:
    "Crunch here is insane," one reviewer said. "We read about Bungie's crunch and ME:Andromeda crunch and laughed. And crunch will hit current project hard. Because spreadsheet planning + incompetent overseers = hemorrhoids, bad back and depression."
    Reply
  • jasonkaler
    AgentLozen said:
    I don't have a ton of coding experience under my belt but I was under the impression that a game engine is a bunch of code segments tied together in a big code network. Then the engine calls in assets like textures, geometry, voices, music, and lighting and directs it where to go and how to act. Is this right?

    If my perception about how a game works is correct then why do I need to download 16GB of data to change the broken logic that causes all the bugs? Can't I just replace the bad code segments?

    Analogy - The windows in my house are drafty and I make an appointment with the window company to have it done. The next day, a construction crew comes to my house, bull dozes half of it, then gradually rebuilds it over three months. This confuses me because it seems like they could have just replaced the windows without bulldozing my house.
    perhaps the windows in your house are drafty because the foundation is skew? They may be the only piece you don't have to replace
    Reply
  • Sumsin
    jasonkaler said:
    The testers reported those bugs. Even if it were only a 5 man team they would have spotted them. The tester's job ends at reporting the bug. After that it's managements decision if they fix it or push ahead to meet some deadline.
    To paint a picture of what it's like to work there, I found a quote from 3 years ago from someone working at CDPR:
    "Crunch here is insane," one reviewer said. "We read about Bungie's crunch and ME:Andromeda crunch and laughed. And crunch will hit current project hard. Because spreadsheet planning + incompetent overseers = hemorrhoids, bad back and depression."

    Then test team only destroying their own reputation and career. If they are still working on there with their reports being ignored or postponed indefinetly, it's their fault. Should quit immediately.
    Reply
  • jasonkaler
    Sumsin said:
    Then test team only destroying their own reputation and career. If they are still working on there with their reports being ignored or postponed indefinetly, it's their fault. Should quit immediately.
    If I recall correctly, after each game at CDPR is released, 50% of their staff leave.
    It all starts off fun and games but ends up 100 hour work weeks. You're not credited if you don't see it through to release. I wouldn't be surprised if there was also a large amount of passive-aggressive backlash against management here.
    Reply
  • cryoburner
    Sumsin said:
    Then test team only destroying their own reputation and career. If they are still working on there with their reports being ignored or postponed indefinetly, it's their fault. Should quit immediately.
    I don't think there are many "AAA" game development studios in Poland, and CD Projekt RED is probably the most well-known internationally. I would hardly say that being a tester on Cyberpunk would be damaging to one's career, as other studios are going to be aware that the game's problems are largely down to management rushing out a release well before the game was ready.

    jasonkaler said:
    If I recall correctly, after each game at CDPR is released, 50% of their staff leave.
    That's likely mainly due to the nature of their development cycle. So far, CD Project has mainly just developed one big game at a time, with minimal overlap in-between. So unlike some other big studios that continuously have multiple games in various stages of development, where they can immediately shuffle employees to another title once their work on one is completed, they instead have periods of time when many of these employees are simply not needed. It's probably not so much that they "leave" as that they were only hired on as temporary help to begin with. What's a beta tester supposed to do when the game they are testing is finished and the next one is mostly just a collection of art assets and storyboards? While the gap can be somewhat filled with work on DLC and small spinoff titles, those generally won't require as large of a team as the initial release. Of course, for this game, they might be keeping more of the crew around for a while, as the game isn't actually "finished" yet.
    Reply