CCP, this issue is sucking the fun right out of this game.
Fix this server issue…
“CCP please solve the O(N2) problem that has plagued all coding since the dawn of coding”
you realise the fix you want is considered a literally impossible task right?
the problems arise quicker when more players start using more and more AoE abilities, if you REALLY wanted a quick fix to bump up performance then the server suddenly disabling the following list would do that:
smartbombs
vorton projectors
burst effects (eg supercarrier modules and ecm bursts)
all fleet links
bosons
lances
reapers
phenomena generators
bombs (both bomber and citadel)
PANIC module
GTFO module
MJFD modules
bubble generators (anchored bubbles, dictor bubbles, unscripted HIC bubbles)
Citadel doomsdays
not aoe but honourable mention: all drones and fighters
quite obviously it would be a massive net loss to alot of playstyles and requirements that are present in most fights of this size, so pick your poison
8 Likes
We have thought about that; there are e.g. cases where we don’t need to track every single shot on a ship when it is clearly destroyed already. But then killmails would become inaccurate since the shots we decided to throw away since they didn’t matter would have been… thrown away.
2 Likes
Monitor and civilian railgun users BTFO
if the server can go without a downtime for several days you can just delay the downtime for a day when big fights hapen around downtime
Can’t most of the effect that use less resources be moved client side and use instances on the server?
Why does the server need to host smartbomb effects when your client can?
then the server having the final say in the moment would essentially go out of the window and cheating would become rampant, to prevent any sort of cheating like packet interception and edits it would have to vet the packets anyway to make sure they havnt been changed and the details are correct
at best it would be the same, at worst there would be no checking and people would just start having infinite range infinite damage smartbombs
2 Likes
Then ccp would have to give notice a head of time that there will be no DT, so therefore resources would be limited among other stuff that is needed for DT. The few times we havent had DT was simply for experiements.
Dont start fights near effin DT
1 Like
I remember that one try, prepared for weeks. What an epic fail, dreams of a (downtime) free world were shattered there 
I like downtime because miners sometimes leave behind juicy drones as their afk operations get disconnected without them bothering to sign off or at least recall their drones. 
3 Likes
We don’t trust the client. The server and only the server is authoritative on the state and progression of the simulation.
2 Likes
Tell that to people who have their prime time around downtime and therefore set their structure timers to happen around downtime. 
Downtime is a stategic advantage for defenders (or anyone moving big ships around) as downtime forcibly removes everyone from space mid-fight while the timers keep ticking down. People can use this to their advantage, and they will use it to their advantage.
As a result, fights do happen around downtime, sometimes even because of downtime.
I’d love to see the ‘no downtime’ changes progress far enough that we can do without downtime for multiple days, if only so that large fights like these do not get interrupted halfway a keepstar timer by downtime.
1 Like
Following server downtime a new boundary was pushed when an attempt was made to simultaneously log in every participant as the system was loading. Usually battles of this size do not span downtime and with this many participants the ensuing login process was very slow. This was not an unexpected result but we are looking into how we can better facilitate battles of this size around server downtime.
Perhaps one solution to this problem would be to prohibit a structure from coming out of reinforced, say 1 hour before or after downtime. That way it will help to avoid this scenario. Just build it into the timing calculation. It will allow a window of time that server can recover before the need for mass logins.
On a slightly different note, you could extend the repair timer to say 30 minutes, as the current 15 minutes seems insufficient when working in heavy TiDi, and the timer remains on normal time. Just a thought.
Agree that would solve the main problem to use the Downtime as a Tactical advantage, especially in Staging systems where a big fight has to be expected.
i would prohibit the timers 2 hours before downtime and at minimum 30 Minutes after Expected Restart.
Also Tidi and Armor Timers are a real problem, they definitely need to be upped to 30 Minutes.
1 Like
To answer the question of why in more detail, if a user’s client calculates and applies any meaningful results to the universe then those results could be forged by a malicious user.
If you allow them to determine who is hit, they can forge a hit on anyone. If you allow them to calculate damage they can cause any amount of damage they choose. To verify the client is honest, you’d have to run the calculations yourself anyway. You might be able to save a few cpu cycles by ballparking or range checking, but a client could still abuse whatever leeway the server allows.
People doing this can, and probably would, be caught eventually, but by then the effects of whatever they had done would already have been applied and you would not know for how long they’d been cheating and what outcomes were affected. Even if you did know and could roll them back, that has its own problems when legitimate players made legitimate decisions based on the illegitimate state that they’d like to keep.
Even supposing you lived in a utopia with only perfectly honest people, the exact state of the universe for each client is a little different, or in the case of network trouble it could be quite different, so even in this case all clients would not agree on what should have happened causing some users to see things that should not happen the way that they did. It’s a huge mess, and it’s best not to go there.
1 Like
CCP does not have to give any notification. They don’t notify you of upcoming patches, all contents of patches or related things anymore. CCP could very well decide, and should do that, on a whim to not have a DT if a massive server breaking battle is underway.
actually, it just means, to double the numer of pilots, you need 2² = 4 times the server performance.
You have been testing mass fleet battles on the test server for the last decade… At one point you will have to face the fact that due the massive calculations required by the game coding, server load vs internet hardware capacities world wide and client hardware capacities this cant be done without the occurrence of equally massive lag. I am not an IT expert by far but it looks to me like it will never be done what ever you try or many times your try. Lunacy is just this thinking that what you are trying to do will have different results while doing the same exact same thing over and over again.
Luckily they’re not doing the exact same thing, but are pushing the boundary further and further.
I wasn’t around back in the early EVE days, but I don’t think solar systems could handle 5000 people fighting back then.
I’m a bit curious why the Imperials didn’t trade so badly with Fraternity. In the battle of FWST-8, PAPI tried to anchor a Keepstar and the Imperials lost the ISK war by… well a lot. It probably was worth it to them so I’m not questioning trying to remove an enemy’s staging ground. However, in this battle the ISK war was almost even. The Imperium and B2 Coalition Commit, Win the X47L-Q Armor Timer Through Downtime | The Ancient Gaming Noob (wordpress.com) But this is a fully operational Keepstar, while in FW-ST the Keepstar the Imperials destroyed was being anchored.