I understand the complaint, but please tone down the attitude. You're aggressively arguing from the position of someone unfamiliar with the code base and trivializing things that aren't trivial. If it were as simple as MAINTAIN_BUFFS_BUT_REMOVE_VFX_ON_THE_GUY = TRUE, we would have done it. We're working with a code base that's approaching its tenth anniversary and has accumulated an enormous amount of content over NWN, SoU, HotU, NWN2, MotB, and now SoZ. Virtually anything could be accomplished or changed in a game given enough time, but it's not always a wise use of time. And often, the limitations of ancient engineering decisions are not immediately apparent when a new system (like the overland map) is being designed.
I know it's comfortable to assume that every feature is simple to implement and every bug is easy to fix, but that doesn't match the reality of the situation. NWN and NWN2 are driven by logic, data, and script. Visual effects can come from a wide variety of sources within those categories, and those effects often do not carry data with them that allows for easy sorting/categorization. That can make it difficult to suppress the visual effects you don't want but retain the visual effects you do want.
Here's an analogous NWN2 situation: when I came onto NWN2, I learned that stacking rules were not properly implemented in the engine. Some things were handled code-side, some were handled haphazardly in script, and most "by-the-book" stacking rules were totally ignored. That's why in NWN, SoU, and HotU, you could stack tons of ability score-modifying items together to get super high stats. There were so many items, game effects and script functions that used the various bonus effects that it would have been incredibly laborious to retrofit everything to follow the proper rules. We talked to WotC about it and they said they would rather have nothing stack than everything stack, and that was the most accurate D&D solution we could implement given the resources available. As a hack, Andy Woo put in an exception for Barbarian Rage, but it was the hackiest hack that every hacked.
D&D is really big. The Aurora code base is really big. The accumulated content of the games is huge. We do genuinely screw up here at Obsidian, but we're not a gang of drooling, lazy buffoons.
EDIT: As an addendum, this was something that several programmers have looked at, and there did not seem to be a "magic bullet" that did everything people would want/nothing they did not want. It's possible that could change in the future, but it comes down to available time for analysis and implementation.
I think people (fans and devs) need to take a moment to think about the effect of iterative effect of several prolonged period of crunching on a codebase. I would assume that obviously this is something that Obsidian are always working towards, in regards to damage mitigation.
See how many times does a programmer need to implement the "hackiest hack that every hacked", before general software entropy takes over causing numerious man hours to be spent fixing hacks.
From what I can see is that some "bad" design most likely took place at some point before Obsidian even got close to the code for NWN2, and 3 crunch periods, with some optimisation having likely taken place, at which point you're inheriting something which in places is extremely difficult to read. I find it unlikely that there would be regular one to one in person contact with Bioware even once a week, at best it was perhaps once a month.
I don't think Obsidian have screwed up so much as made the best of a pile of crap, and I've certainly felt that way about the Aurora experience for a long time. An engine that's trying to do waaaay too much developed initially at the time atleast by an unexperienced team, they'd shipped BG sure, but 3D and 2D engines ain't the same beast at all.
They even went so far as to write their own script parser, it's those sorts of decisions which were made that have an overall impact on the end result. I don't know if they even changed the parser or if they continued to work with it but they most certainly experienced alot of issues, writing a scripting parser isn't a small feat, doing it within the constraints of a games development cycle take dedicated experienced individuals. I don't doubt the guys at Bioware aren't dedicated and experienced, but all the same, few engines have implemented custom scripting languages... Unreal Script always springs to mind, but surely another solution such as lua or python is more desirable...
So in short, I don't blame you guys... You've done a sterling job in whipping up the old badger engine into something semi-efficiant.
