GOG work with Geforce Now - I'm using this service all ultra with RTX ON and DLSS quality 
I wonder what is their deadline for patches. I mean, hotfixes seem to be for stuff that breaks the game in new and exciting ways thanks to the latest patch. The proper patch on the other hand addresses a big list of bugs and introduces improvements on many fields.
So do you think they are working on schedule and if something is not ready yet, they will leave that thing and release everything else instead?
Or does it work the other way: there is a set list of issues they are supposed to address and the patch will only be released when the entire list is ticked off?
It took them 14 working days to release Hotfix 1.21 after Patch 1.2 and I wonder if that is all they were working on, or is there a team constantly working on some big project and that big project will be released "when it's ready". Like the work on making the game work on consols or getting the traffic and crowds figured out.
So do you think they are working on schedule and if something is not ready yet, they will leave that thing and release everything else instead?
Or does it work the other way: there is a set list of issues they are supposed to address and the patch will only be released when the entire list is ticked off?
It took them 14 working days to release Hotfix 1.21 after Patch 1.2 and I wonder if that is all they were working on, or is there a team constantly working on some big project and that big project will be released "when it's ready". Like the work on making the game work on consols or getting the traffic and crowds figured out.
For me, no doubt, the second answer.
It would be the worst if they released a dlc while there are still many bugs / problems in the main game.
(But it's just my opinion)
good to see they are really putting some love in the game fixing some of the issues ... cant wait to see new content after keep up the good work choombas
Well, these forums, while I'm sure they are read, don't seem to have many developers in them so I'll add my mostly useless 2 cents as I'm not going to bother defending or validating my claims. However, any seasoned developer will recognize another one so meh.
As a very seasoned developer (led many teams all the way up to directly reporting to the CTO) myself including working for some of the largest privately owned companies in the world, it's no mystery the problem they're having. Bad release decisions aside, the bugs and performance issues are a telltale sign of the problem.
Keep in mind, I don't work for CDPR, never have, but wish I could. This is not inside information, I have not read any of their source code because frankly I don't even need to. The tools I have on hand can see many wasted CPU cycles and needless memory allocations alone. And they already know this.
First TLDR- more developers is NOT a good thing, which I don't think CDPR was seasoned enough or prepared for.
I can't speak to company structure, but assuming a competent CTO, the most senior devs are working on the hardest issues. Likely in an Agile (possibly SCRUM) type dev environment. Hopefully, or they're way behind the times.
I presume only senior devs can make changes to RED Engine (which both Witcher 3 and Cyberpunk run on, as opposed to other available engines I won't name).
Doing limited de-compiling the engine seems fairly solid. Albeit they do not have adequate performance developers on staff (which are always top talent and in very low supply and extremely high demand). Also what I do literally for a living. I measure in nanoseconds, not micros, not millis, not frames, nanos and cycles. Why? Well when you work for the world's leading trading firms handling billions in USD in real-time you CAN NOT afford bugs. Or you become Knight Capital (see Wikipedia on how they went bankrupt basically in under an hour).
Simply throwing more junior to mid level developers into the project isn't going to do anything but result in more difficult to maintain code, more bugs introduced (as 1.2 clearly does). And, as we can all see, harder to reproduce bugs. These typically are related to multi-threading, memory leaks, kernel wait handles, you name it. Stuff you REALLY do not want anyone not extremely experienced to even touch.
In fact when I worked for high frequency trading firms we literally never hired anyone that isn't senior. It's really more cost than benefit. They write bugs and bad code. Which ultimately ages poorly and frankly ends up just needing to be rewritten anyways.
I can say, blindly, this is a huge problem as the team grew. Period, full stop. They know this, whether they'll admit it or not. I don't even need to see the code. If they wanted me to sign an NDA and do some free static code analysis and performance/memory profiling I have no doubt I'd spot very obvious "low hanging fruit" performance problems as developers call them. Little effort for the most gains is what performance devs will hit first. All large code changes (or branch merges, however they handle SCM) carry large risks.
That's enough text that CDPR themselves (or the coders that work there) can basically go "yup".
Problem is quite literally technical talent. I'm sure they have amazing top talent guys for sure. But they far too many junior/mid level coders that I'd unfortunately code review their commmits and probably fire immediately if I was running things. Ideally the build environment should have some unit tests, static code analysis, performance profiling. Basically what's now considered DevOps.
Now there's nothing wrong with hiring developers that don't all cost top dollar, despite that being ideal. However any seasoned coder knows even one thousand junior devs can NEVER even replace one top talent developer. Period. They simply don't have the knowledge or experience.
If you're running juniors or mids, each team needs at the very least one or two seniors that should frankly be required to code review any commit before it even hits source control. Without this your codebase is going to snowball into a nightmare that takes far too long to make rapid changes and correct fixes.
QA also has to have direct access to either team leads, PMs, BAs, whatever. There needs to be an immediate feedback loop. Not a commit, then a QA build, then another ticker or issue that the "fix" didn't work. It's a code branching and merging nightmare otherwise.
Most bugs to me don't appear to be serious issues with the engine, which is smart and good. But the scripting, or simple code on top of the engine to enable various things, appears to be coded by almost pure amateurs with little to no supervision while the heavy hitters are busy elsewhere. That's a mistake.
Frankly, in the amount of time the game has been released, I (by my lonesome), could bring meaningful performance stability and memory improvements. Fixing other people's code may as well be my job title at companies that hire en masse like as fast as they grew. It's just not feasible they attracted enough top talent fast enough. Not a chance.
The fix? That's simple but a harsh reality. The weakest developers (ones that consistently write bad or hard to maintain code and bugs) need to be let go. And significant resources invested in attracting some more really heavy experienced coders. ESPECIALLY in the performance space which is so niche (especially on a myriad of hardware) that only dedicated performance developers or their top devs (should have been the only ones allowed to touch RED Engine) are going to make meaningful performance improvements. Which EVERYONE wants.
All these other fixes and long changelogs? Meaningless. So they fixed some scripting bugs. That's really about it. Or, if it's not scripts, sandboxed code (basically interface implementations/inheritence from classes that are quite easy to fully implement for lower level devs).
In short, their best devs (which again, I'm sure are awesome) just are stretched far too thin. And no amount of bodies in chairs writing code for their fifth year have any chance in heck doing anything good. The change logs frankly look to me like small commit comments (not a lot of code) translated into easier less technical descriptions.
Longer changelogs, as any dev knows, means virtually nothing. I could patch this code with simply "improved performance" as the only note with substantial code changes. Or make many tiny commits resulting in tons of "fixes" that clearly don't always fix things, and introduce new bugs at the same time. Which is practically the trademark of non-senior level coders.
My advice to them is quite simply more developers is NOT a good thing. Harder communication, management, DevOps, triage, deployment, team structures, branching, merges. And more and more meh or "hack" fixes aren't doing them any good. And everyone on the forum can disagree with me, but any good developer can spot the telltale signs. Want a comparison? The amazing developers that worked on the id Tech engines. Some of the most solid game engines around.
Just..... invest real time and effort attracting TOP talent. Coding talent. They clearly have amazing artists, writers, voice actors, but it's all for naught if the code is meh. The positive note? It's not a hard sea change presuming the underlying engine is rock solid. And it appears that's the case with Witcher 3, which really just ran on an earlier verison of RED Engine.
Best of luck guys. Just stop throwing bodies at the wall. And understand top talent is fought over by every company. You need to attract them. Because competition here (in the USA) is hugely fierce for the best coders.
If they haven't realized all of the above already, I really think the company grew too big too fast, and I really don't care how many mid level devs you throw at the problem. You won't match the competition because nothing tops experience and pure skillset.
Love your work, hope you guys buff up your recruiting and learned your lesson the hard way. I'd prefer a tiny team of great devs over a massive team of good devs any day of the week.
Cheers from USA.
As a very seasoned developer (led many teams all the way up to directly reporting to the CTO) myself including working for some of the largest privately owned companies in the world, it's no mystery the problem they're having. Bad release decisions aside, the bugs and performance issues are a telltale sign of the problem.
Keep in mind, I don't work for CDPR, never have, but wish I could. This is not inside information, I have not read any of their source code because frankly I don't even need to. The tools I have on hand can see many wasted CPU cycles and needless memory allocations alone. And they already know this.
First TLDR- more developers is NOT a good thing, which I don't think CDPR was seasoned enough or prepared for.
I can't speak to company structure, but assuming a competent CTO, the most senior devs are working on the hardest issues. Likely in an Agile (possibly SCRUM) type dev environment. Hopefully, or they're way behind the times.
I presume only senior devs can make changes to RED Engine (which both Witcher 3 and Cyberpunk run on, as opposed to other available engines I won't name).
Doing limited de-compiling the engine seems fairly solid. Albeit they do not have adequate performance developers on staff (which are always top talent and in very low supply and extremely high demand). Also what I do literally for a living. I measure in nanoseconds, not micros, not millis, not frames, nanos and cycles. Why? Well when you work for the world's leading trading firms handling billions in USD in real-time you CAN NOT afford bugs. Or you become Knight Capital (see Wikipedia on how they went bankrupt basically in under an hour).
Simply throwing more junior to mid level developers into the project isn't going to do anything but result in more difficult to maintain code, more bugs introduced (as 1.2 clearly does). And, as we can all see, harder to reproduce bugs. These typically are related to multi-threading, memory leaks, kernel wait handles, you name it. Stuff you REALLY do not want anyone not extremely experienced to even touch.
In fact when I worked for high frequency trading firms we literally never hired anyone that isn't senior. It's really more cost than benefit. They write bugs and bad code. Which ultimately ages poorly and frankly ends up just needing to be rewritten anyways.
I can say, blindly, this is a huge problem as the team grew. Period, full stop. They know this, whether they'll admit it or not. I don't even need to see the code. If they wanted me to sign an NDA and do some free static code analysis and performance/memory profiling I have no doubt I'd spot very obvious "low hanging fruit" performance problems as developers call them. Little effort for the most gains is what performance devs will hit first. All large code changes (or branch merges, however they handle SCM) carry large risks.
That's enough text that CDPR themselves (or the coders that work there) can basically go "yup".
Problem is quite literally technical talent. I'm sure they have amazing top talent guys for sure. But they far too many junior/mid level coders that I'd unfortunately code review their commmits and probably fire immediately if I was running things. Ideally the build environment should have some unit tests, static code analysis, performance profiling. Basically what's now considered DevOps.
Now there's nothing wrong with hiring developers that don't all cost top dollar, despite that being ideal. However any seasoned coder knows even one thousand junior devs can NEVER even replace one top talent developer. Period. They simply don't have the knowledge or experience.
If you're running juniors or mids, each team needs at the very least one or two seniors that should frankly be required to code review any commit before it even hits source control. Without this your codebase is going to snowball into a nightmare that takes far too long to make rapid changes and correct fixes.
QA also has to have direct access to either team leads, PMs, BAs, whatever. There needs to be an immediate feedback loop. Not a commit, then a QA build, then another ticker or issue that the "fix" didn't work. It's a code branching and merging nightmare otherwise.
Most bugs to me don't appear to be serious issues with the engine, which is smart and good. But the scripting, or simple code on top of the engine to enable various things, appears to be coded by almost pure amateurs with little to no supervision while the heavy hitters are busy elsewhere. That's a mistake.
Frankly, in the amount of time the game has been released, I (by my lonesome), could bring meaningful performance stability and memory improvements. Fixing other people's code may as well be my job title at companies that hire en masse like as fast as they grew. It's just not feasible they attracted enough top talent fast enough. Not a chance.
The fix? That's simple but a harsh reality. The weakest developers (ones that consistently write bad or hard to maintain code and bugs) need to be let go. And significant resources invested in attracting some more really heavy experienced coders. ESPECIALLY in the performance space which is so niche (especially on a myriad of hardware) that only dedicated performance developers or their top devs (should have been the only ones allowed to touch RED Engine) are going to make meaningful performance improvements. Which EVERYONE wants.
All these other fixes and long changelogs? Meaningless. So they fixed some scripting bugs. That's really about it. Or, if it's not scripts, sandboxed code (basically interface implementations/inheritence from classes that are quite easy to fully implement for lower level devs).
In short, their best devs (which again, I'm sure are awesome) just are stretched far too thin. And no amount of bodies in chairs writing code for their fifth year have any chance in heck doing anything good. The change logs frankly look to me like small commit comments (not a lot of code) translated into easier less technical descriptions.
Longer changelogs, as any dev knows, means virtually nothing. I could patch this code with simply "improved performance" as the only note with substantial code changes. Or make many tiny commits resulting in tons of "fixes" that clearly don't always fix things, and introduce new bugs at the same time. Which is practically the trademark of non-senior level coders.
My advice to them is quite simply more developers is NOT a good thing. Harder communication, management, DevOps, triage, deployment, team structures, branching, merges. And more and more meh or "hack" fixes aren't doing them any good. And everyone on the forum can disagree with me, but any good developer can spot the telltale signs. Want a comparison? The amazing developers that worked on the id Tech engines. Some of the most solid game engines around.
Just..... invest real time and effort attracting TOP talent. Coding talent. They clearly have amazing artists, writers, voice actors, but it's all for naught if the code is meh. The positive note? It's not a hard sea change presuming the underlying engine is rock solid. And it appears that's the case with Witcher 3, which really just ran on an earlier verison of RED Engine.
Best of luck guys. Just stop throwing bodies at the wall. And understand top talent is fought over by every company. You need to attract them. Because competition here (in the USA) is hugely fierce for the best coders.
If they haven't realized all of the above already, I really think the company grew too big too fast, and I really don't care how many mid level devs you throw at the problem. You won't match the competition because nothing tops experience and pure skillset.
Love your work, hope you guys buff up your recruiting and learned your lesson the hard way. I'd prefer a tiny team of great devs over a massive team of good devs any day of the week.
Cheers from USA.
Hired!
Post automatically merged:
Also it says careers down below here bottom of the page, not forum page but main page sorry.
Even if it is very interesting what you explain to us, and that I could not contradict you because I know nothing about it
Personaly, I have retained one thing in particular. In french : "It's not modesty that suffocates you"
Last edited:
When contrasted with what we can see from the game and CDPR, it definitely sounds on the money.
The "scripting" sounds to me like the issues I'm having with my favourite topic here: crowds and traffic.
Lately I noticed that cars on the streets behave in a very weird ways when I walk towards them. How to explain it... So what happens is, if I approach head on a car that is in motion, it will stop. And it will not move until I walk away to a certain distance. Ok? Now here's an interesting thing: if there was another car behind the first one and that one also had to stop, it will not move until I walk past it. Even after the first car is all long gone, the second car will wait. No matter how far away I walk from it, it won't move until I am BEHIND it.
The "scripting" sounds to me like the issues I'm having with my favourite topic here: crowds and traffic.
Lately I noticed that cars on the streets behave in a very weird ways when I walk towards them. How to explain it... So what happens is, if I approach head on a car that is in motion, it will stop. And it will not move until I walk away to a certain distance. Ok? Now here's an interesting thing: if there was another car behind the first one and that one also had to stop, it will not move until I walk past it. Even after the first car is all long gone, the second car will wait. No matter how far away I walk from it, it won't move until I am BEHIND it.
Incredible and grateful for the time that you have dedicated to giving knowledge to the people that in this forum we try to support and encourage in the evolution of Cyberpunk 2077. You are incredible people developing incredible experiences. I hope it is not the last time you write in the forum, I was delighted to read you. Your skills and knowledge give great value to your comment and undoubtedly give quality to this forum. Please don't hesitate to share more thoughts with us.
And I hope some of the CDPR people who enter the forum read it.
Post automatically merged:
tests on steam keep coming:
Last edited:
When it comes to the issue with crashes, there are not as many now so thats good. I can isolate 80% of my crashes to one specific event in the game, after i have forex finished one of thoose NCPD assault quests and at the end i "jack in" to an antenna to get some eddies and quickhacks and what not, thats when the most of the crashes happens, i monitor the pc:s performance when i play, cpu usage, temperatures and so on and i can see that when you "jack in" the cpu usage get really high, it could of course be my computor, i dont have the latest hardware its like 3-4 years old but i dont think thats it. Just a thought maybe its helpful.
Even if it is very interesting what you explain to us, and that I could not contradict you because I know nothing about it
Personaly, I have retained one thing in particular. In french : "It's not modesty that suffocates you"
don't worry no one who can will have any interest in doing so
#PC #bug #Sweetdreams
AMD FX8350 Black Edition 4GHz / 24 GB (16 GB) RAM DDR3 / Radeon RX 580 8GB (+8GB) / SSD NVME 500GB
Bug in the Sweet dreams mission. I get my equipment back, I go out to face Stefan. Once in the elevator, he told me to collect my equipment (basic optional rated mission). There are some impossible eddies to take as well. Since 1.21, the game also lags very strongly!
Bug dans la mission Sweet dreams. Je récupère mon matériel, je sors pour affronter Stefan. Une fois dans l'ascenseur, il me dit de récupérer mon matériel (mission notée facultative de base). Il y a des eddies impossible à prendre également. Depuis le 1.21, le jeu lague très fort également!
AMD FX8350 Black Edition 4GHz / 24 GB (16 GB) RAM DDR3 / Radeon RX 580 8GB (+8GB) / SSD NVME 500GB
Bug in the Sweet dreams mission. I get my equipment back, I go out to face Stefan. Once in the elevator, he told me to collect my equipment (basic optional rated mission). There are some impossible eddies to take as well. Since 1.21, the game also lags very strongly!
Bug dans la mission Sweet dreams. Je récupère mon matériel, je sors pour affronter Stefan. Une fois dans l'ascenseur, il me dit de récupérer mon matériel (mission notée facultative de base). Il y a des eddies impossible à prendre également. Depuis le 1.21, le jeu lague très fort également!
Attachments
-
IMG_20210421_141712.png -
IMG_20210421_141716.png -
IMG_20210421_141755.png -
IMG_20210421_141759.png
I don't work in gamedev specifically but the approach is pretty much the same for every software development company. They specify work for x days, for instance 14 days. They specify priorities of tasks including everything like bugs, features, changes, optimization etc. Devs are experienced enough to estimate how many tasks they can cover within given time (more or less). It doesn't always work 100% because it's very difficult to estimate every task accurately, coding is very complex job that has so many variables and unpredictable outcomes that you can just make the best you can and hope it's good enough. That's why usually you call for more time than your estimation resulted in, just for that "unpredictable" part. If you deliver faster then great, another backlog items are waiting for you. Obviously they are big enough company that they have plenty teams, some might only work on bugs, some might only work on optimization etc. That's good if you have the resources. Good management can definitely take care of that. Proper people on proper positions, even if you have 2 developers that on paper are the same, they can be good at two different parts of code. They release patches on time and if not everything is done that was supposed to be done, they just push it to another sprint (mentioned 14 days, for instance) and estimate/re-estimate the time and priority again. Obviously those tasks are usually on lower priority and they come in last. The approach is to always deliver working code and solve critical bugs first (those that make an application stop working in certain scenarios, for games it's for instance a mission you get stuck in and can't complete and go further or the crashes which makes an application to fail completely). They can't get stuck because something makes the game unplayable because it's still in the works. Every developer earns quite well and if he's not working atm. he still gets paid for doing nothing so management and preparation for sprints is very important to cover everyone with tasks all the time. And it's better to deliver 90% than 0% and wait for the 10% to be finished. You might as well push the 10% to another sprint. Sometimes you get to the point when 100% is delivered, sometimes not. That really can't be fixed at 100% delivery always, coding is too complex, the size of project like Cyberpunk also makes it harder. The coding good practice is to always deliver small but working updates. So that you can, for instance, launch your application every day and never leave it temporarily not working, that's called continuous delivery (sprints are a part of it), meaning you can release your application any time you want. Moreover, it's pretty bad assumption that it took them 14 days to release 1.21. You don't know when they started working on the tasks included in this patch. It might have been a part of 1.2 patch that failed to deliver, it might have been larger tasks that were pushed out of 1.2 scope and put into "deliver when ready" queue because of complexity and maybe lots of testing required etc. Not to mention software development has something called version control system (usually it's GIT) which makes you able to work on an application, which main code is stored on master branch (let's say it's the code that people get with updates), while you can work on "your" version of application on "your" branch, for instance hotfix 1.21 branch which is still the game and can be played normally and when ready it gets merged to master branch when fully tested manually, automatically, reviewed and accepted by a leader or whoever does it. That allows devs to work on 1.2, 1.21, 1.3 or whatever version of patch simultaneously without any collisions which can happen but always in reference to the master branch and then you need to resolve them before being able to push your changes in game to the master branch. People have no clue how challenging it is to develop a game for completely new platforms (new gen consoles) for a first time and also for existing platform like pc and also go for such massive game. CDPR only fault was to listen to people whining about postponed releases, it wasn't possible to release a fully finished game in those circumstances, they should have waited 2-3 months and release decent enough initial version and start from there.
I dont know if this is the correct forum to take this up in but i guess someone will point me in the right direction if it isnt But there are aproblems with certain clothing mods, forex the "resist" mod does not work... i have 2 of them on the current clothes, they are 11% each, (Damage over time reduction" but on the stat page the value is 0. I also put on a "bully" mod (30% crit damage) and the crit damage stat did not change. There are more of that as well. Next: If someone could write an explanation of what the cybermods do, that would be great, because as it is now you look on the ripperdocs "trade" page and it says medium battery! ok, battery for what? and so on and on. (English is not my native language, so i´m sry for the spelling)
But there are aproblems with certain clothing mods, forex the "resist" mod does not work... i have 2 of them on the current clothes, they are 11% each, (Damage over time reduction" but on the stat page the value is 0. I also put on a "bully" mod (30% crit damage) and the crit damage stat did not change. There are more of that as well. Next: If someone could write an explanation of what the cybermods do, that would be great, because as it is now you look on the ripperdocs "trade" page and it says medium battery! ok, battery for what? and so on and on. (English is not my native language, so i´m sry for the spelling)
Breathtaking.
Hotfix 1.21 for Cyberpunk 2077 is live on PC, consoles and Stadia.
In this update we focused on further improving the overall stability of the game and fixing the most common issues that could block progression. Here's what changed:
Quests & Open World
Gameplay
- Fixed an issue in Gig: Getting Warmer... where the player was unable to lower 8ug8ear's body temperature.
- Fixed an issue where being unable to pick up the "Send a crew" shard in Cyberpsycho Sighting: Discount Doc could block progression. Reading the shard is now an optional objective.
- Fixed an issue in Down on the Street where Takemura would get stuck in Japantown Docks after player chose to go to Wakako alone and left the area too early.
- Fixed an issue where the clues in Cyberpsycho Sighting: Bloody Ritual would not count if the player scanned them before talking to the wounded NPC.
- Spray Paint should now trigger properly when player approaches Brendan.
- Fixed an issue in Play it Safe where upon connecting to the Access Point the screen could become black, blocking further progression.
- Fixed an issue where Reported Crime: Dredged Up would not complete if the player opened the container before scanning the blood trail.
- Fixed an issue where a Maelstromer could spawn in an area unreachable for the player, blocking progress in Losing My Religion/Sacrum Profanum.
- Fixed an issue blocking progression in one of the Assaults in Progress in Japantown.
- Addressed an issue where the game could crash during Gig: Hippocratic Oath if the player jumped through the window after breaking it.
- Fixed various issues with enemies clipping through objects and floating in the air in Suspected Organized Crime Activity: Privacy Policy Violation.
- Fixed an issue in Suspected Organized Crime Activity: Privacy Policy Violation, where progression could be blocked due to enemies being stuck in a hangar.
- Holocalls from Mitch should no longer get stuck and repeat if the call was interrupted before.
- Fixed Johnny's appearance in various quests.
- Dennis' car should now spawn correctly in Big in Japan.
- Players can now enter Dennis' car from the right side in Big in Japan.
- Windows inside the shack should no longer break upon opening the container in Big in Japan.
- Big in Japan will now fail if the player leaves Haruyoshi instead of carrying him to safety after opening the container.
- Fixed an issue where player could become unable to use weapons and consumables after getting out of Takemura's van in Down on the Street.
- Player can no longer call Takemura during the meeting with Oda in Down on the Street.
- Fixed an issue where Oda could be found on the bridge between Watson and Westbrook before going to Takemura's hideout in Search and Destroy.
- Fixed an issue in Down on the Street where Oda could crash into player's car if it was parked in his way.
- Fixed an issue where Burning Desire/Night Moves could get stuck on the "Wait for a call from distressed man" objective after player failed the quest.
- Fixed an issue where the door to Cassius Ryder's ripperdoc shop would not open, preventing the player from completing The Gig.
- Saul will no longer follow the player around the world if they leave the quest area after freeing him in Riders on the Storm.
- Fixed an issue where sandstorm could be present in the city if the player fast travelled there during Killing in the Name or Riders on the Storm.
- Riders on the Storm will now fail if the player leaves the Wraith camp before rescuing Saul.
- Gig: Severance Package should now trigger properly after approaching the quest area.
Visual
- Fixed an issue where, after the player commits a crime on the roof of a building, NCPD officers would spawn behind the player's back.
- Fixed an issue preventing the player from climbing ladders out of water.
UI
- Fixed various issues related to clipping in NPCs' clothes.
Stability and performance
- Added back the icon above NPCs, who are under the Distract Enemies quickhack effect.
- Scanning UI is now less cluttered.
- Fixed an issue where Japanese/Traditional Chinese text could disappear if the player changed the interface language from English to one of these languages.
Console-specific
- Various memory management improvements (reducing the number of crashes).
Stadia-specific
- Players should now be able to select stickers in Photo Mode using the Circle button in the Japanese version of the game on PlayStation 4.
- Fixed some graphical issues on a bridge in Mikoshi in Belly Of The Beast/Changes.
This is the key difference. Gaming development is infinitely more forgiving than trading software development. A lot of players either ignore bugs or find them funny as long as the game doesn't crash too often, just look at bethesda and ea products. But good luck finding people who will be amused by bugs in their banking or trading software.
Even in its current sad state, the game development more than paid off in terms of sales. And it will have even more sales once they return it to PS store.
Meaning CDPR bosses don't even have to learn anything from all this story.
[...]
Last edited by a moderator: