1. RounD


    I'd say more mildly interesting.
  2. ShinySunny


    So we should buy the game for $3.50?
  3. Akronis


    They probably surrounded the entire game in one try catch block.

    lol I'm guessing someone fucked up the serialization of the config and they must not have a great method of debugging because this should've been spotted immediately
  4. tbyte64


    I’m not sure you understand how many thousands of warnings you get in a project this size, 99% of which you can safely ignore.
  5. chrisypoo


    Who fuckin programmed this shit? Who needs to be fired? And how did the community figure this shit out before a well budgeted development studio with five years to pour over the code looking for issues? What in the jolly Jiminy fuckin hell is goin on over there?!?
  6. Zips


    Holy. Crap.

    I mean, that doesn't completely fix that mess of a game, but that's HUGE!
  7. Poison Jam

    Poison Jam

    You can't make this shit up
  8. kiguel182


    Man, sucks that they missed this if this is true. Stuff slips by sometimes, even in really small projects. Man, that sucks. But it’s cool that somebody found it and fixed it.
  9. tbyte64


    Jesus Christ people, what the fuck already
  10. jstevenson

    Developer at Insomniac Games Verafied

    this is why I'm not a coder
  11. The guy that wrote the .ini file is probably the guy that had to find his own error. He thought the word was spelled correctly the whole time so he didn't do shit about it.
  12. Alienous



    Lazey devs.
  13. Vimes


    I've worked QA, it's their job to identify problems, not discover the cause.

    But feel free to "WELL ACTUALLY" at people who know development better than you.

    jfc gaming side has been a tire fire this summer. If you all want to understand why Price lost patience and blew that dude on twitter up you can see it illustrated perfectly right here.
  14. pksu


    It would be easy to just blame someone for the typo but so many things must have gone wrong first for this to actually ship. Developers must have seen how broken AI was and pretty much no-one wants to ship broken stuff. Usually there are simple practices to avoid these things like actually handling parsed values/raising errors if something crucial is missing, logging things and having some sort of automated test set that can be run after changes and verified to work without errors and so on.

    This wasn't just a programming error but a sign of something else.
  15. Vimes


    This is the kind of mistake that's made during crunch and will never be caught during crunch.
  16. Pikma


    This is a monument to the clusterfuck that was the development of Aliens Colonial Marines.
  17. slamhk


    Who knows who did it, but it's sad that the gameplay had to suffer under such a mistake. I mean, if it has such a impact on gameplay I would think that someone surely must've noticed within the dev team, but as a consumer we have no idea when this mistake was made, and why they couldn't fix it (no time, no money, publisher pressure, deadlines). I mean, the code is there apparently, it just had a spelling mistake.
    I don't know how large the team was behind the game nor did I play it, but you can't point a finger really and say who has to be fired.
    Sucks that it went this way, but it's great to see that the game has a dedicated community behind it.
  18. OsakaDon



    The community that mods and fixes games like this are amazing.
  19. lazygecko


    Stuff like this is what damages the credibility of the industry for me when we are asked to give developers the benefit of the doubt when it comes to allegations of sloppy development. PC games gives consumers an opportunity to look behind the curtains, and instances like these aren't that uncommon. I can understand if fixing these kinds of things can be more of a financial and political hurdle rather than a purely technical one when it comes to allocating resources for patches and navigating the corporate bureaucracy, but I seldom see honesty over even that.

    At the very best, I'd go so far as making an assumption that there were other potentially serious glitches and ramifications from having this particular line enabled, so all they did was rename it to sweep the problem under the rug.
  20. i don't even know what to say, lol
  21. PeskyToaster


    I feel like this would be pretty noticeable when the program throws an error trying to reference a configuration entry that doesn’t exist
  22. DriftedPlanet


    Reminds me of some of the things that I have seen broken in closed game tests or show builds that were massively improved hours or days later. I know that this sometimes occurs with conventions in particular because the latest build at a show is sometimes delivered through the crunch of a "hell week" (as some devs I know call the week before a convention) and they end up fixing it after active show hours (when they have had a moment to breath and stop staring at the code for a week straight).

    Unfortunate that it wasn't caught in a shipped game but I'm glad that modder cared enough about salvaging and overhauling the game to eventually find the typo. Still need to try it sometime.
  23. Gradon


    The game Dev misconceptions thread turned out literally the same way which is pretty laughable with its intent. Like, devs were explaining their approach to game Dev or what gamers misconceive when it comes to game development and it was full of "well actually"'s from people who don't work in the industry.

    It happened a few times with QA specifically too, even in this thread some people have been doing it when you have some actual input from people who know or have done QA chip in.
  24. Alot of you guys are making fun of Gearbox for this mistake but fail to realize this is exactly what causes bugs in most programs. You guys would probably be more shocked to realize another big cause of bugs is being off by 1 because computer science tends to start counting from 0 not 1.
  25. zombiejames


  26. Sblargh


    This is the greatest gaming discovery since cloudbush.
  27. Krejlooc

    Dreamcast Porno Party Member

    I have an engine that I've made myself that wrangles OpenGL for quick project development. A lot of the complexity of OpenGL is defining buffers in the correct order and assigning pointers to them so that you can work with them, as well as attaching attribute points in shader programs. It's something complex to do by hand that actually is time consuming, so I spent a few weeks writing a configuration tool that would generate all my buffers and pointers for me at start up during runtime, not compile time. To speed things up, these buffers and pointers and stuff are loaded useing an external script into an ordered map that assigns them a local string ID temporarily, then later in the start up process, moves those structures in the map to a contiguous piece of allocated memory in an array, and I stop using string IDs and start using an index number based on order in the map (much faster lookup time).

    Well, one day, I was doing some testing and put a print statement midway between loading values into the map and moving them into the array, because I wanted to check some values really quickly. At one point, I was trying to check the value of some OpenGL Uniform, let's call it "VertexOffsetPosition" but I had spelled it "VertxOffsetPosition" when I printed the statement. The nature of trying to look for a key that doesn't exist in a map is that, if you look it up and it's not there, it'll add the key to the list. So now I had both "VertexOffsetPosition" and "VertxOffsetPosition" as keys. By pure happenstance, in debug mode, both uninitialized values looked identical, so I couldn't see the difference between the keys when I printed out the value. Now, later on in my engine, when I called these values from the array, logically everything still should have worked. Since I created VertxOffsetPosition way later than the other values, it should have populated at the end of the map, and thus been given some end of array index, and all my other indexes should have still been correct.

    Except I was using std::map instead of std::unorderedmap. the standard map function automatically hashes the key value based on alphabetical order to speed up lookup. So, when I was creating VertxOffsetPosition later in my code by accidentally checking for it, it was bumping every other Uniform variable down an index in the array. So if I was calling for index[5] or whatever, the value I might have wanted would have actually been at index[6]. This affected everything.

    The end result? No compiler warnings -- I wasn't doing anything illegal. No errors -- the program still compiled fine. No shader errors -- compiling the shaders were still alright. RenderDoc stepping through the frame didn't reveal any errors, because the logic was still sound. Only thing is that instead of getting graphics, I'd get a bright red screen and nothing else.

    This took me an entire weekend of work to find.

    To the people asking why QA didn't find this -- this isn't the type of work QA would find. To people asking why an IDE wouldn't pick this up -- this isn't necessarily an error, and you more than likely wouldn't be writing this shit in an IDE in the first place, and even if you did, it's not like these are keywords to pickout in the first place.

    These bugs happen. It's the nature of programming.
  28. Solid


    that's seriously what I'm thinking
  29. Dr Doom

    Dr Doom

  30. Solid


    By the way, y'all, this isn't even the first game-changing bug of this nature discovered this year.

    Civilization 6 also released with a typo in the ini that fucked the AI all up.
  31. Samus4145


    Is there footage showing the difference?
  32. Ploid 6.0

    Ploid 6.0

    Someone needs to do a documentary on this. Go back, figure out how this happened, how it slipped by, Sega, time crunches, possible resentment and sabotage if drama is there. This would be an interesting story.

    Someone check Nier Automata ini for spelling errors. I want it, but I hear performance isn't as good as it could be.
  33. massoluk


    holy shit
  34. Maya Fey

    Maya Fey

    Holy shit at all the dev bashing in this thread, I thought we avoided that here. Baffling how you can reveal how loose your grasp of development is and at the same time be so sure of yourself in your criticisms. As usual, Kreejlooc is one of the few with an awesome informed opinion a few posts back.
  35. bryanee


    Man I'm looking forward to seeing videos of the AI now.
  36. Brazil

    Trailing in the sky Moderator

    This is one of the most unbelievable things I've ever heard of in game development. Absolutely mind-boggling.
  37. Zero-ELEC


    People asking why QA didn't catch this: QA almost 100% certainly caught the effects, there's probably a super high priority bug in the QA database about AI not working. QA doesn't code. They find bugs, they replicate them, they do compliance, they file them away for the programmers to fix.

    People asking why IDEs/compilers didn't catch this: it's an external .ini file. Shit's not compiled, it's just a plain text file.

    It's just a typo.

    They probably followed up on it thoroughly. They just missed it because it wasn't in the code.

    The real travesty is that it was made to shipped like that, not that the error happened or didn't get resolved.
  38. Sblargh


    Layman question here, but if it is on the ini file, isn't, at the same time, somewhere in the code?
  39. CloudWolf


  40. InsaneTiger


    Has Randy crawled out of his hole to comment on this?
  41. Zero-ELEC


    The correct value is, yes. There's probably dozens of references to "Tether"s in the game code, it apparently being such an integral part of AI behaviour. But when the game is initialised it runs the .ini file to determine certain values for the engine during this session, and suddenly the game itself isn't setting assigning the "pawn" objects to tethers, but to "teathers" and those don't exactly exist.
  42. Krejlooc

    Dreamcast Porno Party Member

    It's a spelling mistake in an external file that goes through no type of error checking. That is super believable. In fact, this is one of the most common types of bugs.
  43. Krejlooc

    Dreamcast Porno Party Member

    Not necessarily. This is a form of dynamic memory management. You can have a system in your code that takes a declaration file, allocates memory based on text in that file, then another file that assigns a string key to the allocated memory in a map. In which case, no, this key is never once referenced in the code. My engine works like that.

    I have no idea if that's what is happening here, but it very well could be. That's the entire point of doing things at run time vs compile time.
  44. carlsojo


    Users and creators: As a ResetEra user, it is important to understand that video games are being created by different developers working with different budgets and technology on different systems for different publishers who try to strike a lucrative balance between business and art. Of course, it is frustrating that a highly anticipated project turns out to be under your expectations, but remember that there are actual people working on these games that have a life outside of video games and are passionate about what they do. Claiming that an entire studio is "lazy" is not only disrespectful but also very naive and uninformed. If we are lucky we get to learn about the stories behind these products, but other than that it helps to understand that this is an industry that is fueled by money, sweat and passion. No matter how disappointed you are, please try to understand people from the industry and don't pin anybody down on one project that didn't go as you wished.
  45. Nome

    Designer Verafied

    Also, because .inis tend to be local to your machine, it's possible and likely that developers did not have the bug locally.
  46. JigglesBunny

    Member OP

    For those who were asking for it, PC Gamer put up an article with comparison videos and a firsthand account of their experience with the fix.

    Spoiler: They also noticed the improvement.
  47. DriftedPlanet


    Amp version of the page is a bit messy on desktop. Normal link for those who want it: https://www.pcgamer.com/all-this-ti...pid-ai-may-have-been-caused-by-a-single-typo/
  48. Brazil

    Trailing in the sky Moderator

    It's understandable that it could happen in the first place, but not that the typo remained there for half a decade before being noticed. I mean, the devs surely must have noticed at some point that the game footage people were capturing of the game's AI was off compared to what they'd put in the game.

    Unless the difference isn't that big, which I guess remains to be seen.
  49. JigglesBunny

    Member OP

  50. Krejlooc

    Dreamcast Porno Party Member

    It's the nature of complex systems. This could be just a single component in a larger complex algorithm. It could be something buried deep within subsystem that don't manifest in obvious ways. It could be that the uninitialized value looks legitimate enough that it's essentially invisible to debugging.

    Also, consider that once something is released, it is basically subject to thousand monkeys at typewriter style debugging. And with all the people undoubtedly looking all around the files, it still took half a decade for it to be found.

    Asking people to go through and spell check ini files is pretty much impossible. Not least of which because sometimes spelling errors are intentional.

    This is all super believable.