There will be an extended downtime on Tuesday, 26 October, lasting until 11:45 UTC. A continuation from last weeks’ extended downtime which began the process of fully cabling a new SAN, replacing the DB hardware, and upgrading to SQL Server 2019. The server may be back up a bit earlier if work is completed ahead of schedule.
We’ll keep you updated on this thread and the EVE Status Twitter account if there are any noteworthy developments.
Yes, the network and DB hardware is being upgraded, and they’re changing to SQL Server 2019. None of that impacts the way CCP has coded their DB structure or its limitations.
It’s like saying ‘oh, the road outside my house is being repaved. That means the car seats more people, right?’
With the decline in player numbers over the past 10 years, logic would state that as the player load decreases, the available resources per player increases, especially when upgraded too.
Yet we’re still stuck with the upper bounded limits.
That’d be true if two conditions were also true. First, when someone stops playing, their assets are all removed from the DB. But you can stop playing for 10 years, and then come back and have all your stuff.
Second, if CCP had coded their DB structure to be dependent on ‘there are X slots in the DB spread among Y players’. Which isn’t the case.
Their assets are “inactive” and not queried or cached as they are being unused, since the player “stopped playing” by definition. They may be stored sure, but not queried or cached, that’s an important difference don’t you think? Storage is cheap.
Not really. First, CCP has no way to control that: the player might come back. Second, it’s not really relevant to issues like max inventory size. That’s all in how they structured things the last time they overhauled the DB structure, and isn’t dependent on player activity or the underlying hardware or db software being used. Those things might impact the speed of response, but response time isn’t why caps are in place. That’s all about the same structural concerns that necessitate the ‘can’t put a container in a container’ response.
Anybody who does anything with BPO’s and BPC’s probably has a ton of cargo containers called “Blueprint copies 1”… “Blueprint copies N”. It becomes cumbersom and a terrible player experience.
And when you want to haul them, it’s even more cumbersom.
Yes, I know, I deal w/BPCs, myself. I’m not saying they shouldn’t fix it. I’m just saying these changes have no bearing on it. That would need them to actually go in and recode the underlying structure of the database.