If this bug isnt fixed in 1.01 of dg, im gonna pull out my hair!

Easy, everybody has an opinion, nobody knows what he's talking about. Welcome to the internet.

IIRC Microsoft even has a seperate 'secondary' team veriewing all the vital code to filter out any bugs or mistakes that the main devvers could miss, simply for the reasons stated in earlier post. Fresh eyes are essential in projects of this size.

To all the whiners out here, if you have balls do this 'little' test. Everybody knows you make spelling mistakes, grammar errors, etc. Usually you see them (in your forum posts for instance) and correct them. Now let's take it to game designing magnitute. Write a story of 10,000 pages, with spellcheck off (game designers don't have that either, except for syntax and compile checks). Review it for errors and correct. Do that again and correct. Again. And again. Even after 4 times I can [b]assure you[b] that someone else that reads it will find several if not dozens of errors.

Since when has lua something to do with decompiling? This part of the source is available for everyone with a unzipper.

The mod actually only changed 1 function. It is very good he found the bug. And as a player he just looked very carefully when the problem happened. And in this case he had the benefit of a reproducable error. Something that is very difficult to find in an development environment. They were looking at the wrong places. And often fresh eyes see more clearly that has nothing too do with noobs.

Then whose fault is it? GPG wrote the entire damn game, it's definitely their fault. Then released it to the public with the bug still present. Still their fault. Then they failed to fix it within such a long period of time that one of their customers had to show them how to fix it. Still stinks of incompetence.

Additionally this bug falls into the category of "never should have been written that way in the first place". Telling the player's character to turn toward the statically checked (original) location of the enemy instead of the dynamic (moving) location of the enemy is just plain stupid. Did they really think that people wouldn't be moving around in combat?

Well, I'm still waiting on anyone to even *read* my pm's so I'm not hopeful...

Frogboy has stated in IRC that he saw this and forwarded to GPG. Probably as much response as you'll see until they release an official fix.

Just to clarify here a bit: no they didn't state before they were trying to fix it,  the comment made in bman's reply was made three days ago, and try as I might, I can't find anything before that stating that, "hey guys, don't worry we hear you". That's all I'm really upset about. In the reply bman is referencing, they also try to blame the bug on the gamers. The "did you update your video drivers" assuming everyone is an idiot kind of technical support just isn't going to make me happy here. I'm not saying (and didn't say) GPG fails for not fixing or finding the bug, but I am just upset that with all the extra work going into after-the-fact polishing it seems as though the face of the support for this game (I'm refusing to say GPG, because that's not who we get to deal with) is trivializing anything that's not on their priority list right now.

Secondly, to those of you generalizing my comments out of context and then saying that I must not know anything about programming, you probably know less than you imagine I know about it. I have worked on several project that were hundreds of thousands of lines long, programming, debugged, and implementing fixes. My longest standing project I have personally written hundreds of thousands of lines of my own and I can tell you, when it's your code it is a lot easier to debug. But the important issue here is that if any of my players ever came to me with a problem, I didn't blame them and say, "stop overclicking noob". No I tracked down my mistake and fixed it. Now I can tell you that from what bman posted, yes this one of those kind of errors that once you see, you realize that wasn't a very good method to accomplish sight checking.

fyi I did hear back and GPG will include a slightly different implementation of the fix in an upcoming patch so yay!    I don't know if it will be in the next one coming out though...since that one is already at SD's QA.  We'll see I guess.

I guess they all took the long weekend off.

For the record, bman654 is THE MAN. We were down to deconstructing the wrong code trees for this problem, animation was not an intuitive place to look for this. A testament to bman's intuition for sure. This is such a great example of how easily things can be pinpointed once we can reproduce the problem, it isn't even funny.

Hindsight is 20/20, but for those who aren't coders, there are about 14,000 files in our code, and another 8,500 in data and scripts. If something doesn't generate an error or warning (it doesn't), and you can't get it to reliably happen (we couldn't), then you are throwing darts at what you think is the bullseye on a dart board that is very large.

As far as how long before you can play with this fix in the next patch, that is mostly up to Stardock's testing. We are reworking several associated animation scripts right now, and will likely hand this off to Stardock tonight. If it takes a while, it probably won't be because of testing this fix, but several of the matchmaking fixes that have gone in over the last week, and require much more rigorous tests. We will obviously put in a good word for "fast tracking".

- Servo

Great. Can't wait for 1.01, i hope it will be released this week.

I certainly am too. Issue addressed, so I won't say another thing about it.

i've never seen that.  does it happen when very far away or only when near?  Or just all the time?