Wha... Did you not read the OP?
Like, Jesus, do you expect people to personally dictate the forum to you?
-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
Aliens: Colonial Marines AI fixed by a single letter
- Thread starter JigglesBunny
- Start date
Wha... Did you not read the OP?
Like, Jesus, do you expect people to personally dictate the forum to you?
intellisense ftw
funny this happened in a modern IDE environment, but it sounds like bad naming convention.
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
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.
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?!?
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.
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.
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.
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.
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.
Last edited:
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.
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.
Last edited:
I feel like this would be pretty noticeable when the program throws an error trying to reference a configuration entry that doesn't exist
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.
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.
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.
This is almost as incompetent as when Bethesda released the debug version of Skyrim instead of an optimized release version and didn't realize it until modders fixed it for them.
https://www.kotaku.com.au/2011/12/m...ormance-by-up-to-40-per-cent-could-be-faster/
https://www.kotaku.com.au/2011/12/m...ormance-by-up-to-40-per-cent-could-be-faster/
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.
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.
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.
Civilization 6 also released with a typo in the ini that fucked the AI all up.
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.
Someone check Nier Automata ini for spelling errors. I want it, but I hear performance isn't as good as it could be.
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.
This is one of the most unbelievable things I've ever heard of in game development. Absolutely mind-boggling.
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.
The real travesty is that it was made to shipped like that, not that the error happened or didn't get resolved.
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.
Layman question here, but if it is on the ini file, isn't, at the same time, somewhere in the code?
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.
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.
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.
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.
Also, because .inis tend to be local to your machine, it's possible and likely that developers did not have the bug locally.
OP
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.
Spoiler: They also noticed the improvement.
Last edited:
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/
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.