[2023] Regarding the Fleet Fight in X47L-Q

Hello everyone,

Yesterday you took to the battlefield and had yourselves a massive brawl in X47L-Q with local reaching over 6,000 pilots. These moments are always awe inspiring and we get extremely excited to witness these battles and wars unfold. It is our goal to deliver the capability for you to create these moments, in ever bigger and more glorious fashion.

I will go over the general circumstances surrounding the issues you experienced yesterday and what we are doing to address them going forward.

As for the issues that ultimately lead to a node death which contained the system in which the fight took place, they were unexpected. At this time it is not known what caused it, we are looking into this and if they relate to the previous recent node deaths.

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.

We noticed there was talk of a Rollback in the restoration of the system following the node death. We would like to clarify that this was absolutely not the case, and no decision was made by anyone from CCP to restore to a previously saved state of the system before the service containing the system terminated. We had indicators that a node death might be imminent and we prepared to bring the system back online. When the node death occurred the system was restored as is, with the very last saved state we had.

When the outstanding calls on a node begin to pile up, the information that is recorded can sometimes vary. Ship kills and losses are the highest priority, and ship location is often much lower. When the X47 node was killed and the system was placed on a new node, we were using the most up-to-date information available.

It has been a while since we discussed the method of requesting fleet fight reinforcements, given an issue that manifested yesterday this seems as good a time as any. When requesting multiple systems to be reinforced it is paramount that your staging system is not requested unless you intend to fight there. Staging systems naturally have more load, and thus more resources dedicated to them without you having to request them. Node reinforcements are done following downtime, in the case of there being more requests than dedicated fleet fight nodes they will be distributed onto those nodes and then resolved manually after downtime. In this instance the automated distribution placed one staging system with X47L-Q by chance and this caused some problems.

In the short term, we have as in previous large conflicts temporarily dedicated more nodes to serve as fleet fight nodes which become available after server downtime tomorrow. As you continue to push the boundaries, we continue on our goal to make that possible. We will look into these issues and inform you of our progress.

o7

Thanks for posting this explanation, Paragon.

Let me clarify.

The problem that arose from the staging system being on the same node as X47 was resolved shortly after server downtime manually. X47 was the only system on the node for multiple hours before node death.

Those two problems are not related.

For fleet fights the simple answer is that as the number of players n increases then the number of interactions increases O(n²). Server performance roughly entails a linear increase in the number of interactions and therefore a O(√n) increase in players.

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.

We don’t trust the client. The server and only the server is authoritative on the state and progression of the simulation.