I gave up on it for now when the questline involving the NPC learning to write broke, and then I started crashing to desktop (without any logs anywhere, either in the Buffout directory or even in Windows’ Event Viewer) every time I left the Swan or fast traveled directly to it, even though traveling to another point literally fifty feet south worked just fine. And since there’s no logs describing the crash, I have no idea how to fix it.
I could probably fix it by uninstalling and re-downloading it again, but I have a goddamn data cap that my roommate already blows through every month with the fucking massive updates Fallout 76 has taken to pushing out, I have zero desire to download 60 GB of data (30 GB base game + 30 GB FOLON) every fucking time I sneeze wrong and make the game start crashing again. =|
When IT folks say devs don’t know about hardware, they’re usually talking about the forest-level overview in my experience. Stuff like how the software being developed integrates into an existing environment and how to optimize code to fit within the bounds of reality–it may be practical to dump a database directly into memory when it’s a 500 MB testing dataset on your local workstation, but it’s insane to do that with a 500+ GB database in production environment. Similarly, a program may run fine when it’s using a NVMe SSD, but lots of environments even today still depend on arrays of traditional electromechanical hard drives because they offer the most capacity per dollar, and aren’t as prone to suddenly tombstoning when it dies like flash media. Suddenly, once the program is in production, it turns out that same program’s making a bunch of random I/O calls that could be optimized into a more sequential request or batched together into a single transaction, and now it runs like dogshit and drags down every other VM, container, or service sharing that array with it. That’s not accounting for the real dumb shit I’ve read about, like “dev hard coded their local IP address and it breaks in production because of NAT” or “program crashes because it doesn’t account for network latency.”
Game dev is unique because you’re explicitly targeting a single known platform (for consoles) or targeting for an extremely wide range of performance specs (for PC), and hitting an acceptable level of performance pre-release is (somewhat) mandatory, so this kind of mindfulness is drilled into devs much more heavily than business software dev is, especially in-house dev. Business development is almost entirely focused on “does it run without failing catastrophically” and almost everything else–performance, security, cleanliness, resource optimization–is given bare lip service at best.