EVE Information Portal

I never said it was "nigh on impossible", we have plans and such they're just not easy ;)

The fine folks over in Operations have been running experiments with virtualization in order to get a better idea how the Eve server specifically reacts to it. For instance, Sisi is currently virtualized. If it works out and we can migrate smoothly, that would allow us to take *groups* of solar systems and put them on beefier hardware. It doesn't give us the ability to isolate a specific solar system though, which is what the software-level migration (non-destructive live remapping, we call it) would give us.

As always, a step in the right direction is always good even if it doesn't go *all* the way, so here's hoping the tests go well!

Always makes me think of dark city http://www.youtube.com/watch?v=S5ZSDCvUwN8

I know in the old say when a side was about to loose, including their Super Caps they would perposly over load the node to make it crash.
Then there would he a long file of people petitioning to get their shinny toy replaced.

How has the customer services been since this implementations.

have the Customer Services been able to replace few ships resulting from large fights?

One question about TiDi:

Is it possible to put in game some space distortion/anomaly that appear in the space that's under time dilation?
This way players will have a feeling like its game feature, especially in systems that are on same node an system where fight is.
And add message from our ship computer, something like: "Ships sensors discovered time flux anomaly generated by unknown source. Ship computer cant predict time variables in this conditions."


There would be few pluses of this:
1. From annoying thing that ppl don't know why it is happening you make new game feature. In all space related stories there was some sort of time flux anomaly so its all ok from the side of the space story.
2. You add some nice new graphic of space distortion/anomaly in the space.
3. You add one new thing that ppl cant predict in the game (good thing).
4. You give ppl a story behind all of this.


Just a thought.

TiDi sucks when you are not in the big fight. I lost a scout ship a while back because right when I tackled a ship and my fleet was coming up behind me to support me, they got hit in TiDi and didn't make it to me in time.

Convince those 10-20% of subscription losses since last summer to start subscribing again.

(The bleeding stopped in December, once they revealed that Crucible was going to focus on the core EVE experiences with lots of bug fixes. But a lot of folks are still waiting to see whether CCP can continue to do things right, or whether they'll go back to not listening to feedback and just implementing whatever the hell they want, damn the consequences.)

Time dilation is amazing. It makes the funnest part of large fleet battles last even longer, watching people blow up. How can you go wrong? Now instead of floating in space for an hour waiting, and then a lagged out fight that happens in the blink of an eye, you actually get to spend a good amount of time in fleets actively fighting. Also, since it makes it easier to reship and get back to the fight in time the large fleet battles have become really interesting, they've become an event rather than just a quick show down.

I'm really looking to forward to Crucible 1.3 with the overview and bracket update. Even with time dilation it's hard to get your client to be responsive in large fleet battles, even with shutting off all the graphics and brackets. Things are certainly looking up for fleet battles.

Could lore this away.
Be cool to have time dilation explained as to many warp drives messing up time and space.
In space animation would be neat as well.

Its all about the server tools required and how long it takes to write and QA. Right now more easy and faster wins can be found in the client optimizations route.

When they get those fixed hopefully the planing work will already be done so its a straight forword path to writing and QA any code that is needed.

CCP from hard experience knows how many bugs get created from "simple" low level changes. The Client fixes are one example. On sisi the client is still fairly buggy but the results of the changes are major wins. The issue is finding the edge cases and the only way to do that is to let players test it. As was sayed above the next step is already in testing. If it gets cleared to deploy to TQ then we are one step closer.

Your ideas match mine but we just have to give the devs some time.

The problem with the 'jump lag' is that's its a handoff between two different sol node processes. Your client must open a new connection to the destination node, destination node tells the source node 'Hi, I've got this one', the source node disconnects, and the destination node tells the client to start loading environment. That 'hand off' has to be done within less than a second, *and* without any delays due to system load.

I know this problem very well, from some early work on reverse engineering the Second Life protocol (their case is very extreme, because you can have a vehicle crossing multiple 'systems' within a second as well!). That was back in 2006 or so, and last I heard the problem is still not solved over there.

From another angle, I think CCP does have the edge on this problem. Apparently windows systems have a facility to move an existing open socket between processes - even across computers. The downside, when/if implemented, is that Eve will no longer work in Wine/Linux as this feature has not been re-created there yet (it broke Uru's client in Wine when something similar was implemented there). Mac should be OK though.

[If Veritas or another Dev could pipe up at some point with confirmation or details, it'd be appreciated. ]