EVE Information Portal

well it could be titans and motherships ,dreads,carriers .. all with support ...
if theres a way round it it will be found and exploited ..?

so if the sever is already maxed out .. and more jump in then it would have no option either to crash or pause ?


can we not add 2 servers combined to a single system working like a raid drive ?

Just quoting this for the benefit of people who aren't understanding what's on offer, because it makes my points better. This does accomplish something, by making lag predictable, moving it to "This is kinda slow, but at least I'm doing stuff." from "An hour of staring at a black screen, then ten minutes between shots at a ship that turned out to have died half an hour ago, and then losing because half the fleet got killed before they loaded grid."

Playing devil's advocate here: what about bigger/better servers?

Although I was under the impression that the Eve servers are already pretty top-end. Is there any information out there that talks about Eve's servers?

yahh there is tho digging it out would take a while, i know last fanfest they bought a top secret IBM super server to act as the dedicated server, that had a previously unreleased and unnamed new main board on it which was housing a previously unreleased and un-named new top of the range Intel CPU on it.

to my mind the only way CCP could do more hardware wise to their servers is to take a leaf out of that film 'Sunshine' and house the whole server farm in liquid coolant/liquid nitrogen. and thats a pretty mental and horrendously expensive thought! so right now its all about software optimisations!

i would say that CCP's code monkeys are seriously pushing python to its absolute limits. I know some critics say '**** it, write the damn thing in C' and thts kinda what theyre slowly doing. from what i remember CarbonIO and its underpinned python extensions are practically fooling python and sidestepping its main disadvantage!

it might be that in the future CCP can release itself from python, but it cant be something wished out of thin air, and it cant be something that they dedicate all their dev time to it, cause eve would suffer from being left in the shadows of other games in the marketplace.

Veritas,

I'd just like to give some serious kudos for this. Being a developer, I find this is quite an elegant solution to the issue of graceful degradation. Bit of a stroke of genius, IMHO.

As to the "more hardware" approach, IIRC your current brick wall is 1 node = 1 system, right?
Have you considered the possibility of 1 node = 1 grid? Granted this is probably a pretty major, hairy, overhaul of server code, but as a long term project, perhaps?

How much difference would that realistically make? From what I understand in a major fleet fight most of those involved are on the same grid anyway. I don't really see you getting a particularly big improvement in performance by doing this. At least not enough to justify the effort that would go into doing it.

When i first heard of the idea of time dilation i loved it! It does not solve the underliying problems but it allows EVE to suffer more gracefully. I agree with most people here saying that the UI should not be slowed in its responsiveness, but everything ship based must be slowed.

If you allow the UI to be slowed in time with dilation the perception of 'This time dilation business does not work, it is still laggy' will happen and EVE will get negative PR. i.e. CCP writes code to spin wheels that do nothing.

Video: I like it.

Notes:

1. i would like to see the timer PULSE when the time dilation value CHANGES. mainly cos I want my attention drawn to it when its state changes, so i can adjust my perception of what is going on.

2. When someone is in a system next door and starts the 'jump in' process, I would like a notice saying that the system is under time dilation and an indication of how much. Not sure how I would like this done. It could be the gate looks/behaves differently or the UI jump button is coloured differently (follows the time dilation factor colour code). Personally, I would like to see this information before i commit myself to starting the 'jump in process'.

3. If a system is under heavy time dilation, would it be sensible to lightly dilate the systems surrounding it. This is to prevent the 'run around the block to the other gate' concept. It would also give an indication that 'big *&!* is going down next door' and also reduce the huge difference in time dilation values.

4. The new font: yes the 0O and 6G are clearer. I'm unsure if it is easier to read. It is certainly _harder_ to read when using the Black colour scheme.

+1 overall.

Tedric.

edit: typos.

yes this is the case, only 1 or 2 exceptions to this ie jita node and the dedi server used when a particular system is reinforced.

nice mass test veritas! im working on a video of it atm and will post it :) have to say tho on the pos bash part when you put TiDi to 50% i swear you can see on missiles the 2 second sync checksum looping! LOL!

Excellent!

The one things that seems odd is that you plan on also reducing the client fps when time dilation kicks in. There is no good reason for that. Just the bad one that the graphics subsystem is probably incapable of running at a different simulation speed than the physics one...