I see. And these config files are usually done with barebones text editors? Boggles the mind that they wouldn't use tools capable of detecting these things to me if such grave errors can result from it.It's not a line of code, it was a misspelled property in a conf file that the game engine uses. These conf files are normally plain text consisting of key/value pairs, the engine will look for keys and change behavior according to the value associated with the key. If either the key or value is not recognized by the engine, it will most likely ignore it and assume default behavior for that particular entry.
Goes to show you why external configuration files can be bad news.
To you.
But don't they alert the developers and inquire if there might be something seriously wrong with the AI?
This isn't code. Game code would be much harder to edit. This is just a plain-text .ini configuration file. I'm gonna assume someone stressed out and tired mistyped the value in the configuration file and the game didn't properly validate the input. Validation and proper error handling are often the things that you sort of brush over when you're trying to get a project out of the door quickly. This sort of error can happen very easily. This particular bug isn't a sign of incompetence or lack of professionalism on the dev's part, it's most likely stress and lack of testing.So just one line of code screwed the entire IA? what? there arent like more conditions to make the IA work?
Wow. The aliens gaming franchise could have potentially gone in an entirely different direction and have an entirely different history...all over a single letter being where it wasn't supposed to be.
Yeah speaking as someone who made some relatively complicated mods for XCOM 2, it's really easy to get yourself in the sense of that if there's a fuckup, it has to be in some of the major things you just changed, and maybe if you just take a second or third or fortieth look through it, maybe you'll finally find it.I'm really not surprised. I spent almost 6 weeks trying to fix some broken deep learning code because the algorithm kept derping out, and it was only when I was eating cornflakes one morning I noticed a single typo that fucked the entire thing. It's easily missed when you have been staring at it for weeks.
this hurt sega way more than it hurt gearbox
This isn't a issue of competency. Gearbox even came in for quality reasons. Sega gave them a set date and it wasn't sufficient time.It doesn't take a genius to figure out that there was something seriously wrong with their AI.
Well gearbox didn't actually develop the game they outsourced it to another company, a friend of mine was running of working there during that project.Five years since the game has been released so about that same time.
I'm more amused by Gearbox Software themselves never picking up on this.
I would think so too, but I would genuinely like to hear from someone with QA experience in video games. My thinking is that they would have reported broken AI in testing the product and it was up to someone resolving issues to look for the cause. I have never heard of QA going through INI files though. Maybe I'm wrong.
Yes, that's definitely a factor too. Usually as a programmer, you have sort of a bias to look at the complicated parts first because those are usually the most error-prone. A mistyped constant, as often as it happens, is often the last place you'll look.Yeah speaking as someone who made some relatively complicated mods for XCOM 2, it's really easy to get yourself in the sense of that if there's a fuckup, it has to be in some of the major things you just changed, and maybe if you just take a second or third or fortieth look through it, maybe you'll finally find it.
Meanwhile the true culprit of one simple typo in a place you considered simple and shouldn't be relevant is silently laughing all the way.
I saw another post about another typo from geoffegg so thought copy paste it here. I believe we are all still missing this second INI fix that needed still.
This typo is in the DefaultEngine.ini, in your Steam\steamapps\common\Aliens Colonial Marines\PecanGame\Config\ directory
Turns out the biggest bug in the game isn't just one letter long Templar, it's one letter wrong too.
I've found out ClassRemapping=PecanGame.PecanSeqAct_AttachXenoToTether also has a typo on the exact same line as the AttachPawnToTeather typo. It says ClassRemapping=PecanGAme with a capital A in Game which could potentially be causing a problem as well. (lower the A to "a" yes)
This exists in the DefaultEngine ini file, which is what serves as a default for the PecanEngine config in My Documents.
Just been testing it out quickly with both typo corrections in the Vanilla ACM and it looks to me like the Xeno Soldier's are definitely wall and ceiling climbing more, only tested No Hope in Hadley's so far.
This typo is in the DefaultEngine.ini, in your Steam\steamapps\common\Aliens Colonial Marines\PecanGame\Config\ directory
https://www.fanatical.com/en/game/aliens-colonial-marines-collectionI was honestly considering getting the game on Steam right now but......
As funny as it is, I doubt the game's perception would've changed if the alien AI was a little better.
But don't they alert the developers and inquire if there might be something seriously wrong with the AI?
All QA does is report technical issues with the game the notice in playtesting, they can't fix them. The devs knew the AI was broken but probably couldn't find the reason.I would think so too, but I would genuinely like to hear from someone with QA experience in video games. My thinking is that they would have reported broken AI in testing the product and it was up to someone resolving issues to look for the cause. I have never heard of QA going through INI files though. Maybe I'm wrong.
I'm not sure exactly what you mean, but the entries in the INI file don't need to correspond to files. They're just text that the game reads and stores in some sort of key-value data structure. If I had to guess, I'd say that there's a part of the code that decides for each enemy type the type of AI behavior it should use, depending on what it says in the configuration file. If there's no value or an unrecognized value, it'd probably fall-back to the default behavior (which is what happened here).so wait
The "teather" file does actually exist though? It's just nothing? Did they like, catch that a non-existent file was being called, make a blank one with that name, and call it a day or something?
I guess the alternative is that someone caught that the file was misspelled, made a new copy with the same name, and then forgot to actually change the references?