To solve the issue of too many in one system for the server

Due to the recent fight in M2 being denied by the server we have a mechanic now that any large alliance can defend their timers simply by packing the system with alts in ships. The server clearly has a limit of characters in any given system and fights of 10k plus people is beyond our current reach.

So until significant changes can be made to accomodate very large numbers in a given system I propose this:

Timers on Keepstars and Fortizars caused with x period of time align with one another.

So for example Keepstar 1 is put into reinforcement and yields a timer of X.
Keepstar 2 is put into reinforcement within 24 hours of Keepstar 1 and then has timer of X.
Keepstar 3 is put into reinforcement within 24 Hours of Keepstar 2 and has timer of X.

So in the scenario I have outlined above the defenders could choose to stack a system or split across all 3 systems. So if the option of stacking a system is chosen then 2 Keepstars will fall. If the fleets are split then there is a fight across all three.

I am aware that this model will not work when there is only one keepstar left and this can be defended by stacking said system but the chaining of timers will encourage the attackers and give defenders a headache as to which system to defend as you in CCP work out how to increase the ability of more pilots shooting at one another in one system.

I do not say this is a perfect solution and I am sure a sweatlord on here will moan but I am trying to think of a quick fix to allow the war to continue and this mechanic will alllow that.



This is stupid, The fight was denied by poor leadership decisions, NOT server failure. Papi attempted to cyno in on the keepstar, that already had been gridlocked by Imperium.
The proper play would have been to either cyno into the Papi fort, or pass on the fight due to the risk after allowing Imperium grid control for 3 hrs. This has been pointed out in two previous server failure losses by Imperium. This issue has been known since the inception of eve. and everytime theres a server improvement made, theres a server breaking fight. Papi Leadership ■■■■■■ up, pure and simple.

Even Bobby Atlas knew better than to try and cyno a capital/super capital fleet into a grid controlled by PL and DRF, and refused to do so, even though it meant his alliance imploded the next day.


I think the point is that there was no ‘fight’ because the server couldn’t handle the fight that PAPI leadership decided to take. It’s a post about game/server mechanics.


Let me reiterate, this is about side A wanting a fight with side B. The Eve platform in its current state would not allow this.
Any talk of good, bad strategy, being foolish or not being on the correct side is just useless noise.

The crux is a fight was denied. The outcome of said fight is irrelevant because the point is the fight could not take place.

The suggestion allows for fights to continue with the same risk and reward.

1 Like

PS the stacking of Station timers could be linked to one or two Sov timers as well. This would remove the last Keepstar left issue.

The attackers will still focus on one keepstar and the defenders will still try to cyno in on that keepstar once they realise which one is going to be attacked.

Fozziesov allowed for fights to happen by creating capture points across several systems (it is essentially the same as your idea) and everyone complains about how awful it is.

No, you’re trying to disadvantage a defender here, a stacking of timers dilutes side b’s forces over multiple stations, or save one station at the loss of untold numbers more. Meaning an attacker has every advantage at that point, either hit all structures left unguarded, or if the defender spreads out to defend them lump the attacking force onto one structure and kill off that portion of the defenders assets.

The point is, THERE COULD HAVE BEEN a pew pew at m2- part 2, had Papi leadership not blundered.
if they had cyno’d onto the Fortizar, they could have loaded grid, undisturbed and then warped into the fight. as it was they cyno’d into weapons range, on a taxed server, and paid the price of their Hubris.

This is the same thing Imperium said about the boson trap that failed, Papi responded with things dont work in heavy tidi, This was Imperiums complaint at Yz9 keepstar anchoring, bubbles everywhere 6000 Papi already on field, no one in wave one from Imperium could load grid, Papi responded with Things dont work properly in heavy tidi. Stacking station timers from stations reinforced hrs even days apart is a BS fix.

Everytime CCP gives us a setup that can handle the amount of players in system we want, we add more. Dont blame them or the Server for what in the end was a Leadership mistake. We all know what happens when you cyno in so many at once on a loaded grid, And many times over, that problem has been avoided by jumping to a friendly point first, then warping in.

It’s not though. The proposal is about giving something to attackers and taking it away from defenders.

Regardless of M2-, it just doesn’t seem like a good approach as there is nothing inherently wrong in defenders defending their stuff and all this encourages is for sides to get bigger and bigger so that they can defend multiple timers by progressively staging in time to still get the same outcome.

In that situation, this proposal just makes it even harder to attack someone and won’t solve the perceived issue here.

I think there’s a lot of debrief and review needed all around before it’s time for anyone to be making suggestions on how to change the situation.

1 Like

Sure but then the problem still is that any system that a group that can form 5k people becomes invulnerable. Which means CCP “has to” change game mechanics.


Yeah, that doesn’t seem like it would work. As Felonia noted, that would just force defenders, but not attackers, to split their forces.

I don’t have a fully baked solution, but I feel like there is a kernel of an idea here: what about instead of time dilation, they use alternate realities. Make X instances of the system and split the players up between them. E.g., if 10,000 players show up, and you can only really handle 2,000, make 5 instances of the system, split the players up between them, if the Keepstar is destroyed in 3 or more, it is destroyed. If it repairs in 3 or more, it is not destroyed. Whatever happens to a ship in whatever instance it is in is what happens to that ship. For anything in space that doesn’t have a pilot, maybe whatever happens in the initial instance is what sticks.

There would probably be problems that would need to be dealt with where you’d end up with 2 instances with all pilots from one side and 2 instances with all pilots from the other, so they’d need a mechanism to prevent that… Probably would be a lot of other issues, like you’d have to come up with a mechanism to roughly distribute classes of ships across the instances so you didn’t end up with one side getting all their logi stacked in a single instance. You’d have to figure out how to do loot. But I wonder if there isn’t some kind of a solution there that is at least better than the status quo, until CCP fixes the underlying architecture.

so WoW phasing…how about NO!

What about 3 wormholes or tears in space open up near the structure and the entrence/exit’s appear 3 jumps from the main system.

Players can fire their weapons through the wormholes (ships can’t move through the wormholes only shot’s) and hit the citadel with it. This would split the attackers and defenders forces into 4 systems: main + the 3 wormholes.

The server only needs to calculate the total dps entering a wormhole as a single entity or calculation which will free up a lot of processing for the main system.

Attackers will for sure use it instead of piling into the main system and defenders will feel forced to defend those 3 extra systems so it becomes a bit harder to game.

Could also work lore wise if citadels (maybe just keepstar) implement some type of triglav tech which causes space to bend with the sheer power of the power source becoming unstable.


I don’t think we as players will ever have the true “solution”.

The long term solution for CCP is to continue to do what they’ve been doing, to reorganise the backend into a microservices architecture that can scale horizontally across physical blades, and anything that isn’t directly gameplay, get’s moved off to other servers all together.

While I don’t know which hypervisor CCP are using, I can probably guess which one, and it (and all of the main competitors) now also provide container runtimes directly on the hypervisor with no server; and that’s probably where the code will end up also - microservices running in containers that can scale horizontally on a single blade and across blades where necessary.

That way it’ll be easier for CCP to scale the compute requirements needed to handle 10000 trying to get in system, with drones, cans and everything else that adds to server load.

It’s already so much better than it was even just a couple of years ago, but the solution is likely to be invisible to us, not just changes in mechanics.


That is pretty interesting I always thought they where limited to 1 server per system instead of being able to combine a few for a single system in eve.

Finally someone with some sense. Fixing the issue should not involve changing the game or its mechanics, the solution needs to be directly associated with the issue. With that said, if CCP knew there was a pilot cap and the server couldn’t sustain the number of pilots about to be in system and they failed to release that info then shame on them. CCP is informed of these fights ahead of time to avoid this issue. At least knowing that bit of information both sides could/would have possibly changed tactics to avoid a complete cluster F. And no it doesn’t matter if PAPI had come into the system from another method or location and then warped on grid, the outcome would have been the same once they landed on grid with Imperium, the server would have choked just the same.

@Felonia_Despare Goonswarm is blaming PAPI for the server crash. You’re not qualified to represent the problem that happens in M2. We need some neutral to tackle the issue. I’m also tired of the false propaganda from both sides.

Im not qualified? I was there. they cyno’d in at risk onto a controlled grid, a mistake that has been known since even before eve could handle 4000 people on a grid, even before TIDI was implemented…

They should have cyno’d onto the fort on grid, taken all the time they needed to load grid, then they would have been able to do what they wanted with a much lower chance of failure. Nobodies blaming Papi for the server failure, but we are saying stop crying about the server failure when you yourselves knew the risk and did the thing… Much like they told us in YZ9, witht he bubble wrapped keepstar, and in Operation ENHO where the bosons failed, in what CCP admitted what a server side error.

The solution, is a server that can handle 20000 clients interacting at once, with lightening fast connections to all players, untill we blob in 40000 clients.

So do you expect them to go hey they are already there, therefore its fine if they win without a fight? seems rather silly

1 Like

Actually maybe not, CCP’s changes have brought in these types of responces:
“Unsubbing 5 of my accounts only using 3 now”

Which means soon the same amount of players will be on grid with less alt’s which is easier for the server to handle.

CCP is obviously pushing for faster and more optimized servers but that will always increase at a certain speed it wont miraculously just get 20x better now because it is “needed” so for now other solutions need to come in until the hardware and software catches up.

All in good time.

They had an alternate cyno, straight onto their own Fortizar, on the same grid, and then they could have taken as long as needed to load grid.

They would have had to contend with bubbles, but that is also something than can be worked around, as it always has been.

Jumping straight onto the Keepstar was a tactical error, and possibly bought on by being behind in preparation.