Very good to know! So the client needs to be written and altered if possible - otherwise we get all the servers back?
Just that the names can't be easily changed. Which ones are active or listed can be altered as that comes from the server when you connect. The authentication server sends a list of numeric IDs -- along with the current number of active players (for the load level bubbles) and IP address -- for the client to choose from. The client appends each ID to a hardcoded string and looks it up in the translation table, which is loaded from the client messages bin file. CoHWorldServer_1, CohWorldServer_2, etc.
A monkey with a hex editor might be able to pull off changing a server name to a different name of the same or shorter length. But they couldn't make it longer, and they'd run into serious problems trying to reintegrate the extracted bin file with the game, getting past pigg checksums, etc.
I think we all suspected that a new launcher and at least a client patch would be needed anyway, I mean that the new servers would have a different IP than the original so the new launcher would have to point at the correct server address to apply the client patch or even download a clean client for those who don't have it anymore. Wouldn't it?
Then there is an issue of Logo's and what not, the new masters would need to slap their own brand on that hide. . .
Downloading the client and patching the client, while often performed by the same launcher, aren't necessarily tied together. One is easier and less complex than the other.
Dropping in a texture replacement and modifying .bin files without dev tools are on completely different levels as well.
For that matter I don't think even the .pigg archive format has a publicly-available way to
create them. There are plenty of viewers, but no tools I can think of are comprehensive enough to create new ones or patch existing ones (which is more easily done by creating a new one to replace it anyway). That's a little surprising to me since the pigg format is relatively simple.
Or they could do what players have been doing and drop replacements into data/, which works to override any type of file that's not on the forbidden list. But it looks amateurish, and players would be able to delete their data directory and revert those changes. Not to mention support headaches with other client mods that go into data/.
My own opinion on number of shards is that due to the heavily instanced nature of the game and the fact that the architecture shares a pool of map-hosting servers, there is little reason to limit the number unless you're anticipating an extremely low number of players. Once you have enough hardware to run
one shard smoothly (and don't fool yourself, it'll take quite a bit just for that), you can easily fire up 2-5 more without taking much of a hit on resources at all.
From available evidence (mothership raids, hami raids, iTrials, Freedom stress test, ITF valley of lag), the server software doesn't scale particularly well with the number of players/critters at all. In that case, a large number of shards with a lower population each would support more players on the same hardware than a few heavily populated ones.