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

Author Topic

Ranger 1
Amarr
Ranger Corp
Posted - 2011.04.22 16:59:00 - [91]
 

Originally by: Bagehi
Originally by: ShipSpinner
How will capitals jumping out of a system work?

Example: My capital/supercap/whatever is in system X functioning at, say, 10% speed. I'm trying to GTFO. My buddy/alt/new best friend lights a cyno in system Y, which is dead empty and running at 100%. His cyno cycle time is normal, no matter how cynos are affected inside the dialation. I issue the jump command.

If, due to time dialation, the jump command take longer to come up than his cyno field will last, what happens? does the jump fail, trapping me and wasting liquid ozone? If it succeeds, can my buddy let the cyno drop and gtfo to the next system on my jump route before I emerge from jump? Probably the worst option is that caps jumping out should get priority and ignore time dialation, for obvious reasons.

Time dialation itself sounds like a very good idea, but there's a lot that has to be considered in how a dialated system will work with the rest of the game.

Also, I don't envy you guys wading that deep in to the fundamental code that powers EVE. I don't expect we'll see any of this even in testing for at least a year even if you guys work on nothing else. Good luck, Gridlock.

This is a really good question. Another one is the waiting on the gate to come in. Those timers can have you sitting vulnerable on an entrance gate for 5-10 minutes already. I worry a little about what will happen with time dilation. Perhaps it is time to change the jump mechanic so it isn't one node handing players off to the next node. Once they hit jump, that ship shouldn't be sitting there, just like that ship shouldn't be sitting on the other side waiting for the server-client communication to resolve. Taking care of those problems would likely reduce a fair amount of animosity from players towards customer support.



In the situation of the Cap ship wanting to jump out, I would imagine that once the button is clicked to jump (assuming the cyno was up in the distant system at the time of the click) the process is initiated and when it's turn in the que of commands comes up the jump will happen, regardless of whether the cyno is still up or even if the cyno ship is even still in that system.

Of course, even if 30sec later the cyno ship reports "Abort, abort, local is filling" at that point it is too late and you are committed to the action.

In the case of waiting at a gate to jump in or out of a TD system, the commands that happen to complete a jump would be processed a according to the TD (or lack thereof) of the system handling those commands. Jumping into a TD system, your command to jump would happen immediately, but the hand off process could take some time to complete. Likewise, jumping out of a TD system, it could take a while for the initial command to be processed but once you are handed off the rest of the process happens normally.

Ideally, there would be a transitional state between being in one system before appearing in the other. An "In Gate Transit" state (with a neat graphic of course) similar to what you see when in warp. In this state you are in neither system, and can not be attacked. You do not come out of this state until you are fully loaded in your destination system.

Of course, jumping out of a TD system would not benefit as much... as you would still be sitting there waiting for your original jump request to be recognized in the que. But it would solve the issue of people appearing in a TD system to others and able to be shot, yet unable to see the system or move yet at their end.


War Kitten
Panda McLegion
Posted - 2011.04.22 17:02:00 - [92]
 

Originally by: aKille's 10Don

If it takes longer to blow up that ship it takes longer to need replacements. Which means it takes longer to sell the ship that is manufactured. Team Gridlock may be in charge of fixing lag but their changes need to be balanced with the rest of the game.


Really? This is your best shot at arguing against time dilation, because it'll take longer to create the demand for a blown up ship to be replaced?

Originally by: aKille's 10Don

If fleet fights are the poster child for Eve why is it that only 11%(could be higher but not more than 20%) of the player base is in Null-sec? It may be that large fleet fights bring more news to sites like Massively but how does that make it the poster child?


I'm sorry, you must be new here. This isn't a game about shooting little red npcs for isk, and where battles between 7 or 8 ships sometimes create market demand for new ships.

This is Eve. Where epic fleet battles can crush or create entire economies, and decide the fates of hundreds or thousands of players in alliances at once.

If you don't aspire to be one of those 11%, then GTFO and go whine in a thread where the development team actually works on the things you care about, and leave this one to the big kids.


Megan Maynard
Minmatar
Navigators of the Abyss
Posted - 2011.04.22 17:04:00 - [93]
 

Let me get this right....
In the heat of a large fight we are getting BULLET TIME??????


Absolutly fantastic idea CCP, I'd love to have 2-3 more seconds to think about actions in a tiny ass frigate during a fight.

Ranger 1
Amarr
Ranger Corp
Posted - 2011.04.22 17:22:00 - [94]
 

Originally by: Xaarous
Edited by: Xaarous on 22/04/2011 16:52:11
Originally by: Ranger 1
Edited by: Ranger 1 on 22/04/2011 16:19:50
People seem to think that TD will make battles last longer. In fact, compared to the status quo, TD affected battles will actually proceed faster as the game won't hang/black screen. Also players will be more entertained by a battle that moves in slow motion as opposed to a game that stops entirely or goes black.

A couple of pertinent questions:

1: How is speed affected by TD?
Will the ship slow down proportionately, thus becoming easier to track?

Or will a ship maintain normal speed and simply be trickier to control due to the delay in the pilots commands being reflected in the ships movement?

2: Under the current missile mechanics, how will this affect a Missiles flight time?

Could this possibly have the unforseen benefit of actually making missiles more viable in comparison to turret ships in long range combat as the delay in applying damage to target due to flight time may be altered?

3: I know that a delay requiring cynos to "spool up" before allowing the actual jump has been considered. Will TD solve this issue by it's very mechanics, or make their implementation mandatory due to TD often not starting until AFTER the initial jump in of caps?

If TD affects the cyno ship and it's cyno, is it preferable for the waiting fleet to have to wait longer to jump in? (I personally think so)

4: Will the ability to jump out of a TD system and recharge shields/repair more quickly than they could if they stayed in the TD system considered a problem, or as an encouragement for fleets to split up and spread out on both sides of the engagment?

If it is considered a problem, will the TD affect be incrementally implemented in surrounding systems?


I'm sure a multitude of issues will be resolved simply because everyone in system will be affected equally, it's the issues that affect events in other connected (via gate or jump bridge) that will be the most tricky.


Not quite the right way to look at it. In Time Dilation, the definition of a second is what's changing. So you perceive a ship going 500 m/s as going some % slower; but a gun that tracks at .015 rad/sec *also* slows by the same %. Net result, no change to accuracy/tracking issues. Same for missiles - the explosion propagates at the same % slower as the ship's perceived velocity changes.

If the TD rate is changing from second to second, I could see manual ship control being tricky, but I doubt this will become a huge problem (it affects both sides equally, inty pilots of all alignments will have to adapt and they like that kinda thing anyway).

The rep-outside-TD area and jump to full-speed cyno seem to be the most interesting edge cases so far. It'll be VERY interesting to see if the prospect of getting out of TD changes fleet tactics (and if so, is it for the better). In theory it'll be self-correcting: As TD worsens, the engagement will "break up"; as that happens and the load spreads to multiple nodes, TD goes away, fleets blob up again, rinse and repeat. What's key there is that fun stuff is happening the whole time, just sometimes in slow motion.

As someone else said, that sounds a lot better than an indefinite black-screen...

(Edited for emphasis and formatting only)


Good point on the numerical values being constant for tracking and such, regardless of TD. Although there are instances where this is not as straightward as it seems.

However, and I could be wrong, but I don't believe that the reality of TD is that the definition of a second is what is really being changed. If the server clock, the actual amount of time a second takes is altered you run into a large number of issues when that server communicates anything outside of itself to the rest of the cluster.


Ranger 1
Amarr
Ranger Corp
Posted - 2011.04.22 17:28:00 - [95]
 

Very Happy
Ran out of space above.

I believe what is being altered is the lenth of time that a command/action actually takes in real time, not the length of the second itself.

That module that is supposed to activate for 1 second instead activates for 10 seconds, rather than the system clock being slowed down to 1/10th speed and then rubberbanding back and forth in relation to the clocks on other servers in the cluster.

This changes how certain things will behave, thus prompting most of my questions above.

Alexeph Stoekai
Stoekai Corp
Posted - 2011.04.22 17:29:00 - [96]
 

Proposal:

Time Dilation should be abbreviated as TiDi (pronounced "Tie-Die") to avoid conflict and confusion with existing nomenclature (TD = tracking disruption).
Wink

Gnulpie
Minmatar
Miner Tech
Posted - 2011.04.22 17:31:00 - [97]
 

Is time dilatation systemwide or only per grid?

The problem with time dilatation is that you cut down DPS and thus boosting buffer tanks a lot. Also your energy consumption per second is greatly modified while your amount of cap is still the same. All this changes gameplay! Not that this is bad, it could result in interesting new strategies - but still, have you thought about this too?


Originally by: CCP Veritas
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.


Why not?

If you allow some (random?) space phenomena to make time run faster for a (limited) period of time, then I think you would have introduced a very interesting new game element. Just imagine that time runs faster the closer you get to a singularity or something like that...

Please think also out of the box for interesting new gameplay with time dilatation!

Delta Jax
NixCraft
Posted - 2011.04.22 17:32:00 - [98]
 

Edited by: Delta Jax on 22/04/2011 17:34:12
Edited by: Delta Jax on 22/04/2011 17:33:42
Ok, maybe i'm missing something but.. let's talk about this in a technical aspect.

I applaud your determination to do more with less, but this is not the way. These bottlenecks your servers experience are caused by peaks in demand, not as in players but resources, and TD is only reducing your theoretical "combat" bandwidth. so if you attempting to curb demand.. you done it, at the expense of reducing the pew-pew per cycle

That only gets you so far..

If it takes 3x longer to do something people will bring 3x the numbers. That is just how users react to system changes, and I've seen it many times in the IT field.

But the truth of the matter is this: this is not what your user base wants, they want REAL TIME huge pew-pew.

CCP, you made a great game, it has some flaw's but most of us over look it as the overall is much better. But you haven't invested enough back into you servers/infrastructure in tune with capacity planning, so you may want to add another cluster or two, get some HP DL785's or something, to spread load.

But really, ask yourself, why is this really even an issue?

Yes, you can can the TD route, but remember you are changing a lot of the mechanics of the game itself in doing so.. but your not addressing your true problems.

aKille's 10Don
Posted - 2011.04.22 17:34:00 - [99]
 

Originally by: War Kitten

I'm sorry, you must be new here. This isn't a game about shooting little red npcs for isk, and where battles between 7 or 8 ships sometimes create market demand for new ships.

This is Eve. Where epic fleet battles can crush or create entire economies, and decide the fates of hundreds or thousands of players in alliances at once.

If you don't aspire to be one of those 11%, then GTFO and go whine in a thread where the development team actually works on the things you care about, and leave this one to the big kids.




Wow, thats a troll. 360,000 subscriptions and everyone of them must be in or strive to be in 0.0? Eve is a sandbox and 0.0 is just one small (11% is small) part of the game.

It must really bother you that not everyone believes the universe surrounds your game play to lash out like that.

I truly hope that IF they do manage to implement time dilation, they are sure to look at all aspects of it. After all, The Mittani is correct in that "What happens in 0.0 can affect Empire"

War Kitten
Panda McLegion
Posted - 2011.04.22 17:41:00 - [100]
 

Originally by: Ranger 1
Very Happy

I believe what is being altered is the lenth of time that a command/action actually takes in real time, not the length of the second itself.

That module that is supposed to activate for 1 second instead activates for 10 seconds, rather than the system clock being slowed down to 1/10th speed and then rubberbanding back and forth in relation to the clocks on other servers in the cluster.

This changes how certain things will behave, thus prompting most of my questions above.



It's the game clock that 1s changes definition, obviously. Not the real system clock.

The point is valid that those things shouldn't be overlooked in testing, but they also shouldn't be a problem the way the change is being described.

Lord Zim
Goonswarm Federation
Posted - 2011.04.22 17:44:00 - [101]
 

Originally by: CCP Veritas
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.

How likely would it be to rearchitect the code so that things like missiles and drones etc would be on a player process instead of a solar system process? I assume that if it was implemented it could scale much better (by virtue of spreading the load across multiple nodes) but it would mean tons of communication overhead and potential sync issues.

What I'm wondering is if it has been considered, and rejected. I kind of hope it has, so I can stop thinking about it.

War Kitten
Panda McLegion
Posted - 2011.04.22 17:47:00 - [102]
 

Originally by: aKille's 10Don

Wow, thats a troll. 360,000 subscriptions and everyone of them must be in or strive to be in 0.0? Eve is a sandbox and 0.0 is just one small (11% is small) part of the game.

It must really bother you that not everyone believes the universe surrounds your game play to lash out like that.


No, it bothers me that you came whining about faction wars, incursion attendance, and the economy, in a thread devoted to working on lag and system performance.

If it makes you feel better, I also pick on the loons that whine about fixing lag in new feature threads on occasion.


Forest Hill
Posted - 2011.04.22 18:02:00 - [103]
 

Edited by: Forest Hill on 22/04/2011 18:02:36
Any ideas what happens around DT? I expect a dilated node to run in sync with the rest of the cluster again when it's brought back up after dt, so is a bit of time being 'disappeared' on the dilated node?

From a gameplay point of view, triggering TD right before DT could be a nice trick to achieve some result - ie prevent a ship from exploding before dt or some such.

The mass tests are going to be very interesting :D

Ranger 1
Amarr
Ranger Corp
Posted - 2011.04.22 18:04:00 - [104]
 

Edited by: Ranger 1 on 22/04/2011 18:06:40
Originally by: War Kitten
Originally by: Ranger 1
Very Happy

I believe what is being altered is the lenth of time that a command/action actually takes in real time, not the length of the second itself.

That module that is supposed to activate for 1 second instead activates for 10 seconds, rather than the system clock being slowed down to 1/10th speed and then rubberbanding back and forth in relation to the clocks on other servers in the cluster.

This changes how certain things will behave, thus prompting most of my questions above.



It's the game clock that 1s changes definition, obviously. Not the real system clock.

The point is valid that those things shouldn't be overlooked in testing, but they also shouldn't be a problem the way the change is being described.


With respect, whether you call it the game clock or system clock, the point still stands.

Case in point:

My Drake blob fires a volley of missiles at a target.

Either my missiles appear to travel in slow motion, take 10X longer to get to their target, and all things remain equal.

Or once the command to fire takes place all missile fire and fly to target at their normal (appearing) speed doing their damage. In this example the missiles likely applied their damage before the next volley of turret fire occured (from those laggarts in the fleet that brought the wrong ships Very Happy) This has mitigated some of the drawbacks to using missiles in a longer range fleet conflict (delayed damage). Granted, your next volley won't go off any quicker than the turret users, but your damage got there and was applied during 1 volley of fire from them, rather than several.

It all depends on exactly how the TD effect is occuring and what it is and is not affecting.

Activities such as flying a fast interceptor, or even a hack that is relying to some extent on speed tanking and manuvering to specific ranges quickly will be dramatically affected by how this is handled. If everything is in slow motion, no biggie. If only how often commands, such as change direction, are affected by the TD effect and not the actual speed of the ship in real time... things become very tricky very quickly.

Either way, people better not be "click happy" when under TD effects. Since commands will be in a que waiting their turn, the person that gives several commands while waiting is going to be trapped in that sequence of events longer than his companions that take a more "minimalistic" approach and make each click count.

aKille's 10Don
Posted - 2011.04.22 18:06:00 - [105]
 

Originally by: War Kitten


If it makes you feel better, I also pick on the loons that whine about fixing lag in new feature threads on occasion.




Then I shall attempt to bow out...

Herschel Yamamoto
Agent-Orange
Nabaal Syndicate
Posted - 2011.04.22 18:11:00 - [106]
 

Re cynos, I say dilate. Getting a long cyno for people to jump into a battle with is less of an issue than letting a ship survive lighting a cyno because it's only up for 30 seconds(if only because it probably won't survive the cyno timer if the system's that laggy).

Originally by: aKille's 10Don
Honestly, I'm still confused on why there is so much time being placed upon this?

Last I heard only 11% of the player base was in Null. I've heard the argument that Null helps push the Empire economy but if battles take 10x longer due to time dilation wont that just stagnate the entire economy?

Wouldn't fixing Faction Warfare or increasing Incursion attendance be more appropriate to improving the economy before we go and stagnate it with something like time dilation?


Much like your namesake, you are the critical flaw in this otherwise very awesome thread.

Originally by: Dwindlehop
Would Sunday afternoon in Jita be subject to time dilation? Or is it only certain kinds of server load that will trigger the dilation?


Jita runs more or less lag-free at present. Even if they decided to go for noncombat dilation, there wouldn't be much need for it. Also, what sort of dilation could you do? It's not like you have to wait on your market check to finish its 30-second cycle.

Jonathan Malcom
Gallente
Test Alliance Please Ignore
Posted - 2011.04.22 18:12:00 - [107]
 

Edited by: Jonathan Malcom on 22/04/2011 18:16:57
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 personally would prefer something ham-fisted. I want a digital indicator in the top right hand corner of my screen that gives the percentage of dialation. Giving the player more information is never a bad thing, in my opinion.

Also, please please PLEASE slow down effects in a dialated environment. Explosions and turret effects and energy effects going in slow-mo would move this from "mildly inconveniencing" to "Matrix bullet-time dog-fight ****ing awesome."

Edit: Forgot to voice my support. Excellent idea. From someone who regularly engages in large-scale fleet combat, this is a fantastic change and will make the entire process much more enjoyable. Make it so.

Ranger 1
Amarr
Ranger Corp
Posted - 2011.04.22 18:13:00 - [108]
 

Originally by: aKille's 10Don
Originally by: War Kitten


If it makes you feel better, I also pick on the loons that whine about fixing lag in new feature threads on occasion.




Then I shall attempt to bow out...


Just remember, TD will affect all aspects of EVE that experience lag... not just null sec fleet battles.

This would include battles between warring corps in high sec (often in high traffic, laggy systems), Incursions, FW, even ratting or missioning in little traveled systems that don't have much in the way of server resources devoted to them under normal circumstances.

So yes, this affects you too. These are other reasons why CCP is devoting resources to this quasi-solution. Lag can hit anywhere, anytime, whenever the normal system load is exceeded.

Xaarous
Caldari
Woopatang
Primary.
Posted - 2011.04.22 18:21:00 - [109]
 

Originally by: Ranger 1

Good point on the numerical values being constant for tracking and such, regardless of TD. Although there are instances where this is not as straightward as it seems.

However, and I could be wrong, but I don't believe that the reality of TD is that the definition of a second is what is really being changed. If the server clock, the actual amount of time a second takes is altered you run into a large number of issues when that server communicates anything outside of itself to the rest of the cluster.



You're right - it's more accurate to say "the tick rate of *this node* (actual scope TBD) is being un-bound from the real-time 1-tick-per-second clock". It sounds like most things will still happen per-tick, with ticks happening at a variable rate <= 60/minute; while some things like POS fuel cycles will stay on the 'master' clock which is ticking 1/sec. At this point I think we're in vehement agreement. :)


Xaarous
Caldari
Woopatang
Primary.
Posted - 2011.04.22 18:28:00 - [110]
 

Originally by: Gnulpie
Is time dilatation systemwide or only per grid?

The problem with time dilatation is that you cut down DPS and thus boosting buffer tanks a lot. Also your energy consumption per second is greatly modified while your amount of cap is still the same. All this changes gameplay! Not that this is bad, it could result in interesting new strategies - but still, have you thought about this too?


Originally by: CCP Veritas
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.


Why not?

If you allow some (random?) space phenomena to make time run faster for a (limited) period of time, then I think you would have introduced a very interesting new game element. Just imagine that time runs faster the closer you get to a singularity or something like that...

Please think also out of the box for interesting new gameplay with time dilatation!



Respectfully, go back and read the devblog again until you actually 'get it'. They're not stretching weapon timers while leaving the rest of the system alone (!!!), they're slowing the entire affected area (exact scope TBD) down. "Bullet Time" really is the way to think about this, with a few limited exceptions around things like POS fuel usage and possibly cynos, etc.

++SupportCount on the 'slow EVERYTHING down' - including animations, explosion FX, etc. if it's at all feasible. It'll give people more time to enjoy the visual aspects of the carnage, maybe even look at actual ship hulls instead of icons and HP bars... (gun-cam view on a combat drone still MWDing towards the target can be LOTS of fun)

War Kitten
Panda McLegion
Posted - 2011.04.22 18:33:00 - [111]
 

Originally by: Ranger 1

Case in point:

My Drake blob fires a volley of missiles at a target.

Either my missiles appear to travel in slow motion, take 10X longer to get to their target, and all things remain equal.



Yes, that.

As I said, your point is valid, these things should be considered. But rereading the devblog...

Quote:

A large majority of the load in large engagements is tied to the clock - modules, physics, travel, warpouts, all of these things happen over a time period, so spacing out time will lower their load impact proportionally.



...would indicate that interceptors and missiles and things flying around in space will be affected by the dilation - not just the queue of commands sent by the client.

Stafen
The Workers Union
Posted - 2011.04.22 18:38:00 - [112]
 

Originally by: aKille's 10Don
Honestly, I'm still confused on why there is so much time being placed upon this?

Last I heard only 11% of the player base was in Null. I've heard the argument that Null helps push the Empire economy but if battles take 10x longer due to time dilation wont that just stagnate the entire economy?

Wouldn't fixing Faction Warfare or increasing Incursion attendance be more appropriate to improving the economy before we go and stagnate it with something like time dilation?


Well I think the problem you are seeing is due to the "silent majority" not voting for the CSM and thus not having a loud voice.

The CSM council members are all in 0.0 alliances (http://wiki.eveonline.com/en/wiki/Members_of_the_sixth_CSM)

I suggest you run for CSM and voice what you think 89% of the EvE population want.

I am of the option that 0.0 fixes are what the players want as CSM members are all from 0.0, the votes have been counted. People who did not vote now pay the price for not voting by being the "silent majority".

Dorian Wylde
Posted - 2011.04.22 18:44:00 - [113]
 

Sadface at all the people who think this will affect game mechanics like tracking and missiles.

Razzeil Velendio
Posted - 2011.04.22 18:52:00 - [114]
 

what i would like to know is, Even if time dilation would assist in removing lag, What if due to something going wrong, or a bug, or some non server related lag, how would a player notice it if they have been slowed down?

would ccp have add some sort of lag/ping to the ui so people who are Time dilated , know if something is not working as it should if the player cannot perceive the lag?



Ranger 1
Amarr
Ranger Corp
Posted - 2011.04.22 18:54:00 - [115]
 

Originally by: Dorian Wylde
Sadface at all the people who think this will affect game mechanics like tracking and missiles.


But you see, depending on how this is implemented, it could. If it affects the "tick rate" of the system as a whole (with some exceptions) then no it would not. If it simply affected how the que of commands was handled, then (particularly in the case of missiles) then it certainly would.

That said, I am in agreement that the former is likely the case, although that raises other issues.

Regardless, clarification is a good thing. Assuming is usually not. One of the main points of this thread is to explore options and to bring up problematic area's that many not be obvious before coding commences.

Stafen, you fail to realize that lag affects many, many people in high sec as well. It may not affect you personally, depending on what you like to do in EVE, but large scale PVP as well as large scale PVE engagements are affected by lag in Empire all the time. I would say the majority has, indeed, spoken.



mkint
Posted - 2011.04.22 18:57:00 - [116]
 

Originally by: CCP Veritas
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.


What about a warning before jumping into a time dilated system? Perhaps add an interruptable jump delay. This would also give a chance to establish a "max load" on a system so dilation will never reach that 0.1% dilation.
Quote:


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 =)


Would it be possible to dilate the module (making the cyno ship easier to kill) but run the beacon itself real time (meaning no benefit to out-of-system people)?
Quote:


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.

I would argue that POS's should function as described in the dev blog. Shield, rate of fire, should run on dilated time. Dilating fuel consumption (including stront) and POS cycles would mean going directly against what was said in the blog about lagging out a system to control date/time timers.

Stafen
The Workers Union
Posted - 2011.04.22 19:03:00 - [117]
 

Originally by: Ranger 1

Stafen, you fail to realize that lag affects many, many people in high sec as well. It may not affect you personally, depending on what you like to do in EVE, but large scale PVP as well as large scale PVE engagements are affected by lag in Empire all the time. I would say the majority has, indeed, spoken.



My point was as you said "the majority has, indeed, spoken". I was just trying to silence "aKille's 10Don" argument with hard numbers (the CSM votes).

PVE lag in mission systems might soon be solved by simply removing agent quality and division and thus making more agents worthwhile so spreading people around.

Not sure if insurrection systems are at the point that lag severely effects gameplay, but they can easily be always placed on a dedicated node and that might be enough (do you get 500+ people in them?)

Please point out any other large scale PvE encounters I missed, cannot think of anymore.

Shobon Welp
GoonFleet
Band of Brothers
Posted - 2011.04.22 19:04:00 - [118]
 

It would be funny as hell if packed mission hubs started getting dilated and the farmers suddenly found their isk/hr ratio dropping as a result

Ardamalis
Caldari
Deep Core Mining Inc.
Posted - 2011.04.22 19:16:00 - [119]
 

Edited by: Ardamalis on 22/04/2011 19:25:11

Originally by: Xynthiar
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?


I like this idea. ^^

As far as timers go: if it affects combat directly, then it should be dilated. Other things such as POS production, blueprint manufacturing, etc should not be dilated. Reinforcement timers should not be time dilated also. These things are designed to be predictable (i.e. you will always know at what eve time it will be ready regardless of circumstances).

To sum things up: if predictability is intended as part of the mechanic in a given system, then no time dilation.

Originally by: Shobon Welp
It would be funny as hell if packed mission hubs started getting dilated and the farmers suddenly found their isk/hr ratio dropping as a result


I for one would look forward to that. It would encourage people to spread out and move around.

Adapt or die Twisted Evil


--------------

Big question (sorry if its been asked) but will Jita be subject to constant time dilation if too many people are inside at once? I guess it really wouldn't matter though if the market was unaffected by time dilation.

Ranger 1
Amarr
Ranger Corp
Posted - 2011.04.22 19:17:00 - [120]
 

Edited by: Ranger 1 on 22/04/2011 19:17:22
Originally by: Stafen
Originally by: Ranger 1

Stafen, you fail to realize that lag affects many, many people in high sec as well. It may not affect you personally, depending on what you like to do in EVE, but large scale PVP as well as large scale PVE engagements are affected by lag in Empire all the time. I would say the majority has, indeed, spoken.



My point was as you said "the majority has, indeed, spoken". I was just trying to silence "aKille's 10Don" argument with hard numbers (the CSM votes).

PVE lag in mission systems might soon be solved by simply removing agent quality and division and thus making more agents worthwhile so spreading people around.

Not sure if insurrection systems are at the point that lag severely effects gameplay, but they can easily be always placed on a dedicated node and that might be enough (do you get 500+ people in them?)

Please point out any other large scale PvE encounters I missed, cannot think of anymore.


Sorry, the way your post was worded it looked like you were inferring that since the CSM has a large percentage of reps from 0.0 that currently the issues important to high sec dwellers was being ignored in favor of the wants of the smaller population in 0.0.

As far as large scale PVE the primary group having lag issues was indeed the Incursion runners, especially when Incursions first came into being. However most any PVE activity can be affected seriously by lag if in a high population system, or is on a node that is shared by a system under heavy load. Check any thread in which people are complaining that they can't get their ship petitioned successfully when they died due to lagging out. Smile

The most obvious example of lag affecting PVP in Empire (compare loss reports in Empire and 0.0 sometime, you may find it surprising) is Faction Warfare and of course any system where corps that are at war are fighting. Faction Warfare in particular has been plagued by this, and is a contributing factor to many groups dropping it (along side flaws in the game mechanics themselves).


Pages: first : previous : 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