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 Information Portal

 
  • Topic is locked indefinitely.
 

New Dev Blog: Time Dilation Video Demo

First post First post
Author
Previous Topic Next Topic
CCP Veritas
C C P
C C P Alliance
#101 - 2011-10-01 11:39:45 UTC
Tusko Hopkins wrote:
CCP Veritas, another quick question:
if the server decides to dilate the time, it obviously has to communicate this to the client as well. Because of this, for a short while the simulation speed of the client and the server will be different. Isn't this going to introduce some sort of desync for fast-moving ships?

Excellent question. When the server decided to slow down time, the decision is delayed for two seconds in order to smooth over that difference. Instead of being "Hey, I'm going to slow to .5 now!" It's "Hey, I'm going to slow to .5 time in 2 seconds, just so you know". This allows the server and client to apply the event at the same time and keep a much tighter sync.

If network conditions are bad enough that the event doesn't arrive in time, then the secondary simulation clock synchronization kicks in, which tries to smooth out the difference until the two times are back in sync. It should be reasonably smooth and such.

CCP Veritas - Technical Director - EVE Online
Debir Achen
Makiriemi Holdings
#102 - 2011-10-01 11:40:02 UTC
Two thoughts:

(1) Part of me wants to see a little "arrow" indicator denoting whether server load is getting worse / better / stable, purely as a way of predicting whether time is about to get more or less dilated. But the wiser part of me says that this indicator would add UI complexity without any real corresponding increasing in accuracy (a fleet jumps in, and it's going to go from "improving" to "more dilated" real quick).

(2) One concern: action spamming. Say my ship is being popped, and I quickly start spamming warp-out to get my pod away. There's a practical limit on how fast I can spam this command, but my understanding is that each "click" queues up an action on the server, most of which are redundant (because they arrive before or after the pod spawns). No consider if time is running 1/4 speed: I can fill the queue with 4x as many useless operations (and still only 1 useful one).

Is the load of these "extra" events significant? If so, is there a way to tweak the client-server protocol so that the desired event gets processed in a reasonable manner - allowing for potential lag and hand-shake time between client and server - without filling the event queue with lots of useless events?

Aren't Caldari supposed to have a large signature?
CCP Veritas
C C P
C C P Alliance
#103 - 2011-10-01 11:42:21 UTC
Jackk Hammer wrote:
I'm curious as to whether it will solve the problem of bombs travelling 100km+ or not moving at all in extreme lag.


If dilation is able to bring the load down to what the server is capable of, then yes, bombs will behave normally.

What I mean by that is that I do plan to have a lower limit on how slow we allow time to go (probably 10% speed). If the load is so extreme that going 10% speed isn't enough to keep up, the existing "method" of dealing with overloading will start to happen and bad things like this will crop up again.

CCP Veritas - Technical Director - EVE Online
GeeShizzle MacCloud
#104 - 2011-10-01 11:50:35 UTC
personally from a cinematic standpoint, i liked the slower camera movements, it was no where near slow enough to impede combat or navigation imho... it added some ability to smooth movement and give u time to really control what you're centering ur camera on!

idbe very dubious about adding some motion blur if the camera will be freed from slower movement. Could possibly add it as an advanced feature of the camera menu, so frapers can have the option of using it. but keep it off as a default.
CCP Veritas
C C P
C C P Alliance
#105 - 2011-10-01 11:51:24 UTC
Debir Achen wrote:
Two thoughts:

(1) Part of me wants to see a little "arrow" indicator denoting whether server load is getting worse / better / stable, purely as a way of predicting whether time is about to get more or less dilated. But the wiser part of me says that this indicator would add UI complexity without any real corresponding increasing in accuracy (a fleet jumps in, and it's going to go from "improving" to "more dilated" real quick).

(2) One concern: action spamming. Say my ship is being popped, and I quickly start spamming warp-out to get my pod away. There's a practical limit on how fast I can spam this command, but my understanding is that each "click" queues up an action on the server, most of which are redundant (because they arrive before or after the pod spawns). No consider if time is running 1/4 speed: I can fill the queue with 4x as many useless operations (and still only 1 useful one).

Is the load of these "extra" events significant? If so, is there a way to tweak the client-server protocol so that the desired event gets processed in a reasonable manner - allowing for potential lag and hand-shake time between client and server - without filling the event queue with lots of useless events?

Regarding 1 - It's very difficult to predict the future...don't even know how I'd go about making something like that remotely useful.

2 - Yep, this is something I will be monitoring once we go live with it. A great many of those types of requests get shot down quickly, so they are quite cheap, but they do represent a type of load that slowing down time does not lower.

CCP Veritas - Technical Director - EVE Online
GeeShizzle MacCloud
#106 - 2011-10-01 11:54:33 UTC
well veritas u can give a few numbers on what 10% speed means for a typical node and what it would be able to deal with right?

afaik the numbers are pretty impressive, let alone what TiDi would do to the performance of a reinforced node!
Fenaire
Caldari Provisions
Caldari State
#107 - 2011-10-01 11:55:06 UTC
They renamed LAG as Time Dilation and called it a feature?
Malcom Dax
Sebiestor Tribe
Minmatar Republic
#108 - 2011-10-01 11:56:03 UTC  |  Edited by: Malcom Dax
Not sure if this has been asked before, but in one of the videos thats been posted time gets stopped showing that this is possible. In reality, what is the most that time will dilate to? Will it slow-down as much as it has to in order to cope or is there a level that it will not go past? Will it ever stop while it catches up?

Edit: Also, +1 awesome for responding to this thread on a saturday Big smile

.
CCP Veritas
C C P
C C P Alliance
#109 - 2011-10-01 12:01:17 UTC
Malcom Dax wrote:
Not sure if this has been asked before, but in one of the videos thats been posted time gets stopped showing that this is possible. In reality, what is the most that time will dilate to? Will it slow-down as much as it has to in order to cope or is there a level that it will not go past? Will it ever stop while it catches up?

Edit: Also, +1 awesome for responding to this thread on a saturday Big smile


Yes, I can pause Eve. It feels good bro.

The plan for the automatic dilation system is to limit it to going no slower than 10% of normal time. The game feels very, very slow at that point, and I'm not sure I want an automated system to be able to make it turbo-slow. I may do such things manually, we'll see.

The client may, if it loses sync with the server clock, slow down to a stop (or speed up past normal speed) in order to regain synchronization. But, unless a dev or GM is explicitly pulling the levers, the server should not stop time on its own with the current implementation.

CCP Veritas - Technical Director - EVE Online
CCP Veritas
C C P
C C P Alliance
#110 - 2011-10-01 12:07:10 UTC
GeeShizzle MacCloud wrote:
well veritas u can give a few numbers on what 10% speed means for a typical node and what it would be able to deal with right?

afaik the numbers are pretty impressive, let alone what TiDi would do to the performance of a reinforced node!


It's heavily dependent on what behaviors are being exercised. Some things grow linearly in load, like shooting lasers at a single object - that load grows almost entirely with the number of lasers. Other things grow more quadratically, like launching missiles, where it scales both with the number of missiles being launched but also the number of people who witness it. The worst is things that grow cubically, namely AoE weaponry which scales on the number of shots, then the number of targets, then the number of witnesses.

But from what I've seen, "general" fleet fight behavior is somewhere between linear growth and quadratic growth. If we take a slightly pessimistic view and it grows quadratically, then doubling the number of people fighting will cause time to slow down by 4x, so if an 800 player fight is lag-free on a reinforced system these days (which is often true), then 1600 will be run at about 25% time.

CCP Veritas - Technical Director - EVE Online
AngelFood
#111 - 2011-10-01 12:13:27 UTC
Time dilation; Previously known as lag, now controlled by game ai. Great Cry
GeeShizzle MacCloud
#112 - 2011-10-01 12:43:39 UTC
SOZ FOR THE WALL OF TEXT! bahh!!

name and shame time once again!

Swayzz wrote:
so ccp could never get rid of lag ...they have tried for 3 yrs ...
and now one of the highly paid monkys has said lets put a little clock on lag and call it time dilation....
and all the little boy's and girls are happy ......

could we not spend some money on eve instead of the crappy console games your making and actullay fix it ?
more servers = less load= less lag ..


Fenaire wrote:
They renamed LAG as Time Dilation and called it a feature?


AngelFood wrote:
Time dilation; Previously known as lag, now controlled by game ai. Great Cry


you all need to go back to school and become intelligent, and if you currently do go to school then u should go back to watching cartoon network instead of showing everyone how impressively dumb u are.
GeeShizzle MacCloud
#113 - 2011-10-01 12:43:54 UTC

Will DestroyYou wrote:

Fair share of server time??? Seems to me a fair share should favor the ones not exploting the node. eg: slow down the larger blob more.


Currently server lag favours the force creating the server lag, cause theyre typically the ones that have loaded grid and are in system making all the requests to the server.

what you're saying is **** fairness i want the server to dedicate all its processing to ME!

Will DestroyYou wrote:

This said, I appreciate the effort being put in, and this is better then nothing. But why not a permanent fix? Some alliances wouldn't like it initially (namely, the same ones that are usually the problem), but they need to adapt for the good of the game instead of exploiting the server limitations.


you have to come to terms that there will ALWAYS be server limitations. Eve's customer base isnt near the size of some multiplayer games. so its likely to increase. CCP have been adding more and more servers that are more powerful to their server farm, and creating new coding to make it perform better, but there are actual PHYSICAL LIMITATIONS that will always create some form of lag, no matter how big or complex the server farm gets. Its simple physics!

Will DestroyYou wrote:

Fix the source of the problem. The blobs. You don't need 1000 (or 2000 with this dilation system) people firing on a single target. Change the game mechanics to split them over multiple targets (optimally in multiple grids or even systems). Change the mechanics to make NAPfests a disadvantage. Change the game to make alliances pay a price for becoming bloated.

Fix the cause, don't just patch up the symptoms. This is exactly why eve has always had lag issues.


you're not wrong that a huge amount of people are the cause of lag, but Eve Online is the ONLY game in the world that doesnt actually enforce limitations on player participation, in MMO's it is its Unique Selling Point and eve without it wouldnt be Eve!

on the subject of NAPs, they will happen regardless of any constructs that u place. ive been in fleets engaging only particular reds and making sure other alliances red to us, that were on grid werent shot at, on prior agreement. you cannot enforce the eradication of NAPS


Will DestroyYou wrote:
*Addition* Won't slowing time also make it easier to react to enemy orders? What effect is this going to have on battles?
it will mean FC's will have to get smart on what they do in the firefight and not just target call, but assess the battlefield and come up with new innovative tactics while doing what they do best. ;)
Tiger's Spirit
Templars of the Shadows
#114 - 2011-10-01 12:45:24 UTC  |  Edited by: Tiger's Spirit
Grey Stormshadow wrote:
One video shows more than 1000 words.

Looks great, works great, solves many problems,doesn't break the game, isn't just eye candy.
Well done, 10/10.

keep up the good work,
grey



Please tell to me, what is great on the video ?
It's a bullsh*t. A laggy video, just check mouse cursor movements there. I didn't see any great thing there, just missile lag and an useless,stupid idea.

Need to buy pause button in Noble Exchange.
Time dilation = Time dilettante
CCP want to sell to us, lag like a feature.

And other thing many players have desync without fleetfight, they will playing in slowmotion, because server will slowing down them? LOL

Remember Veritas words:
"The client may, if it loses sync with the server clock, slow down to a stop (or speed up past normal speed) in order to regain synchronization."
Abdiel Kavash
Deep Core Mining Inc.
Caldari State
#115 - 2011-10-01 13:09:19 UTC  |  Edited by: Abdiel Kavash
Will DestroyYou wrote:
*Addition* Won't slowing time also make it easier to react to enemy orders? What effect is this going to have on battles?

Ignoring the rest of the trollpost, this is actually a good point. With TD, you will actually have the time to analyze the situation and respond to the actions of 500 hostiles before half of your fleet explodes. As a logistics pilot, I can see this as a great help.

To everyone saying that people will just bring more: there is a definitive limit on the maximum fleet size, which is directly proportional to the number of people in nullsec alliances. The largest fight to date, LXQ, involved about 3,200 - 3,400 people. And believe me, the reason it's still the record is not because people didn't try. Assuming a reinforced node can handle 600 people now (which it reasonably can), and assuming that TD affects server performance linearly, with 90% TD (i.e. 10% speed) even a battle twice the size of LXQ should be playable.



Question for Veritas, can you make time go backwards? Big smile
Jack bubu
Caldari Provisions
Caldari State
#116 - 2011-10-01 13:21:00 UTC
Tiger's Spirit wrote:
Grey Stormshadow wrote:
One video shows more than 1000 words.

Looks great, works great, solves many problems,doesn't break the game, isn't just eye candy.
Well done, 10/10.

keep up the good work,
grey



Please tell to me, what is great on the video ?
It's a bullsh*t. A laggy video, just check mouse cursor movements there. I didn't see any great thing there, just missile lag and an useless,stupid idea.

Need to buy pause button in Noble Exchange.
Time dilation = Time dilettante
CCP want to sell to us, lag like a feature.

And other thing many players have desync without fleetfight, they will playing in slowmotion, because server will slowing down them? LOL

Remember Veritas words:
"The client may, if it loses sync with the server clock, slow down to a stop (or speed up past normal speed) in order to regain synchronization."

Stop posting



forever
Swayzz
Perseid Meteor Shower
#117 - 2011-10-01 13:25:16 UTC
ok you have said that there is a 2 sec pause to keep sync ...
so what happens when you jump 2-3 titans into a dialated system each with 100-200 ships ...
would this desync everything or pause the whole system till eveything is loaded ?


and why can't we add more servers? to eve ..is it the money or the hardware ?
Xenial Jesse Taalo
The Scope
Gallente Federation
#118 - 2011-10-01 13:29:29 UTC  |  Edited by: Xenial Jesse Taalo
Yes decouple this business from the camera. Indication is one thing, what the player feels is another, and the speed of the camera is going to be felt more than anything. Feel feel feel. As soon as time dilation starts, everyone in system is going to be bitching in local because their camera is turning into a slug and the players will feel and hate that heavy camera.

I'm no professional here I know, but leaving the camera connected to the server's slowdown was a flipping terrible idea (or compromise).


Edit - The same goes for any and all UI elements the player interacts with. If clicking, selecting, shifting cargo, etc becomes slower... blegh, you're doing it wrong. Imho. I would seriously hate it.
CCP Veritas
C C P
C C P Alliance
#119 - 2011-10-01 13:29:35 UTC
Abdiel Kavash wrote:
Question for Veritas, can you make time go backwards? Big smile


I can make the clock go backwards, but no systems are equipped to deal with that so it doesn't really do anything...

CCP Veritas - Technical Director - EVE Online
CCP Veritas
C C P
C C P Alliance
#120 - 2011-10-01 13:35:59 UTC
Swayzz wrote:
ok you have said that there is a 2 sec pause to keep sync ...
so what happens when you jump 2-3 titans into a dialated system each with 100-200 ships ...
would this desync everything or pause the whole system till eveything is loaded ?


I...didn't say anything about a 2 second pause to keep sync? I said changes in the advancement factor of the clock are delayed for 2 seconds so both server and clients apply the change in sync.

When a large jump-in happens, the server will react to being overloaded and pull down the dilation factor fairly aggressively. Once the ships finish loading, it will start to recover until back to full speed. At no point will time pause on the server.

Swayzz wrote:
and why can't we add more servers? to eve ..is it the money or the hardware ?

We can add more servers, sure. It wouldn't help this problem at all though. This problem is dealing with what happens when a single server becomes overloaded. When that happens, it doesn't matter a bit if we have 1000 other servers sitting around doing nothing - that one is overloaded and that's a problem.

CCP Veritas - Technical Director - EVE Online