Sound issue with 1.2

It's easy to armchair quarterback this and say (rather harshly) that it's "BAD PROGRAMMING". Since I'm fairly certain you are not privy to BWs development tools, systems, designs, and structure, it would be a bit over the line to just simply declare it BAD PROGRAMMING.

I've worked in the commercial sector on moderately mission critical systems in which we continue to have bug reports trickle in on versions that have been in the field in use for years. Any sufficiently large code base is, quite simply, going to have bugs. And... sometimes... those bugs are extremely hard to track down, much less actually reproduce them.

While I certainly agree that this sound problem drives me insane, frustrates the hell out of me, and seriously has driven me to playing Diablo 3 and back into Middle-earth, I have a fair idea what kind of effort goes into these systems and how easy it is for a bug to slip in, get by all the unit tests, the integration tests and QA. So, let cooler heads prevail here. If you want to /ragequit, vote with your wallet and be done, but let's try to keep it constructive.

The thing that I have trouble understanding is there are *so* many people experiencing this issue I just find it beyond my grasp that it cannot be reproduced in-house. There's a guy here who says every single week they run one of the raid ops and every single week by the time they hit the first boss, the sound is hosed. Not just for him, but for his entire team. That just honestly seems like something which should be reproduceable. A tech followed that up saying he ran the op and didn't have the problem... but I'm going to guess he didn't run it with a full group like us normal folks would. That or it's a platform issue (see below).

For me and my friends it's much more of a random length of time. Sometimes we'll go a whole 4-5 hour session with no problems. Sometimes we're in for 30 minutes and everything is hosed. It isn't locale based or event based. At least, I can say that generally within 2 hours we're having issues.

The only consistency my friends and I experience is when we're grouped up, we all seem to start getting hosed up at the same time.

A question I did have for those still reading... are we all on Windows 7? Me and my friends are all running Win 7 64-bit. If no one is experiencing this on XP, that may be a clue for Tech Support/QA to pick up on for trying to reproduce. Perhaps that is why they can't reproduce the problem in-house... I know a lot of the "QA" teams just get the hand-me-down computers, so it's entirely conceivable they're all running XP.

The problem with sound buffers does seem to be a good guess though. Too bad there's no way we could track that kind of info.

Work on Robots for a short time and you quickly understand that you get something wrong you KILL PEOPLE.

This forces programmers to NOT SCREW UP ANYTHING EVER.

Very much the opposite of game programming where the User is the Beta tester and tired of doing it.

(Note: we used all kinds of OS Linux, MS XP, 95, 98, 98SE, 2000 and Windows 7. Oh and IBM DoS.)

I seem to have found a fix for my sound issues as well as many other issues.

I simply installed the app Cacheman . . . . it's like night and day.

hmm then maybe the ram flush in Cacheman would work without having to close the game if needed? So far I haven't needed to do anything like that since installing Cacheman, but before that I would have to close the game to restore those sound files as well as rendering, etc.

Yes, and that's my point. If your company (or mine, for that matter... not that either of us have the dev staff to develop one, but let's pretend!) developed an MMO it would be 20 years in the making due to all the tests, procedures, and extra hoops one must jump through to be SIL-2 compliant or higher.

Not to mention developing code for a robot is a closed environment. You know the hardware, you know exactly the requirements, you know exactly what the outputs should and will be. You have simulators which allow you to test your code as if it were the real thing with a incredibly small margin for error.

Now think about that in terms of what environment an MMO runs in. It's apples and oranges.

My point is, there will be bugs no matter how hard you try. Some of them will be readily reproduceable, some will be easy fixes, and some will be completely hidden because the only way to reproduce it is via a long series of coincidences which end up forcing an unanticipated circumstance.

That is not necessarily bad programming, that's the reality of an MMO.

At any rate, not sure what to think about this Cacheman... I noticed no link was provided, unsure if this is something reputable or not? Anyone else have any info?

Please, shut up these speeders engine sound while THEY DON'T MOVE!!!!
Bring back the IDLE sound from 1.0-1.1

Here is a motto from the first programmers in the world they had posted on the wall for the ENIAC:

What could go WRONG?
(You do not know till you test it)

http://en.wikipedia.org/wiki/ENIAC

Sadly the good programmers are a dying breed and today bugs are accepted as normal. Think about this for a second. What is harder to do:
A. Check 300000 lines of code in 1s and 0s for a single error manually on printouts. (ENIAC)
B. Check a C program for errors by using the thousands of tools today.

ANSWER: A as you had to be very good at not screwing up. Using C just made everyone real lazy.

I couldn't agree more.
I work in retail, so allow me to give you a real world example:

A customer makes a small purchase, lets says his/her total is $5.79. The customer hands the clerk a $100.00 bill. The clerk punches a few buttons on the cash register, and it spits out a receipt stating the customer's change is $94.21. The clerk then hands the customer a wad of bills and some change, and says, "Your change is $94.21. Thank you and have a nice day."
What should have happened: The clerk should have counted back the change!
The clerk says, "Your total was $5.79. You gave me $100.00. Here is .21, which makes $6.00. Here is is four more dollars, equaling $10.00. (Handing the customer a $10.00 bill) Ten more dollars equaling $20.00, and (Handing the customer 4 more $20.00 bills, one at a time) forty, sixty, eighty, and a total of $100.00. Thank you and have a nice day."
Too many people can't even count back simple change anymore! Next time you order fast food, ask the teenager behind the counter to count back your change, and watch them stare at you like a deer caught in headlights!
As an added bonus (only good with U.S. paper currency), once the clerk states your total, inform them all you have with you are Federal Reserve Notes, and may you pay with them? You will get several mixed reactions, such as, "I don't think so, we only accept cash or credit", or "Are you in the military or something?'", or (most frequent), "Wait a moment while I ask the manager".
ALL UNITED STATES PAPER CURRENCY STATES "FEDERAL RESERVE NOTE" ACROSS THE TOP OF THE BILL.
I've even gone so far as to offer to show the clerk what a Federal Reserve Note looks like. I carry an older style $50.00 bill just for this purpose, as its not as well known as say, a $20.00 bill. I point to the "Federal Reserve Note" in bold print across the top of the bill, and 9 times out of 10, I get a response of, "No, I'm sorry, I don't think I can take that."

bump+

Even if it is "old" problem, it's weird that it never happened before 1.2 patch. So that memory leak wasn't there then. Something changed in 1.2 and the leak, or what ever is the cause, appeared. So if they had the problem fixed before 1.2, there should be a possible fix somewhere again.