Yeah, that's a good point. At most it would have been a warning line in some UE log that no one might have been checking to begin with. Whatever was parsing the .ini file probably wasn't even written in-house at all but some default UE module.An "advantage" of UE is that is pretty robust to missing files and scripts. You can disable movies in every UE game only deleting the files. A missing texture will be grey, etc
Maybe a warning was in some place, but nothing critical for them to put more effort into. Sadly.
There is no reason that enemy behaviour like that should be relegated to an initialization file in the first place and not in the code itself. If it had been in the game's code, it would have been caught before release because it would have thrown a compiler error about an undefined variable.That's amazing! And entirely feasible to have happened. Gearbox likely pulled devs from the game, so nobody really *could* check for nonsense like that.
So it remained. Who'd find out? Only someone going VERY carefully over every line. Gearbox didn't have anyone like that on the game anymore, it seems.
I drives me crazy when programming in RThis is why I hated coding in college, I constantly had stupid tiny little errors in my code and I was terrible at finding the mistakes.
That's why you turn on all compiler errors and warnings are treat warnings as errors, right from the start.This is why I hated coding in college, I constantly had stupid tiny little errors in my code and I was terrible at finding the mistakes.
I did, but at least 11 years ago when I was learning Java it didn't help all that much. Helped find errors that completely broke things, but not a lot of the little things (that add up quick and ruin your grade).That's why you turn on all compiler errors and warnings are treat warnings as errors, right from the start.
Dunning–Kruger in full effect here.The reactions in threads like this are a pretty good barometer for how much the average poster thinks they know about game development, versus how much they actually know.
Sorry ERA, but you all got a D-. You're going to have to retake Introduction to QA 101
I appreciate this post. Bravo.
Good point. That's probably what happened now that you mention it.You're assuming the people who did the AI were even still there at the end. Don't forget all the shadiness that went into this game's development. Sega thought Gearbox were making it and meanwhile Gearbox were farming it out left right and centre. It could be that TimeGate did the bulk of the AI and then Gearbox finished it without properly understanding the code and that it was supposed to work better.
https://www.cinemablend.com/games/Watch-Dogs-E3-2012-Graphics-Can-Unlocked-PC-Here-How-64710.htmlWasn't there a similar ini file fix for Watch Dogs 1 on PC that let the game look more similar to the initial E3 demo? I remember playing it and noticing it looking a lot more pleasing than the unmodded game
this sound like funI 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.
There is no reason that enemy behaviour like that should be relegated to an initialization file in the first place and not in the code itself. If it had been in the game's code, it would have been caught before release because it would have thrown a compiler error about an undefined variable.
Now wonder with us all at how awfully they've mismanaged the series, its related stories, characters, and universe.Watching Aliens now, can't believed a game based on it went so wrong.
Huh? Just go to the file mentioned and edit the word Teather to Tether yourself, it's all right in the OP. If on PC of course.
Just open up the INI configuration file in your installation folder/directory, CTRL+F for "Teather", and remove the "a" before saving the INI configuration file.
So did anyone play through it with the fix, is the game half decent now?
Ohhh if it's on a console, you're out of luck I think.
Here's the AI in action. Fixed by removing the offending letter.
how did the motherfuckers who made this shit, and made the AI, and expected it to run a certain way
how did they just not...follow up and look and say "something isn't right"