EVE Information Portal

Been in Eve a fair time now and the fact that the Jita node supported this type of activity and numbers shows how far CCP have come in addressing the lag monster with both hardware and software solutions. Very well done to all those invovled over the years in this process.

I won't go into individual people for losses, sorry! But the others (Jita only, the previous post with kill links included neighbouring systems):

Freighters: 37
Obelisk 17
Charon 14
Fenrir 4
Providence 2

Jump Freighters: 9
Rhea 6
Nomad 1
Anshar 1
Ark 1


Of the 337 "industrial" ships lost (I expanded it to be not just industrials but freighters, jump freighters, transport ships, exhumers, mining barges and industrial command ships), alliances who lost the most:

Goonswarm Federation 28
Test Alliance Please Ignore 5
Loosely Affiliated Pirates Alliance 4
Fatal Ascension 4
Tactical Narcotics Team 3

On the SP lost front, I'll take a look but will probably take a while before I can get to that.

This issue originally came up in this thread. Because the Jita node was running dilated, it effectively meant neighbouring systems on other nodes were running at a sped-up rate (relatively speaking).
This caused some issues with clients - specifically a client in Jita believing that a bad guy had 15 minutes of 'Jita-time' GCC. However if that bad guy had left Jita, spent his GCC time elsewhere, and then returned (so from the PoV of Jita he had fast-forwarded through time), the server would happily accept that he was now innocent (having served his time). But your client (running dilated due to Jita-time) might think he had maybe 7 minutes of GCC left. Hence why he appears red to you. When you try to fire on him, your client sees the (incorrect) red flag, and so doesn't give the usual "Are you sure - CONCORDOKKEN?" warning.
The server receives your open-fire request, and happily follows it. It then happily bring in CONCORD to kill you for attacking an innocent person.
(This is now reminding me of studying Special Relativity and the Twin Paradox)

The server had the full information and did the right thing. The client had incomplete and incorrect information and did the wrong thing. These kind of 'incomplete information' trade-offs are absolutely essential to obtaining any kind of scalability. Normally you make certain assumptions (such as "15 minutes here is the same as 15 minutes there") in order to bring down client-server interactions to a sane level.

On Friday evening, we live-fixed a solution for this on to the Jita node. This fix was then rolled out to all nodes during the Saturday-morning downtime.

The GMs are aware of the particularities of this defect, and are working through a number of related cases. If someone has petitioned a loss like this, then it will get looked at as they get through the queue.

Yes, the population cap meant that ganking in Jita was actually the wrong choice for most of the weekend. Nice juicy targets would stack up trying to get into Jita and getting the node full message. So you had plenty of time to scan them all and blow them up. So anytime the node was full, we jumped into another system and ganked everyone waiting to get in.

Good times.

No. This path is a dark one, filled with terrors and things unspeakable. We do not want to go down it.

What happens now? What was the fix?

I could see:

Inform all clients of the correct time GCC time when someone jumps into system;
Make the 15 minute timer not subject to TiDi;
Something else...?

What was the fix?

------------------ BUG --------------------
No it isn't a filter problem. The information about alliance or corp is missing after a session change. Those pilots are neutral to others. It's an annoying bug in 0.0. It happens with heayv server load.
------------------ BUG --------------------

Could you add some corp stats?

And we sure got that testing.

Thank you!