These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE General Discussion

 
  • Topic is locked indefinitely.
123Next pageLast page
 

Time Dilation feedback

First post First post
Author
CCP Phantom
C C P
C C P Alliance
#1 - 2012-01-12 11:49:28 UTC  |  Edited by: CCP Spitfire
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!

CCP Phantom - Senior Community Developer

inexistin
Rubbish and Garbage Removal
#2 - 2012-01-12 12:35:59 UTC  |  Edited by: inexistin
Didn't participate to any Time Dilated fight, unfortunately Sad
Raid'En
#3 - 2012-01-12 13:16:05 UTC
since when is it active ? it was not on my last fleet fight, 4 days ago
ChromeStriker
Sebiestor Tribe
Minmatar Republic
#4 - 2012-01-12 13:21:41 UTC
Raid'En wrote:
since when is it active ? it was not on my last fleet fight, 4 days ago


It was only activated for a few fights, with dev supervision, not across the whole cluster

No Worries

CCP Veritas
C C P
C C P Alliance
#5 - 2012-01-12 14:01:46 UTC
ChromeStriker wrote:
Raid'En wrote:
since when is it active ? it was not on my last fleet fight, 4 days ago


It was only activated for a few fights, with dev supervision, not across the whole cluster

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.

CCP Veritas - Technical Director - EVE Online

Neo Agricola
Gallente Federation
#6 - 2012-01-12 14:07:06 UTC
CCP Veritas wrote:
ChromeStriker wrote:
Raid'En wrote:
since when is it active ? it was not on my last fleet fight, 4 days ago


It was only activated for a few fights, with dev supervision, not across the whole cluster

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.


I like that Idea of testing something "in Production" even if it killed that fight with WN.

Looking forward to see it in action...

DISSONANCE is recruiting Members: https://forums.eveonline.com/default.aspx?g=posts&m=706442#post706442 Black-Mark Alliance Recruitment: https://forums.eveonline.com/default.aspx?g=posts&t=6710

Alua Oresson
KarmaFleet
Goonswarm Federation
#7 - 2012-01-12 15:40:59 UTC
CCP Veritas wrote:
ChromeStriker wrote:
Raid'En wrote:
since when is it active ? it was not on my last fleet fight, 4 days ago


It was only activated for a few fights, with dev supervision, not across the whole cluster

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)

http://pvpwannabe.blogspot.com/

Neo Agricola
Gallente Federation
#8 - 2012-01-12 16:16:38 UTC  |  Edited by: Neo Agricola
Alua Oresson wrote:
CCP Veritas wrote:
ChromeStriker wrote:
Raid'En wrote:
since when is it active ? it was not on my last fleet fight, 4 days ago


It was only activated for a few fights, with dev supervision, not across the whole cluster

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)


afaik: They fixed that problem on the day after that fight...

EDIT: https://forums.eveonline.com/default.aspx?g=posts&m=626332#post626332

DISSONANCE is recruiting Members: https://forums.eveonline.com/default.aspx?g=posts&m=706442#post706442 Black-Mark Alliance Recruitment: https://forums.eveonline.com/default.aspx?g=posts&t=6710

GeeShizzle MacCloud
#9 - 2012-01-13 19:42:35 UTC
mmm i cant wait for this veritas! will buy you a beer as and when i go to fanfest sometime!
KrakizBad
Section 8.
#10 - 2012-01-14 18:13:42 UTC  |  Edited by: KrakizBad
Looks freaking awesome at 10% \o/

Ships slowing down coming out of warp is particularly cool.

Also, I'm sorry we couldn't live fire it for you today. We tried, I swear.
Zagdul
Virtual Progression
#11 - 2012-01-15 09:17:54 UTC  |  Edited by: Zagdul
Pros:

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

ArrowTiDi exposes the most frustrating bugs in EVE.

Cons:

ArrowThe 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.

ArrowThe 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.

ArrowTiDi exposes the most frustrating bugs in EVE

ArrowFOR 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.

Dual Pane idea: Click!

CCP Please Implement

mercuryyy
The Scope
Gallente Federation
#12 - 2012-01-16 11:59:53 UTC
IdeaPrioritize actions that result in people leaving the system. As in "leaving through a gate", "using a jump drive out"(when not agressed maybe,needs research) or "clonejumping elsewhere".

TiDi happens because there are too many players in the system, doing to many things at once that all have to be relayed and transmitted to each and every client.

I was in a fleet (3 combined fleets for that matter) last weekend. Tried traveling together, but soon got streched out. Gatelag is bad enough already when a few hundred players try to use the same gate. Its much worse when you dont have to wait 30 seconds after the jump command (and get a bunch of traffic advisory notifications in the process) to actually see a jump animation, let alone wait for you to load the next system.

Its absolutely worse waiting those 30 seconds being dilated to 10%. And when finally loading the new system, being at the emergency warp position. Yes, it took us the better part of an hour to travel 7 Jumps.
As soon as a few pilots activated a gate for jumping out, one could see the dilation notifier in the corner turn and turn and turn..
Being this was only a test probably saved the GMs from getting time dilated as well, as there briefly was an idea of about 700 pilots just stopping to try to leave a system, but file "stuck" petitions all at once We talked that one out of the idea though.

CCP Veritas
C C P
C C P Alliance
#13 - 2012-01-16 12:53:07 UTC
mercuryyy wrote:
Its absolutely worse waiting those 30 seconds being dilated to 10%.


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?

CCP Veritas - Technical Director - EVE Online

Zagdul
Virtual Progression
#14 - 2012-01-16 15:08:11 UTC
CCP Veritas wrote:
mercuryyy wrote:
Its absolutely worse waiting those 30 seconds being dilated to 10%.


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?


I don't mean to speak for him, but the process of jumping feels like it's bugged to hell and back. Putting it into TiDi exposes it and you feel the entire process failing and bugging out far more during TiDi than you would without.

The process of jumping through a gate needs help, potentially something more drastic than optimization.

Dual Pane idea: Click!

CCP Please Implement

mercuryyy
The Scope
Gallente Federation
#15 - 2012-01-17 11:46:13 UTC
CCP Veritas wrote:
mercuryyy wrote:
Its absolutely worse waiting those 30 seconds being dilated to 10%.


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.
Tallian Saotome
Nuclear Arms Exchange Inc.
#16 - 2012-01-17 12:22:54 UTC
As said, the hand off of players between systems seems to be getting affected by the dilation, and (Based on what Veritas was saying in local this weekend) the high cpu cost of changing systems on the server is causing the dilation to go straight from 50% or so down to 10%, and then make the jumps take 10x as long as they would normally.

Make jumping exempt from dilation, or make its cpu cost not affect the dilation, perhaps?

Inappropriate signature removed, CCP Phantom.

Cearain
Plus 10 NV
It Burns When I'm PvPing
#17 - 2012-01-17 16:03:30 UTC
Does time dilation effect our ability to warp our pods out by spamming warp?

Make faction war occupancy pvp instead of pve https://forums.eveonline.com/default.aspx?g=posts&m=53815&#post53815

Elise Randolph
Habitual Euthanasia
Pandemic Legion
#18 - 2012-01-17 18:11:32 UTC
We got to experience TiDi a few times in the last week, and it was nothing short but amazing today. It made a fight that would have surely been ruined by lag easily playable (and fun too). CCP Veritas saves the day!

~

Timural
#19 - 2012-01-17 18:15:30 UTC
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.
Hedliner
Sniggerdly
Pandemic Legion
#20 - 2012-01-17 20:14:10 UTC
We got this for the aforementioned 700 man fight earlier, we loved it and it worked. Thanks for implementing something which works! Please never take it away.
123Next pageLast page