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: first : previous : ... 3 4 5 6 [7] 8 9 10 11 : last (11)

Author Topic

Illwill Bill
Svea Crusaders
Posted - 2011.04.25 12:25:00 - [181]
 

I, for one, look forward to the epic battle videos this will result in.Cool

StarStryder
WISE OUTCASTS
Posted - 2011.04.25 14:29:00 - [182]
 

I haven't had time to read all of the comments, so my apologies if this has already been brought up.

Do this mechanism not have the potential to imbalance a combat scenario? For example:

1) A large fleet fight causes time dilation.
2) Pilots outside the system are unaffected.
3) Communication between pilots inside and outside the dilated system can communicate in real-time (out of game comms systems)
4) It follows that the defenders can gather reinforcements outside the dilated system at an accelerated rate as seen from inside the system.

Thinking about it, this may not be fair, but it may prove to discourage blobbing since the larger the blob, the more chance there is that you'll increase your opponent's ability to bring in timely reinforcements! Laughing

Knug LiDi
N00bFleeT
Posted - 2011.04.25 14:39:00 - [183]
 

Edited by: Knug LiDi on 25/04/2011 14:45:47
Originally by: Trebor Daehdoow


I will admit that it is amusing that manipulation of space-time may become a tactical option in EVE.


Forgive me, but in EVE with have THREE different methods for faster than light travel. Somehow space-time is tied in insane Gordian Knots already, and we seem to survive.

Myself, the idea of Bullet Time expressed by Gamma, will be awesome. As others have said, time to think, time to consider. It will make us god-like pod folks even more god-like when we can sit with our brains working 50% faster (gamma 1.5) than other mere mortals.

I would like to see, if possible, someone take that server load graph and apply a time-stretching mechanic and guestimate the gamma ranges. I would like to think that gamma could change smoothly, as opposed to wild swings.

It could be, that on a reinforced node, that we only see short periods of gamma in excess of 1.5 (wishful thinking, I know, but a gamma of two would represent the node having (nearly) twice as much resources to handle requests) but it would be a start. If gamma values approach 3 for extended periods (5-10 mins) that would be a little dull. Who knows, perhaps putting the node into a gamma of 1.2 before 100% utilization may make the whole thing better?)

Knuggles

[edited for epic quote fail]

Knug LiDi
N00bFleeT
Posted - 2011.04.25 14:50:00 - [184]
 

Oh yes,

And if the graphical effects are stretched out as well, it would be very cool to have the same happen to sound effects. The sound of 1400's booming away all distorted and slo-mo would be sharp.

heh - and for extra emphasis, introduce that same thing to EVE-voice.

'Nooooooooooo' - stretch out for 3 seconds . . .

Knug

Vincent Athena
Posted - 2011.04.25 16:41:00 - [185]
 

Originally by: StarStryder
I haven't had time to read all of the comments, so my apologies if this has already been brought up.

Do this mechanism not have the potential to imbalance a combat scenario? For example:

1) A large fleet fight causes time dilation.
2) Pilots outside the system are unaffected.
3) Communication between pilots inside and outside the dilated system can communicate in real-time (out of game comms systems)
4) It follows that the defenders can gather reinforcements outside the dilated system at an accelerated rate as seen from inside the system.

Thinking about it, this may not be fair, but it may prove to discourage blobbing since the larger the blob, the more chance there is that you'll increase your opponent's ability to bring in timely reinforcements! Laughing


This has been mentioned many times.

Remember, we already have a broken type of time dilation right now, called Lag. The issue you bring up is something that can already be exploited.

Trebor Daehdoow
Gallente
Sane Industries Inc.
Posted - 2011.04.25 21:36:00 - [186]
 

Originally by: Knug LiDi
Originally by: Trebor Daehdoow

I will admit that it is amusing that manipulation of space-time may become a tactical option in EVE.

Forgive me, but in EVE with have THREE different methods for faster than light travel. Somehow space-time is tied in insane Gordian Knots already, and we seem to survive.

Excuse me, but EVE is clearly a non-relativisitic universe. If the fact that space is a viscous fluid wasn't a dead giveaway, consider that in a relativisitic universe, a FTL drive is also a time-machine. If EVE was a relativistic universe, all of our grandfathers would have been retroactively assassinated by now -- in the case of certain people, multiple times.

Ergo, FTL travel in EVE manipulates space, but not time. QED. Twisted Evil

Vincent Athena
Posted - 2011.04.25 22:44:00 - [187]
 

Trebor, I read that link. I think Special provision 9.5.4 would serve the eve universe just fine. Make the "special reference frame" the frame in which the cosmic microwave background had no dipole moment, do some hand waving at Mach's principle, and we are good to go.

Trebor Daehdoow
Gallente
Sane Industries Inc.
Posted - 2011.04.25 23:30:00 - [188]
 

Originally by: Vincent Athena
Trebor, I read that link. I think Special provision 9.5.4 would serve the eve universe just fine. Make the "special reference frame" the frame in which the cosmic microwave background had no dipole moment, do some hand waving at Mach's principle, and we are good to go.

I obviously require a higher standard of inconsistency than you do, my good sir. Twisted Evil

quygen
Minmatar
Acting Neutral
Posted - 2011.04.26 11:48:00 - [189]
 

Very good, pretty planned out.

But if I read correctly this will work depending on server load. Sooo... This wil cause JITA to Dilate every Sundayevening al least till monday morning.

Or is this 0.0 only stuff?

Louis deGuerre
Gallente
Malevolence.
Posted - 2011.04.26 12:14:00 - [190]
 

Drop what you're doing and build this.

No, seriously, drop it ! Twisted Evil

CCP Veritas

Posted - 2011.04.26 13:14:00 - [191]
 

Originally by: quygen
Very good, pretty planned out.

But if I read correctly this will work depending on server load. Sooo... This wil cause JITA to Dilate every Sundayevening al least till monday morning.

Or is this 0.0 only stuff?


Any location node (server running space stuff) will be capable of being dilated. That said, Jita hasn't come close to 100% CPU since we changed inventory to use sets. Sooo...Jita will continue to be just fine.

Originally by: Louis deGuerre
Drop what you're doing and build this.

No, seriously, drop it ! Twisted Evil


But I'm building this...so I'm confused at if I should drop it or not!

Newbie Ned
Minmatar
Real Nice And Laidback Corporation
Posted - 2011.04.26 14:01:00 - [192]
 

Originally by: CCP Veritas
Originally by: quygen
Very good, pretty planned out.

But if I read correctly this will work depending on server load. Sooo... This wil cause JITA to Dilate every Sundayevening al least till monday morning.

Or is this 0.0 only stuff?


Any location node (server running space stuff) will be capable of being dilated. That said, Jita hasn't come close to 100% CPU since we changed inventory to use sets. Sooo...Jita will continue to be just fine.

Originally by: Louis deGuerre
Drop what you're doing and build this.

No, seriously, drop it ! Twisted Evil


But I'm building this...so I'm confused at if I should drop it or not!


What you doing on the forums then? Get building!!Wink

ps - nice plan

Darth Vapour
Posted - 2011.04.26 15:05:00 - [193]
 

Quote:
Any location node (server running space stuff) will be capable of being dilated.


So a busy mission hub could be slowed down and the income of the mission runner reduced ?

CCP Veritas

Posted - 2011.04.26 15:43:00 - [194]
 

Originally by: Darth Vapour
Quote:
Any location node (server running space stuff) will be capable of being dilated.


So a busy mission hub could be slowed down and the income of the mission runner reduced ?


Sure. Better than what's possible today.

Lan Staz
Posted - 2011.04.26 18:29:00 - [195]
 

Sorry if this has been answered already, but is there a way to determine which system is causing the largest load on a time-dilated node, and hence to provide an indication to players when they are slowed down by activities in another system that they happen to share a node with?

If I'm in a massive fleet fight then I'll understand why my modules are cycling slowly. If there's only a few people in system you might see a few "WTF?" reactions.

Dev Rom
Caldari
Masterminds Industries
Posted - 2011.04.26 19:56:00 - [196]
 

Originally by: Trebor Daehdoow
I will admit that it is amusing that manipulation of space-time may become a tactical option in EVE.


Good point too. Warping space-time tactically or because some influence made by so mani warp drive, jump drive, mwd and weapons fired inside a system, it's sci-fi meaningfull thing.
This space-time disruption could very well affect systems in a wide area (5-10 light years) ad different degree and can possibly be used tactically.

Glyken Touchon
Gallente
Independent Alchemists
Posted - 2011.04.26 20:26:00 - [197]
 

Hope it works.Very Happy

as to indicators on-screen: have an exact one in either the FPS graph or monitor, and a more prominent one (maybe also as a map option) based on bands (0-10% etc).

I would also consider the rate at which the server reverts to normal time after being dilated, so that the graphics don't get too jerky for people due to stop-start.

If this works and local is ever removed, people will still know a fleet has just jumped in because TiDi (or whatever) will kick in.

Bobro Koromyslov
Posted - 2011.04.26 22:11:00 - [198]
 

I just want to say that though I really like the idea of time dilation in general, I don't like the way it's going to be implemented - I mean that partial system slow-down when some timers still run at normal speed. I.e. I agree that it gives better player experience comparing to the current situation, but it doesn't solve one major problem - the problem of some players taking advantage over others due to a server lag. In fact I think it will be aggravated, I expect time travel exploits to propagate and flourish. IMO guys you shouldn't waste your time working on this semi-solution and go straight for the real one - slowing down all the timers in the time-dilated system/cluster, allowing it to go to the past and forcing people that jump in (both normally and by means of being podded) to wait until the clocks are synchronized. By clock synchronization here I mean a simple wait loop that ensures that time travel is not possible, i.e. if a player with system time 1:00 jumps into system that's at 12:55, the jump should take as much real time as needed for the target system clock to reach 1:00. Player experience can be improved by allowing us to cancel such lengthy jumps. Also note that this approach solves the problem of a cyno ship being destroyed in the past - when it's blown up, all the pending jumps are just canceled.

This all may sound complicated but in fact it's more logical (and hence simple) approach comparing to the partial slow-down one. I'm of course looking at it from user perspective here, I don't know how well it fits into existing code base, but I still think you should work in this direction or leave things as they are now.

P.S. 1) By time travel here I mean travels into the past; there is not much sense in restricting jumps into the future since they are safe.
2) This approach of course assumes that the clock, once slowed down, should at some point begin to run faster that normal so that it can come up with the real one. This also looks logical and shouldn't
impair user experience provided that there is an upper limit for the speed-up.

Spooks'em
Posted - 2011.04.27 05:14:00 - [199]
 

Edited by: Spooks''em on 27/04/2011 05:14:15
I am sorry I didn't see this blog last week.
That said.

...

Team Gridlock best gridlock.

Originally by: Scatim Helicon

CCP Veritas best eritas

<3

Veritas blog always delivers, always.

I very much appreciated and enjoyed the technical blogs you have done Veritas. I will continue to watch this with great interest. Also, some method of knowing what the time dilation is, I think, important. I don't think it has to be a strict readout, but there should be something at least as an option.

Xer Jin
Amarr
The Dex Initiative
Posted - 2011.04.27 07:23:00 - [200]
 

well ive read the dev blog from top to bottom and many of the coments page 1,2,3,4 & 7 and i have a prty good understading of what hapen when u mess with time mecanics. in any univers u create a time parodx the result is the univers is ripped to shreds and impodes and then resets it self vis-a-vis the big bang

the idea terifies me eve is gona rip its self to shreds and the servers gona go crital and melt down


Grukni
Posted - 2011.04.27 07:39:00 - [201]
 

Originally by: Bobro Koromyslov
I just want to say that though I really like the idea of time dilation in general, I don't like the way it's going to be implemented - I mean that partial system slow-down when some timers still run at normal speed. I.e. I agree that it gives better player experience comparing to the current situation, but it doesn't solve one major problem - the problem of some players taking advantage over others due to a server lag. In fact I think it will be aggravated, I expect time travel exploits to propagate and flourish. IMO guys you shouldn't waste your time working on this semi-solution and go straight for the real one - slowing down all the timers in the time-dilated system/cluster, allowing it to go to the past and forcing people that jump in (both normally and by means of being podded) to wait until the clocks are synchronized. By clock synchronization here I mean a simple wait loop that ensures that time travel is not possible, i.e. if a player with system time 1:00 jumps into system that's at 12:55, the jump should take as much real time as needed for the target system clock to reach 1:00. Player experience can be improved by allowing us to cancel such lengthy jumps. Also note that this approach solves the problem of a cyno ship being destroyed in the past - when it's blown up, all the pending jumps are just canceled.

This all may sound complicated but in fact it's more logical (and hence simple) approach comparing to the partial slow-down one. I'm of course looking at it from user perspective here, I don't know how well it fits into existing code base, but I still think you should work in this direction or leave things as they are now.

P.S. 1) By time travel here I mean travels into the past; there is not much sense in restricting jumps into the future since they are safe.
2) This approach of course assumes that the clock, once slowed down, should at some point begin to run faster that normal so that it can come up with the real one. This also looks logical and shouldn't
impair user experience provided that there is an upper limit for the speed-up.


+1

Forcing ppl jumping into a time dilated system to wait till clocks are synchronized is the way to go to avoid "time travel" exploits.

Vincent Athena
Posted - 2011.04.27 16:44:00 - [202]
 

Edited by: Vincent Athena on 27/04/2011 17:11:45
Edited by: Vincent Athena on 27/04/2011 17:10:41
Edited by: Vincent Athena on 27/04/2011 17:09:41
Originally by: Grukni


Forcing ppl jumping into a time dilated system to wait till clocks are synchronized is the way to go to avoid "time travel" exploits.


Actually it doesn't. It just gives the exploit opportunity to the other side.

"Lets lag out the system so they cannot jump in their reinforcements".

Edit: So if TD spreads it effects, those who do not want to see reinforcements have an advantage. If TD does not spread, those who do want reinforcements have an advantage. There is an issue either way. Sometimes you will be on one side, and sometimes on the other. No mater which way we go in the long run the advantages will average out.


So what do we do? I think we should just go with whatever is easiest to code. And that would be have TD effect just the node.

Edit 2&3: grammar

Brannoncyll
The Rip Tide
Posted - 2011.04.27 20:55:00 - [203]
 

Why not time dilate cynos but register the rate at which people are entering the cyno and reduce the rate at which they are spat out of the other end by the time dilation factor?

e.g.

1) Cyno is lit in system A with 50% time dilation.
2) 100 players jump through the cyno from system B in quick succession at a rate of 6 per second.
3) Spit out those 100 players in system A at a rate of 6 per second.

Bobro Koromyslov
Posted - 2011.04.27 21:16:00 - [204]
 

Originally by: Vincent Athena

Actually it doesn't. It just gives the exploit opportunity to the other side.

"Lets lag out the system so they cannot jump in their reinforcements".

According to CCP Veritas: "I do think, however, we'll have to put in a hard limit on how far we're willing to dilate; there's no sense having a system running at .1% time, since no one will be able to do much of anything and it'll just never go anywhere"
I.e. when the time dilation reaches some limit, the slow-down process stops and "normal" lags begin to appear => even if 100500 noob ships are thrown in by the defenders, the time difference between systems will still grow relatively slowly => everyone willing to jump in will be able to do so in a reasonable amount of time. Also don't forget that if reinforcements are forced to wait for, say, 30 min at some point, then they are actually late for that 30 min. It's just fair and logical.

Vincent Athena
Posted - 2011.04.27 23:57:00 - [205]
 

If we had some sort of anti time travel rule:

A fleet knows something is coming out of reinforced, so 3 hours early they jump to that system, time dilate it by a gamma of say 2 for 3 hours. The system is now 1.5 hours "in the past". Now after that 3 hours the defenders get home from work and try to come in to defend their stuff, but because of this "anti time travel" rule, they got to sit looking at a session change timer got an hour and a half while their stuff is blown up.

I think that we got to have it that when you jump into a time dilated system, you jump in just like any other jump.

CCP Veritas

Posted - 2011.04.28 00:15:00 - [206]
 

Originally by: Vincent Athena
If we had some sort of anti time travel rule:

A fleet knows something is coming out of reinforced, so 3 hours early they jump to that system, time dilate it by a gamma of say 2 for 3 hours. The system is now 1.5 hours "in the past". Now after that 3 hours the defenders get home from work and try to come in to defend their stuff, but because of this "anti time travel" rule, they got to sit looking at a session change timer got an hour and a half while their stuff is blown up.

I think that we got to have it that when you jump into a time dilated system, you jump in just like any other jump.


I'm inclined to agree. Jumping in/out of dilation is a bit odd, I'll grant folks, but I don't see a way around it that's not more odd/exploitable.

Bobro Koromyslov
Posted - 2011.04.28 06:48:00 - [207]
 

Originally by: Vincent Athena
If we had some sort of anti time travel rule:

A fleet knows something is coming out of reinforced, so 3 hours early they jump to that system, time dilate it by a gamma of say 2 for 3 hours. The system is now 1.5 hours "in the past". Now after that 3 hours the defenders get home from work and try to come in to defend their stuff, but because of this "anti time travel" rule, they got to sit looking at a session change timer got an hour and a half while their stuff is blown up.

I don't get you here. Do you say that in this situation attackers will have more time to destroy the POS? This is incorrect, the effective amount of time (measured in number of module cycles for example) they have is exactly the same as if there were no time dilation at all, POS effective reinforcement time is also exactly the same. So, if during 1.5h of defenders waiting the POS comes out of reinforced mode and is destroyed, then it would come out of reinforced mode and be destroyed anyway in normal situation (i.e. if there we no slow-down, the defenders would get home and discover that the POS is already blown-up).
As I've understood, the purpose of the time dilation is to mitigate the impact of lags on the game-play, the "anti-time travel" rule helps to achieve this. What you suggest is to allow defenders to obtain larger amount of effective time by slowing down the system. In this case time dilation serves another purpose - just to improve player experience in a slowed-down environment and to add some fancy time travel-related tactics to the game.

Originally by: CCP Veritas

I'm inclined to agree. Jumping in/out of dilation is a bit odd, I'll grant folks, but I don't see a way around it that's not more odd/exploitable.

The only possible exploit of "anti-time travel" rule that I see is intentionally slowing-down a system, so that the opponents have to quit the game due to RL business before the fight ends. This may be solved by restricting the possible time difference to a reasonable amount of time.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.28 08:29:00 - [208]
 

i would suggest looking into the real world physics of dilated time due to gravametric distortions to base TD off of.

...and yes before people jump on the "eve isnt an accurate representation of physics" band wagon, i do believe CCP do make a concerted effort to add a level of realism to keep the immersive nature of main game elements, something that i think should carry on!

and the whole issue of enemy fleets dilating time in a system where timers are ending soon is something that occurs already in one form or another, but is very very rarely taken advantage of. cant remember the last time i was dropped into a system to defend assets, only to lag out for an hour or so. maybe mid fight when successive counter hot drops occur.

with TD all it means is if you're defending assets you should make prior preparations to defend it. it only makes sense!
after all if you fail to prepare, then prepare to fail!

on the issue of cynos i believe cyno's lit in TD systems should have extended active times when being locked onto elsewhere. it makes logical sense to do so.
Every similar situation ive seen in science fiction when an outside observer views streamed moments affected by dilated time the moments are stretched and extended in duration. this should be the case with active cynos in a TD system.

CCP Veritas

Posted - 2011.04.28 12:03:00 - [209]
 

Originally by: Bobro Koromyslov
The only possible exploit of "anti-time travel" rule that I see is intentionally slowing-down a system, so that the opponents have to quit the game due to RL business before the fight ends. This may be solved by restricting the possible time difference to a reasonable amount of time.


That leads me to believe you didn't grasp Vincent's post. It boils down to being able to shift a timer forward, which is Not Cool. Allow me to put some numbers on it.

Alliance A owns a station which is under attack by Alliance B. Its reinforcement timer comes out at 20:00. Alliance A calls a CTA for 19:00 so they can clear out baddies before the timer comes out.

Alliance B, being clever and nasty and all things dishonorable, shows up at 12:00 and does silly things to overload the server, dilating time down to 50% of normal time. They're a very determined bunch of people, so they keep this up until 20:00.

At 19:00, Alliance A's fleet jumps, expecting to arrive an hour prior to their timer expiration - plenty of time. However, since the server's been running at half time since 12:00, a total of 7 hours, your idea would have them waiting to jump for 3.5 hours, completing at 22:30. That allows Alliance B to have two and a half hours wallclock of time to take down the station completely uncontested.

In order for Alliance B to arrive in system at 19:00, as they expected to do, they would have had to initiate that jump at 16:40, effectively moving their reinforce timer up by a few hours. This is Not Cool.

Yeep
GoonWaffe
Goonswarm Federation
Posted - 2011.04.28 12:42:00 - [210]
 

I think theres a general misconception that time dilation would introduce a delay between performing an action and seeing that action start, and that this delay would increase the longer the system had been under dilation whereas actually the goal is to have actions start immediately but take longer to complete.

So in Eve terms, when you fire a gun it always fires immediately but under time dilation you have to wait longer until it can fire again. When you double click in space you start moving immediately but under time dilation it takes you longer to get where you are going.

From a player's perspective its like bullet time where you just see everything happening in slow motion rather than an actual slowing of time so theres no catching up afterwards. I think a lot of the confusion is coming from the fact that the technical implementation of this is to slow time and some official clarification would be useful there.


Pages: first : previous : ... 3 4 5 6 [7] 8 9 10 11 : 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