open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Introducing Time Dilation
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: [1] 2 3 4 5 6 7 8 9 ... : last (11)

Author Topic

CCP Wrangler

Posted - 2011.04.22 11:51:00 - [1]
 

CCP Veritas’ newest dev blog details his thoughts and ideas regarding bringing time dilation to fleet fights to help combat the War on Lag. Read all about it here.

Hoshi
Hedron Industries
Red Dwarf Racketeering Division
Posted - 2011.04.22 12:06:00 - [2]
 

Sounds very good, I do hope that you will include an indicator in the client telling at what speed it is currently running so I won't have to watch mod timers to figure it out.

Meissa Anunthiel
Redshift Industrial
Rooks and Kings
Posted - 2011.04.22 12:18:00 - [3]
 

Edited by: Meissa Anunthiel on 22/04/2011 12:19:12
Good blog.

Things that may need to be looked at for non-time dilatation are cyno fields (most certainly), siege and triage (most likely not).
aggression timers (for gate jumping and docking) may or may not be dilated, most likely yes (otherwise we won't be able to probe those lame people who logoffski to avoid death).

Azhpol
Gallente
Casa Del Wombat
Posted - 2011.04.22 12:23:00 - [4]
 

Excellent, but how you will you handle the surrounding systems? In other words, I get podded in a fight with 1600, go back to base, and immediately come back in a new ship(likely one called by the FC as a counter to the ships the enemy has). Would this not cause blobs to get worse?

Elissen
Amarr
Viziam
Posted - 2011.04.22 12:24:00 - [5]
 

What about the time that has been lost? You're not going to run at 200% to catch up with the rest of the universe (I hope). Since POS (modules) are directly connected to actions in the system, the entire POS should run slow motion as well. But what happens with fuel consumption & production?

And of course there is the problem of people entering a system in slow motion. A is chasing B and A jumps into a system that is running at 50%. Before the jump B was 10 seconds behind A, but after both jumped into the system, B will only be 5 seconds behind A. For leaving the system you have the opposite situation of course.

It is very interesting to think about all the benefits and potential risks this involves.

DaiTengu
Gallente
GoonWaffe
Goonswarm Federation
Posted - 2011.04.22 12:30:00 - [6]
 

see? the CSM most certainly works :)

and Meissa beat me to all the stuff I was wondering about as well.

I think cyno fields are going to be the most tricky, as they're simultaneously available both "in the ****" and outside of it.

Handling warpins/warpouts and people jumping in will probably be tricky as well.

CCP Veritas

Posted - 2011.04.22 12:32:00 - [7]
 

Originally by: Azhpol
Excellent, but how you will you handle the surrounding systems? In other words, I get podded in a fight with 1600, go back to base, and immediately come back in a new ship(likely one called by the FC as a counter to the ships the enemy has). Would this not cause blobs to get worse?


There are no plans to bring down time in any systems besides those with load. I don't consider the scenario you present to be any different than what happens today.

Originally by: Meissa Anunthiel
Things that may need to be looked at for non-time dilatation are cyno fields (most certainly), siege and triage (most likely not).
aggression timers (for gate jumping and docking) may or may not be dilated, most likely yes (otherwise we won't be able to probe those lame people who logoffski to avoid death).



I believe I agree with you on everything but cynos. That's a tough one as there's both an internal and external reason to care about the timer. Internally it's a timer for being able to kill the cyno-generating guy, externally it's a timer for being able to jump in. My opinion (which doesn't actually matter - it's design's call) is that the internal timer matters more. I'd love to read some arguments against me =)

Originally by: Elissen
What about the time that has been lost? You're not going to run at 200% to catch up with the rest of the universe (I hope). Since POS (modules) are directly connected to actions in the system, the entire POS should run slow motion as well. But what happens with fuel consumption & production?


There's no plan to "catch up" time - while going faster than 100% is pretty freakin' funny looking, there should be no reason for it.

I don't think POS production should be affected at all by time dilation. I can see arguments either way for fuel consumption...that's an interesting case.

Scatim Helicon
GoonWaffe
Goonswarm Federation
Posted - 2011.04.22 12:37:00 - [8]
 

Edited by: Scatim Helicon on 22/04/2011 12:37:15
At first glance this seems to work pretty much how I was hoping it would.(I'm posting this from the office while I'm supposed to be working so I skimmed the confusing technical bits Very Happy)

CCP Veritas best eritas

Destination SkillQueue
Are We There Yet
Posted - 2011.04.22 12:38:00 - [9]
 

Originally by: Elissen
What about the time that has been lost? You're not going to run at 200% to catch up with the rest of the universe (I hope). Since POS (modules) are directly connected to actions in the system, the entire POS should run slow motion as well. But what happens with fuel consumption & production?

And of course there is the problem of people entering a system in slow motion. A is chasing B and A jumps into a system that is running at 50%. Before the jump B was 10 seconds behind A, but after both jumped into the system, B will only be 5 seconds behind A. For leaving the system you have the opposite situation of course.

It is very interesting to think about all the benefits and potential risks this involves.


I don't think POS operations or timers in general should be dilated. That is clearly a thing you look at from a clock. On the other hand POS actions relevant to direct combat operations propably should dilate to keep the actual combat side balanced.

I don't think the entering/exiting system is a big issue. We are talking about systems under heavy load, so you can't load them like normal now. Either it takes more time, wiping out your advantage anyway or you blackscreen and likely die before even loading the system. Anyway since the new system would be more predictable it is also something people can take into consideration beforehand and adjust to. Basicly since it affects all equally you can consider it terrain in space, that will cause slight alterations in how people operate compared to normal conditions.

Seleene
Body Count Inc.
Pandemic Legion
Posted - 2011.04.22 12:41:00 - [10]
 

Edited by: Seleene on 22/04/2011 12:41:32

I was lost but that *****in' graph cleared things right up for me! Very Happy

Trebor Daehdoow
Gallente
Sane Industries Inc.
Posted - 2011.04.22 12:45:00 - [11]
 

I am looking forward to the public discussion on this. Getting TD right is crucial, and good feedback from the players on this important topic before a lot of code is written will, I think, save a lot of time and effort -- and perhaps set a precedent for getting feedback on other changes from the players at an early stage.

UI suggestions: there should be a readout of the current TD factor, and perhaps a running graph (ala the frame-rate graph). If you want to get crazy, red-shift the nebula background based on the TD factor. Very Happy

Meissa Anunthiel
Redshift Industrial
Rooks and Kings
Posted - 2011.04.22 12:48:00 - [12]
 

Originally by: CCP Veritas

Originally by: Meissa Anunthiel
Things that may need to be looked at for non-time dilatation are cyno fields (most certainly), siege and triage (most likely not).
aggression timers (for gate jumping and docking) may or may not be dilated, most likely yes (otherwise we won't be able to probe those lame people who logoffski to avoid death).



I believe I agree with you on everything but cynos. That's a tough one as there's both an internal and external reason to care about the timer. Internally it's a timer for being able to kill the cyno-generating guy, externally it's a timer for being able to jump in. My opinion (which doesn't actually matter - it's design's call) is that the internal timer matters more. I'd love to read some arguments against me =)



My argument to exclude cynos is that locally you'd want to be able to kill the cyno, but if it's opened without hostiles already on grid, there's no time dilatation and people can catch up, if it's opened while we're in Bullet Time, the 10 minutes in a situation with 1600 people on grid, slowed down or not, are more than enough to pop the guy.
The "time to jump into the system" doesn't need to be decelerated because the people jumping to the laggy system are out of the system and non-time dilated anyway. So it becomes a question of "give more chance for people to pop the guy" vs "give free cynos for half an our to people outside".

Need to think some more, but I still think that one shouldn't be dilated.

profundus fossura
Posted - 2011.04.22 12:48:00 - [13]
 

What will be the extent of the area effected by time dilation, will it be the grid the fight is on the system etc, the concern is if a fleet battle is taking 5 times longer than usual will this give one side an advantage in bringing in reinforcements and could this effect be deliberately produced for example buy whole fleet ungrouping weapons and lauching/recalling drones Very Happy

also if limited to grid how will items entering grid e.g. launched bombs, ships etc be managed. as for pos modules will online/offline timers be affected as would love to be able to bring replacement pos guns etc online faster/drop warp bubbles in middle of fleet

CCP Veritas

Posted - 2011.04.22 12:50:00 - [14]
 

Originally by: Trebor Daehdoow
UI suggestions: there should be a readout of the current TD factor, and perhaps a running graph (ala the frame-rate graph). If you want to get crazy, red-shift the nebula background based on the TD factor. Very Happy


I could see putting it in the monitor or some other such out-of-the-way place. I'm hoping that dilating certain UI elements (module animation, targeting spinny, things of the sort) will communicate it enough for standard uses so we don't have to do something ham-fisted.

Shasz
Angels of Anarchy
Posted - 2011.04.22 12:50:00 - [15]
 

I would lean towards dilating the cyno timer too.

Otherwise one could sneak into a system with a very pricey T3 cloaky ship, light cyno to bring in 600 of his close friends to rofl-stomp the local fleet, dilate time a wee bit in the process, and not fear losing his ship at all once his 10 minute cyno timer only had to deal with 1 minute or less of effective DPS.


Xynthiar
Gallente
Nulli Secunda
Posted - 2011.04.22 12:51:00 - [16]
 

Edited by: Xynthiar on 22/04/2011 12:52:13
Regarding cynos, correct me if I'm wrong, but if these ten minutes pass without the enemy fleet being able to kill the cyno in time, the cyno is still down, right? So it shouldn't really provide an advantage to either fleet..?

EDIT: I understand now that the issue at hand is more the enemy ship being incapacitated during the cyno; so how about simply incapacitate the ship for the dilated duration, while opening the cyno for the normal duration?

Killer2
The Arrow Project
Morsus Mihi
Posted - 2011.04.22 12:51:00 - [17]
 

Nice blog, thanks Veritas.

I for one am very keen to see this implemented. There's a few things that will need to be clarified as already mentioned above, but for the most part this is definitely a step in the right direction.

Good work!

Brannor McThife
Stimulus
Rote Kapelle
Posted - 2011.04.22 12:53:00 - [18]
 

I don't like how multi-threading was "fobbed off" like this. Working in multi-threaded environments on various platforms on various App Servers has shown that multi-threading in high-load environments is the #1 solution. I know it is probably not the easiest thing to do and the EvE engine is probably architected around this single-threaded model, but please don't go saying that it wouldn't buy you much.

-G

Scatim Helicon
GoonWaffe
Goonswarm Federation
Posted - 2011.04.22 12:55:00 - [19]
 

As far as cynos go, if the cynofield module is mounted on a ship in a dilated system, it should follow the same rules as any other ship modules. Since, as the blog states, the dilation mechanic can change incrementally and dynamically, I'd expect the effect would be too unpredictable to allow much in the way of player exploitation.

Veritas: is this somethig that would be always available? Or would it need to be manually activated in advance in the same way that nodes are petitioned for reinforcement currently?

CCP Veritas

Posted - 2011.04.22 12:59:00 - [20]
 

Originally by: Brannor McThife
I don't like how multi-threading was "fobbed off" like this. Working in multi-threaded environments on various platforms on various App Servers has shown that multi-threading in high-load environments is the #1 solution. I know it is probably not the easiest thing to do and the EvE engine is probably architected around this single-threaded model, but please don't go saying that it wouldn't buy you much.


I said it wouldn't buy us as much as most people think. Going say, 4-wide does not quadruple performance except in the embarrassingly easy cases. With communication overhead and the required locking behavior, we'd be lucky to see a 2x-3x performance gain going 4-wide.

For the effort it would take to get us there, and the ongoing effort of maintaining a multi-threaded codebase, it's not the best plan right now. It is inevitable that we'll do it some time though, that's where a lot of the hardware is going these days.

Vile rat
GoonWaffe
Goonswarm Federation
Posted - 2011.04.22 13:00:00 - [21]
 

As a player this owns. This does not fix lag, nobody ever said it did, it won't encourage more people to cram in system (people already cram until things break), but it'll let people play the game instead of watching a slide show or a blank screen.




Antihrist Pripravnik
Scorpion Road Industry
Posted - 2011.04.22 13:00:00 - [22]
 

Mass tests. We need a couple of those before deployment.

Interesting blog btw.

CCP Veritas

Posted - 2011.04.22 13:00:00 - [23]
 

Originally by: profundus fossura
What will be the extent of the area effected by time dilation, will it be the grid the fight is on the system etc, the concern is if a fleet battle is taking 5 times longer than usual will this give one side an advantage in bringing in reinforcements and could this effect be deliberately produced for example buy whole fleet ungrouping weapons and lauching/recalling drones Very Happy


First implementation will have all locations on the node dilated. For dedicated nodes that'll be only the system that's causing the load, but for shared nodes all systems on the node will be dilated. A couple other things need to fall into place before I can sanely have a per-system clock, but that's certainly desired.

Xaarous
Caldari
Woopatang
Primary.
Posted - 2011.04.22 13:13:00 - [24]
 

Edited by: Xaarous on 22/04/2011 13:22:10
Edit: UI-display-dilation comments repeated and already answered.

My 2 cents on the range/threshold: Change it no more often than ~5 or 10 seconds (edit: if you can help it - having it swing wildly from second to second might be weird but mass testing will be key), change as much as you want per change, and 10% of real-time is the lowest sane value I could imagine. But it somewhat depends on how persistent that state is - if it's really spikey at warp in and will recover, 10% is tolerable; 10% for more than a few minutes would get pretty painful. And let's be honest - it will still change the dynamic of the fight at anything below 50%, because it'll be MUCH easier to call and follow primaries, coordinate your movement, etc.

Xaarous
Caldari
Woopatang
Primary.
Posted - 2011.04.22 13:15:00 - [25]
 

Originally by: CCP Veritas
Originally by: profundus fossura
What will be the extent of the area effected by time dilation, will it be the grid the fight is on the system etc, the concern is if a fleet battle is taking 5 times longer than usual will this give one side an advantage in bringing in reinforcements and could this effect be deliberately produced for example buy whole fleet ungrouping weapons and lauching/recalling drones Very Happy


First implementation will have all locations on the node dilated. For dedicated nodes that'll be only the system that's causing the load, but for shared nodes all systems on the node will be dilated. A couple other things need to fall into place before I can sanely have a per-system clock, but that's certainly desired.


Probably obvious - but Jita shouldn't dilate the full range just to allow 5000 people in system. "Non-combat" dilation should have a less-aggressive threshold than fleet-fight-induced dilation (if possible). E.g. maybe 75% for "it's just busy here" vs. 25% or even slower for "Avatarageddon".

Kenpachi Viktor
Gradient
Electus Matari
Posted - 2011.04.22 13:19:00 - [26]
 

How are nodes currently threaded; one per grid bubble, or one per system?

Mashie Saldana
Minmatar
Veto Corp
Posted - 2011.04.22 13:24:00 - [27]
 

Originally by: Kenpachi Viktor
How are nodes currently threaded; one per grid bubble, or one per system?

Reinforced = 1 solarsystem per node
Default = lots of solarsystems per node.

Tork Norand
Mechanical Eagles Inc.
The Ancients.
Posted - 2011.04.22 13:26:00 - [28]
 

Good blog, I like the details. I think it will work.

I think a LOT of confusion can be simplified by doing a few things:
-- Designate a COLOR as the "Time Dilation Indicator". I'd suggest a green, but knowing some people are colorblind, maybe that should be something they can change. Anything and everything that's going to be affected by time dilation should then have that color used as the timing indicator. This includes module cycling, etc.
-- Add (as soon as possible) an overlay to the Capacitor gauge that shows the current Time Dilation rate. It should be 70% transparent and pulse on a set beat (unfortunately, every second makes the most sense) based on the dilation rate. The pulsing will be done 100% client side based off the dilation rate supplied by the server. This will provide instant feedback to the player on what a "current second in game" is.

Anything that comes up where it's questionable on "would this be effected?" should have the mechanics examined to look at how to change it so it's firmly on one side or the other. Example:
Perhaps the mechanics of the cyno field should be changed such that, once deployed, the field generator has the same resists of the deploying ship, but that ship can then leave the area. Someone warping to the field generator would have to do the equivalent of shooting down the same ship to break it, but the dilation becomes a non-issue since it's now "deployed". Also, use the nature of quantum mechanics to "bind" the ship to the cyno field....such that the ship cannot use anything but it's warp drive and sub-warp drives as long as the cyno is in effect. This then turns the cyno field point into a "deployed" item that has no player tied to it. People warping to it will either know that the time is dilated already (since they are in system) or that it is likely to since their pilot (who put it out there) can inform them of the fact. (Once dilation is in place, people should know that it will change as needed to keep true lag minimum.)

POSes should never be effected EXCEPT where a player interacts with it in the same way as they interact with their ship. So Production, reinforcement mode, fuel consumption, etc will remain the same at all times and work off a real clock. On the other hand, weapons and other player controlled aspects would be affected and have the same Time Dilation Indicator used. Again, keeping the player informed of the time dilation.

Monster Dude
Posted - 2011.04.22 13:28:00 - [29]
 

Hope you are going to make sure that it won't be possible to be same local players with and without dilation?
In that blog you mention be on same node, but for players more importnat be in same local/grid.
Hope with this change all players in system (or few systems) will be in same dilaid node? And when they leave that system they will leave dilation as well and won't remain slow when players in other locals are fast, right?

xttz
GoonWaffe
Goonswarm Federation
Posted - 2011.04.22 13:30:00 - [30]
 

Originally by: CCP Veritas
Originally by: Trebor Daehdoow
UI suggestions: there should be a readout of the current TD factor, and perhaps a running graph (ala the frame-rate graph). If you want to get crazy, red-shift the nebula background based on the TD factor. Very Happy


I could see putting it in the monitor or some other such out-of-the-way place. I'm hoping that dilating certain UI elements (module animation, targeting spinny, things of the sort) will communicate it enough for standard uses so we don't have to do something ham-fisted.

I'd be happy to see a small hour glass on screen when time is running at below a 1.0 ratio to normal. Put it up next to where the session change timer lives and make it optional as a client setting. It could then take rotate and refill accordingly once per time-dialated second - just like the old windows mouse icon.


Pages: [1] 2 3 4 5 6 7 8 9 ... : last (11)

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only