Client Optimization and faulty hardware

Damnit, malfunctioning hardware can really ruin your day. We had a faulty fiber NIC today, which caused 1/3 of the nodes to go offline in the time it took to failover, same happened when the new one was inserted. So much for "hot swapping" huh?. It's been replaced and shouldn't cause trouble, we apologize for the inconvenience.

As I have mentioned earlier, we are working on client optimizations, focusing now on load times, then going on to rendering and UI specific issues. A report from Christopher Scott and Bug Hunter Hammerhead were especially good for pinpointing the problem under various circumstances (Kudos to you), and there are a number of contributing factors that when working in unison can create a number of very sucky circumstances. Most notably, insane loading times.

We have tracked down the "Top 5" list of offenders that we need to deal with, the only factor remaining, what of them can be dealt with in the short buildframe of Castor (roughly 1 month between major builds) or if it is more drastic changes needed that takes more resources and debugging meaning it would only end up in Shiva. Fortunately, some of these are easy, so they'll end up in Castor.

After this loading times, we're going to look at rendering, this is both the initial rendering of models and runtime rendering of the UI. Many UI improvemements are scheduled for Shiva, but these should not be mistaken for UI optimization. It's functionality vs. uhm ... spiffyness! And we aaalll like SPIFFEH! Well, we're working on both.

This is set to the highest importance. We have so many thing of "high" or "critical" that I set this one to "godly". We also have our best people on this, headed by our Lead Programmer, Fuhry. Since putting humour aside in such a large task would be fatal, we decided to call this project "Lagfest 2004", and Fuhry is therefore the Lagbuster. I'm gonna get him a hat with that when this is done. Hell, I'll get him into the Playboy mansion if he makes EVE SPIFFEEEHHH again.