Pages: 1 2 3 [4] 5 6 7 8 9 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 22 post(s) |
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 09:40:00 -
[91] - 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 -
[92] - 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 |
|
Schmell
Russian Thunder Squad Against ALL Authorities
0
|
Posted - 2011.10.01 10:12:00 -
[93] - Quote
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 |
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 10:20:00 -
[94] - 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 |
|
Cedric deBouilard
PonyWaffe Test Alliance Please Ignore
29
|
Posted - 2011.10.01 10:27:00 -
[95] - Quote
CCP Veritas wrote: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. Go back on the camera one, bring it back to normal speed, but keep the rotating target reticule slow (most of us are used to see it slow down when lag / low fps occurs, so its almost natural to keep it slow)
but think of it this way, we'd love to fraps /record time dilated massive fights, and smooth camera movement would be much appreciated :) |
Will DestroyYou
0
|
Posted - 2011.10.01 10:31:00 -
[96] - Quote
CCP Veritas wrote: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.
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.
Do you honestly believe that people won't just bring more people, leading to dilation + server lag anyway? No matter what you do, alliances are going to max things out. Always have, always will. Unfortunately this is going to do increase people's need to NAP even more.
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.
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.
|
Daedalus II
Helios Research Combat Mining and Logistics
43
|
Posted - 2011.10.01 10:51:00 -
[97] - Quote
Cedric deBouilard wrote:CCP Veritas wrote: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. Go back on the camera one, bring it back to normal speed, but keep the rotating target reticule slow (most of us are used to see it slow down when lag / low fps occurs, so its almost natural to keep it slow) but think of it this way, we'd love to fraps /record time dilated massive fights, and smooth camera movement would be much appreciated :) How about having a switch in the menu so you can have the camera slowed down together with TiDi if you want to (to make epic videos with smooth camera moves for example) or at normal speed for the normal player that just want responsiveness in the battle. |
Tusko Hopkins
HUN Corp. HUN Reloaded
0
|
Posted - 2011.10.01 11:15:00 -
[98] - Quote
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? |
KFenn
Percussive Diplomacy
5
|
Posted - 2011.10.01 11:23:00 -
[99] - Quote
Great blog Veritas, +1.
Just a question though, why is everyone so bothered about the UI slowdown? Veritas has already said that it's only certain animations that are being slowed down, I can't imagine any things that the player interacts with directly will be less responsive.
The UI will play the same, it'll just look slower, which is the best way of showing dilated time IMHO. I'd rather have that than the little icon in the top-left. Commanding Officer of the Treacle Tart Brigade SLAPD Director |
Jackk Hammer
Peace Million Foundation Shadow of xXDEATHXx
1
|
Posted - 2011.10.01 11:33:00 -
[100] - Quote
I'm curious as to whether it will solve the problem of bombs travelling 100km+ or not moving at all in extreme lag. |
|
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 11:39:00 -
[101] - 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 |
|
Debir Achen
EVE University Ivy League
0
|
Posted - 2011.10.01 11:40:00 -
[102] - Quote
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? |
|
CCP Veritas
C C P C C P Alliance
90
|
Posted - 2011.10.01 11:42:00 -
[103] - 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 |
|
GeeShizzle MacCloud
4
|
Posted - 2011.10.01 11:50:00 -
[104] - Quote
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
90
|
Posted - 2011.10.01 11:51:00 -
[105] - 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 |
|
GeeShizzle MacCloud
4
|
Posted - 2011.10.01 11:54:00 -
[106] - Quote
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
Eye Of The Deceiver Means TO Oppression
0
|
Posted - 2011.10.01 11:55:00 -
[107] - Quote
They renamed LAG as Time Dilation and called it a feature? |
Malcom Dax
Blacklight Incorporated Broken Chains Alliance
5
|
Posted - 2011.10.01 11:56:00 -
[108] - Quote
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 |
|
CCP Veritas
C C P C C P Alliance
91
|
Posted - 2011.10.01 12:01:00 -
[109] - 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 -
[110] - 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 |
|
|
AngelFood
No C0de
0
|
Posted - 2011.10.01 12:13:00 -
[111] - Quote
Time dilation; Previously known as lag, now controlled by game ai. Great |
GeeShizzle MacCloud
4
|
Posted - 2011.10.01 12:43:00 -
[112] - Quote
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
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
4
|
Posted - 2011.10.01 12:43:00 -
[113] - Quote
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
Troll Hunters INC.
0
|
Posted - 2011.10.01 12:45:00 -
[114] - Quote
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, check mouse cursor movements. I didn't see any great thing there, just missile lag and an useless,stupid idea. |
Abdiel Kavash
Paladin Order Fidelas Constans
53
|
Posted - 2011.10.01 13:09:00 -
[115] - Quote
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? |
Jack bubu
GK inc. Pandemic Legion
22
|
Posted - 2011.10.01 13:21:00 -
[116] - Quote
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
ROC Deep Space
0
|
Posted - 2011.10.01 13:25:00 -
[117] - Quote
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
Tactical Nyan Cat Attack Force OMNIMODUS ALLIANCE
7
|
Posted - 2011.10.01 13:29:00 -
[118] - Quote
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). |
|
CCP Veritas
C C P C C P Alliance
91
|
Posted - 2011.10.01 13:29:00 -
[119] - 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 -
[120] - 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 |
|
|
|
|
|
Pages: 1 2 3 [4] 5 6 7 8 9 :: one page |
First page | Previous page | Next page | Last page |