EVE General Discussion

With Crucible we introduced the amazing ability of Time Dilation, a major step forward in the War against Lag!

Now that Time Dilation got activated on several occasions, we would like to ask for your feedback. Did you notice any difference compared to your 'normal' fleet fights? Was your EVE experience affected in some positive or negative way? Did you notice any strange or unexpected behaviour?

Let's help our brave developers and support them in the fight against the evil lag monster with good feedback!

since when is it active ? it was not on my last fleet fight, 4 days ago

This is correct, and will be the case for this weekend. If things are going great, then we'll likely go cluster-wide next week.

Was the node crash problem ever fixed? Or was that due to the server being ready to crash already and flipping the switch just pushed it over the edge? (Referring to the CFC vs Raiden/WN fight)

mmm i cant wait for this veritas! will buy you a beer as and when i go to fanfest sometime!

Pros:

TiDi seems to help increase client performance in that it feels as though the computer isn't struggling to keep up in eve-real-time.

TiDi exposes the most frustrating bugs in EVE.

Cons:

The bug when locking a target with weapons hot and the module activating as soon as a lock is established is MUCH more visible.

It feels like the server doesn't receive the weapons hot command + lock established in the same packet.

The stack of instructions (not the requests) for jumping while on a TiDi node is a VERY painful experience. It feels like the period of where your client is loading the next system is also dilated and blows monkeyballs.

TiDi exposes the most frustrating bugs in EVE

FOR THE LOVE OF ALL THAT IS GOOD AND HOLY: Please, I beg you, fix the bug of updating corp/alliance/standings after a jump into a system so my EVE friends don't show neutral after jumping into combat. To reproduce: remove the ability to see blues on your overvew (you might wanna have CCP set one side of the next engagement you monitor blue to CCP Alliance) and load grid on a friendly fleet. After loading a grid via session change, many pilots standings are not refreshed.

As I understand, the character info location is retrieved somewhere else... on another node?

Potentially you can have that node be set so that after a request for corp/alliance is made... a few ticks later this node automagically sends the same stack of requests for corp/alliance/standings to the fight to refresh it. Right now it seems as though this series of requests is done once. From there my update overview requests pulled from a cache. If this is true, a few ticks after the cache is created, there needs to be a way where it runs a check against the people missing corp/alliance and refresh them.

something... I don't know.

Can you explain this part, specifically?

I know (very well) that jumping hundreds of players around is a very painful experience. How exactly does Time Dilation make it worse in your opinion?

Well, it felt (and was) a lot longer than usual.
Sadly, i didnt think about frapsing how it actually looked on our end.

For instance, take the process how its happening on a lagged, but not dilated node.

-You warp to a gate.
-Click the jump button.
-Wait a moment
-See the jump animation on your ship
-Wait another moment
-See the ships around you disappear one after another (the ones that had the jump animation before you had it, that is).
-Ocasionally still have shield boost/hardener animation of ships around, but the ships themselves not. (I specifically recall a Maelstrom next to me that was just its shield - the shield was there, and animated, but the ship model itself was not.)
-see traffic advisories or other random text notifications
Then eventually you see the "jumping" text down there in the middle, see your local clear, your overview clear and disappear, come back and filling again (if youre lucky).
That took us about a minute per jump before arriving in dilated systems.

Then, in dilation, the wait was just longer. Everything concerning that lagged jump to the next system happened as i described it above, but much much slower. The ship jump animation happened fairly quickly, but time between you disappearing and loading new system were considerably longer.
Somehow it felt as if there was some timer that determines how many people within a specific timeframe the server considers safe to move off to another node (and therefore accepts or delays) which just got dilated as well.

I mean, to explain why i think of this here, we all know how the optics of a big jump look at a gate.
Everyone is at the gate, FC commands jump. People may or may not click all at once, but i think its fair to assume everyone clicks within 2 seconds after that command.
Whatever happens that everyone should have seen by recreating a fleet consisting of players trying to jump at once, people seem to get "grouped". You start to see a bunch of ships at the gate begin to play their jump animation. half a second later the next ones. then again, about the same timespan later, the next bunch. and so on.

But to my knowledge, the jump animation on the client is in no way representative to the actual session change over to the other system.
Whatever logic tries to "group"stuff or actions or whatever there seems to delay things more then necessary.


The wait between the clicking of the jump button and the actual jumping out of the system was far greater than expected, and a multiple of that we had with the same amount of people traveling before or after coming into dilated constellations.

We got stretched out by that a fair bit, so i figure both sides of the gate were not coping very well with the load (regardless of dilation) so the warp back to the gate after jumping because you nearly dropped and already did an emergency warp on the other side was nearly always the case in jumping dilated. Never had any emergency warps on the other cide before switching the client session (as i may call it because i have no real clue besides basic understanding of network techniques that may or may not be used here, translate into your intern CCP vocabulary as you must) to your ship in the new system.
Only times i had emergency warps after jumping without dilation was logging back in after the server was so lagged that it dropped the entire client connection with a timeout.


I think time dilation should help the server ease up a little under the load thats been put on it by the players interacting with it. But then it should be able to serve such session changes even faster.
A non-dilated server will just peak out at 100% load when a huge fleet changes systems. A dilated one should be able to free ressources from other stuff that is going on to help with jump lag.
Even if the entire node (thats all systems on that node) is completely empty of any players or interaction besides the fleet jumping, it should at least be the same time until all sessions are changed over to the next system. If it needs to dilate down in order to process the session changes more eficciently there should at least be a small improvement, not a nearly tenfold increase of needed processor time.


Maybe you can even create these effects yourself in your Dev Sandbox in Jove space somewhere. Put a bunch (200 should do) ships of whatever type (doesnt matter for session changes, does it?) in a system with activated dilation. make them fleetwarp to a gate, and use it. Maybe not all at once, but about 10 or 20 at once every few seconds. This part might need some twiddling with numbers and timeframes to represent a fleet traveling.
You should see time dilation getting active, and getting cranked up all the way down to nearly 10% within a few seconds. From there, every following pilot will take a good while until arriving in the next system.
Try the same without dilation, you should see a difference.

I suspect there are general inperformancies in how a session change is done, in the various steps somewhere where things need to get notified of the new statuses and so on. And it might have something to do with timers that depend on the ingame time, which makes them act up so violently when time gets dilated.

Does time dilation effect our ability to warp our pods out by spamming warp?

Just had time dilation in a 700 man fleet fight and it was very playable.

My only problem with it is that time dilation adjust itself to much and drastically, basically going from 15% to 90% and everywhere in between all within a minute. It should work in stages.

Anyways I love it.