|
Author |
Thread Statistics | Show CCP posts - 22 post(s) |
|
CCP Fallout
C C P C C P Alliance
171
|
Posted - 2011.09.30 18:57:00 -
[1] - Quote
Now on Singularity: Time Dilation. Watch CCP Vertias' new video blog for a personal demo on how we are winning the War on Lag. CCP Fallout Associate Community Manager EVE Online @ccp_fallout |
|
|
CCP Veritas
C C P C C P Alliance
85
|
Posted - 2011.09.30 19:12:00 -
[2] - Quote
Abdiel Kavash wrote:- Does the effect affect everything running on one node? One system? One grid? - What are the implications for items and abilities crossing node boundaries? I.e. cynoing or bridging from a healthy node to a dilated one? - How does TD interact with various POS and sovereignty timers?
- Everything on the node. Not ideal, but it was the simplest implementation to get the idea out there. We may sometime change it to be system-specific but there are no plans currently. - Jumping/Cynoing in is not treated specially. You jump, you land, you proceed slowly. - POS and Sov timers do not dilate. CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
85
|
Posted - 2011.09.30 19:24:00 -
[3] - Quote
My spies are telling me some folks aren't seeing how or why that helps them in an overloaded situation. If you are one of those people, please go refresh up on my mountain of words on the subject then come berate me with questions. CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
85
|
Posted - 2011.09.30 19:27:00 -
[4] - Quote
bldyannoyed wrote:Really could do with getting rid of the camera and targetting effect (and in fact any UI) dilation. Whats the point of developing a system that will help beat lag if you then go out of your way to make everything still look like its lagged to hell?
I dunno about you but stuttery cameras and stuff are just going to irritate the hell out o fme.
The advancement of time changes rarely enough that I really wouldn't call it stuttery. The goal was to convey that time is, in fact, slowed. There's no point in pretending its not. CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
85
|
Posted - 2011.09.30 19:36:00 -
[5] - Quote
leich wrote:I Dont get the UI elements slowing down. It just makes the game look Laggy. I thought thats what this was trying to prevent.
That's not what we're trying to do at all - we're not trying to hide that the server is overloaded, we're trying to make the server overloaded in a way that maintains game mechanics and keeps things responsive. Select UI was brought over to the dilated clock in order to help convey how slow the universe is moving. It's a hard thing to judge without seeing it live.
leich wrote:I also dont like the idea of it effecting an entire node. It should only effect the Grid or system at the extreme not the whole node.
I don't particularly like that either, but it simplified the implementation enough to the point that this could actually be done. CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
85
|
Posted - 2011.09.30 21:30:00 -
[6] - Quote
Vincent Athena wrote:CCP Veritas: any possibility of getting a number for the little TiDi level indicator, otherwise known as Gamma? Starting at 100% and dropping as things slow? Also the stuttering is sort of annoying. And if Gamma got down to 10% or 5%, the slowing of the UI panning or typing would be a major annoyance.
There is a tooltip when hovered over on the latest internal build. I still think you're the only one calling it Gamma though
Typing doesn't get slowed down, and, client performance willing, things are still smooth. The client in this video was struggling a bit due to ZOMG MISSILES while also being Frapsed ><
The camera speed slowing down does get pretty unwieldy down in the 15-10% range. I'm going to see if I can sanely decouple it, since feedback seems pretty united there...we'll see how good my code-fu is. CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
87
|
Posted - 2011.09.30 22:42:00 -
[7] - Quote
Vincent Athena wrote:Actually I'm not. Everyone who works with Relativity, where the term Time Dilation comes from, calls the time rate ratio Gamma. I'm just going with the majority.
Hey, you get your facts right out of here. CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 09:37:00 -
[8] - Quote
GeeShizzle MacCloud wrote:not sure if veritas will enjoy this bit of test server tomfoolery but frapsed some stuff done tonight that was interesting and fun when it comes to Time Dilation... hope u guys like btw! http://youtu.be/qgXp0S0-wPA I enjoy it enough to quote it up again so more people see it ;) CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 09:40:00 -
[9] - Quote
Hatsumi Kobayashi wrote:Have you tested specific situations under time dilation yet, such as bombing runs, logistics module and so on so forth, or have you kept testing to seeing if time is actually slowed down to allow proper gun cycling, leaving the rest to the SiSi mass tests?
While it's really cool to see that things seem to be working as previously advertised, I can't wait to see/feel/hear about TD's effects on other common fleet mechanics that are currently more than a little wonky in current heavy lag. Habakuk and myself have tested a fair bit of what can be done with 2 dudes and a small army of robots, but things like proper bombing runs just aren't doable with that kind of setup. You guys should totally come do bombing runs in mass tests (with coordination with Habakuk please~) CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 09:47:00 -
[10] - Quote
ThisIsntMyMain wrote:Will DestroyYou wrote:Concerns: 2. Dilation for players is different to lag, HOW???
Lag = UNCONTROLLED degradation of the server, missed requests ie the enemy guns fire and yours don't, modules stick, free cap for active hardeners, you dying on a blackscreen and never loading grid. TiDi = Everyone gets a FAIR SHARE of the server time. All requests are serviced - ie your guns fire at the same rate as everyone else, modules cycle slowly at the same rate as everyone else, no free cap for your active modules, slow loading into system but no dying on a black screen and waking in station. I.e. its completely different. No it doesnt "remove" lag but it does give us the best "fix" that you can expect. These are good words that deserve to be read again by anyone who's still unclear on why Time Dilation helps. CCP Veritas - Senior Programmer - EVE Software |
|
|
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 10:20:00 -
[11] - Quote
Schmell wrote:Ehm...why the user interface (camera, spitter etc) is slowing down in the first place? I thought time dilation is server side and should not affect strictly client-side things Because I want to convey the slowdown to the player. In essense, make space *feel* slower when it really *is* slower. Do note that it's only a couple UI elements plus the camera, and I might go back on the camera one. CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 11:39:00 -
[12] - Quote
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 - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 11:42:00 -
[13] - Quote
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 - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 11:51:00 -
[14] - Quote
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 - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
91
|
Posted - 2011.10.01 12:01:00 -
[15] - Quote
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
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 - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
91
|
Posted - 2011.10.01 12:07:00 -
[16] - Quote
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 - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
91
|
Posted - 2011.10.01 13:29:00 -
[17] - Quote
Abdiel Kavash wrote:Question for Veritas, can you make time go backwards?
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 - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
91
|
Posted - 2011.10.01 13:35:00 -
[18] - Quote
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 - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
93
|
Posted - 2011.10.01 23:44:00 -
[19] - Quote
Aineko Macx wrote:The one things that seems odd is that you plan on also reducing the client fps when time dilation kicks in.
I never have planned that and I continue to not plan that. Where'd you get the idea that I ever did plan to do that? CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P C C P Alliance
93
|
Posted - 2011.10.01 23:52:00 -
[20] - Quote
Zirse wrote:Question for you Veritas- can you describe the scaling procedure?
I've heard that at tidi: 10%, 10 RL seconds = 1 ingame second/tick.
Does that mean at 90% dilation we're looking at 1.5 minutes for each in game second? That seems abusrd?! Gettin' the numbers switched around. The way I'm describing it, normal speed is 100%, paused is 0%, 10% is, well, one tenth of the way from paused to normal speed.
So at 10% speed, 1 simulation second takes 10 wallclock seconds. At 90% speed, 1 simulation second takes 1.11 wallclock seconds. CCP Veritas - Senior Programmer - EVE Software |
|
|
|
CCP Veritas
C C P C C P Alliance
104
|
Posted - 2011.10.03 20:51:00 -
[21] - Quote
Lucas Quaan wrote:I have been looking around and can't find any confirmation on what will happen to the self destruct and log-off timers. Presumably they will follow the dilation and not be decoupled like structures, but I would like to hear a dev say that.
Please?
They will follow the dilation and not be decoupled like structures. CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Spitfire
C C P C C P Alliance
221
|
Posted - 2011.10.11 08:15:00 -
[22] - Quote
Imigo Montoya wrote:I would sure like to see this - making the UI seem glitchy probably isn't the ideal way to convey the message that time is behaving differently, certainly not camera control. I'm seriously impressed though, really liking what I'm seeing. At the same time I'm somewhat confused by the people hating on this. It seems to be coming from a place of ignorance so I wrote an article on EN24 that explains the fundamentals of what TiDi is actually trying to achieve in a way that I think is accessible to anyone (ie no Computer Science degree needed). I'd really appreciate your feedback Veritas, especially if my generalisation conflicts with how the specifics in this case actually work.
Hello,
CCP Veritas had some problems logging into the forums when I showed him this post, but he asked me to pass along that your summary is quite correct. Thank you for that article!
CCP Spitfire | Russian Community Coordinator @ccp_spitfire |
|
|
|
|