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

Author Topic

Daneel Trevize
Gallente
Posted - 2011.04.23 11:07:00 - [151]
 

Originally by: Kyoko Sakoda
I'd like to second the idea of getting a server notification on dilation factor as a UI element. Make it one line of text with a clock icon, and put it somewhere inconspicuous like around the session change timer or what not, but it needs to be there.
This. So obvious and yet :ccp:

Originally by: Alexeph Stoekai
Proposal:

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

Epic t-shirt win opportunity detected

Levitikon
Constructive Influence
Northern Associates.
Posted - 2011.04.23 11:09:00 - [152]
 

Originally by: Tork Norand
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.



Nah, just get graphic guys to do some cool space-storm thingy effect. We can say that amount of jump-in/laser activation is generating localized timespace aberrations and everybody will be happy.

ivar R'dhak
Minmatar
Posted - 2011.04.23 11:16:00 - [153]
 

Originally by: Daneel Trevize
Originally by: Kyoko Sakoda
I'd like to second the idea of getting a server notification on dilation factor as a UI element. Make it one line of text with a clock icon, and put it somewhere inconspicuous like around the session change timer or what not, but it needs to be there.
This. So obvious and yet :ccp:
Nah, I like the client going "Matrix bullet time" on us much better.

Offloading the server is top priority, so having a damn timer clock updated by the server for every single client on the grid sounds a bit counter productive.

Hope they manage to offload the detection process to the client so it slows down turret and all the other gfx on its own. That is, if dynamically slowed down turret animations are possible.

Tanya Tribble
Posted - 2011.04.23 11:21:00 - [154]
 

Firstly, i'm not a 0.0 resident, but i've experienced soul crushing lag numerous times. I'm also for anything that makes the game more playable for everyone.

A few things i'm curious about. Veritas said that it would likely be node wide, therefore it would effect every system running on that node, right?

One problem i can foresee is the average, uninformed, player be they mission runners, miners, whatever, not realising their system is in a dilated state (whether there's a UI notification or not) and repeatedly spamming controls thinking the server just isn't responding. Would this cause more load on the node, bringing the clock further down for all involved and eventually breaking the node anyway?

Could this lead to each side trying to out spam the other in a dilated system, maybe to buy time for reinforcements?

Does it even work like that?

With regard to dedicated nodes, how many large fights actually take place on them?

Veritas quoted 1600(ish) as the breaking point where TD would probably kick in. This won't help small scale pvp then?

Levitikon
Constructive Influence
Northern Associates.
Posted - 2011.04.23 11:27:00 - [155]
 

Originally by: Ben Derindar
Quote:
It's often said that the War on Lag cannot be won because our players can always bring one more ship.

So why not address the problem by making it harder for such blobs to form in the first place, by nerfing all forms of long distance travel?

I don't disagree with the time dilation concept in theory, but unless things like jump clones, jump bridge networks, capital ship jump ranges etc are also heavily nerfed, bullet time will become the norm in every single PvP encounter of consequence.

CCP's proposal is basically to change said encounters from being "free-for-all" slideshows to "balanced" slideshows. While I suppose that is an improvement on the status quo, what would be even better is if fights were mechanically prevented from becoming so stupidly large to begin with, so that time dilation is rarely - if ever - needed at all.



Keep in mind that we already have heavy, uncontrolled dilation ingame - gun activations are effectively dilluted to less than 10% in every major battle, while warp outs still work reasonably on time.

If you look at dps stats, you would see that some battles that in theory (and accounting for player decision 'lag') should resolve in matter of less than hour, can take literally half a day.

Dilation not only makes it more balanced; it will also:
1. Make battles quicker, overall.
2. Fix all ******ed dissapearing ships, ghost titans, bugged killmails, black screens, etc.

Of course, dilation is only part of solution, other part are tweaks to sov system that require:
1. Simultaneously attacking multiple targets on separate nodes and accomplishing majority of objectives to win.
2. Objectives based on presence, instead of pure dps bashing (i.e - time required to flip should not change significantly with amount of people involved and in perfect scenario, even one unopposed guy should be enough to flip sov).

This way we still have huge battles EVE is famous for, while small guys get tons of tactical and strategic options to fight against more numerous foes (of course, it wont help them, if the more blobby side will utilize decent tactics as well:)

Daneel Trevize
Gallente
Posted - 2011.04.23 11:31:00 - [156]
 

Edited by: Daneel Trevize on 23/04/2011 12:25:52
Originally by: ivar R'dhak
Offloading the server is top priority, so having a damn timer clock updated by the server for every single client on the grid sounds a bit counter productive.

Hope they manage to offload the detection process to the client so it slows down turret and all the other gfx on its own. That is, if dynamically slowed down turret animations are possible.
The client has to be told the TiDi rate.

It can't work it out alone, what could you possibly analyse that would have a 100% correlation with the rate?

E.g. Ships and missiles not yet at the speed/position you'd expect them to be at by a certain wallclock would require the client to buffer/log previous positions and actions to extrapolate and even then acceleration is affected by other external things such as manual flying and each person's SPs which you aren't privy to. Currently I expect the client is just told what's where when (and with what ehp, etc) with the server calculating from base to effective values before telling the client. You aren't told if a pilot set approach to another ship to make them move them in that direction or if it was manual clicking or AP, etc. The server is authoritative, so you have to go with what it says and not know/question why (see rubber-banding).

Edit: with all that said, do you see how much effort would have to go into building something like client-side TiDi detection? Yes you could possibly in theory sent the SP data to clients and have it duplicate the servers's calcs to find the differences, but hello why not just send the TiDi rate? You seem to severely underestimate how much the client needs to already receive just to display all the objects moving on your screen anyway, one single number isn't going to really add to the load, and it's the same value to be sent to all clients. Yay it can be cached and not need to be mapped per client even if the current network setup doesnt allow it and other such common-to-all-clients data to be multicast.

Oh, and improving the client to make the gui effects like module cycles go slower should be simple and a relatively common change to all such icons/module types.

DanMck
Amarr
Rionnag Alba
Northern Coalition.
Posted - 2011.04.23 12:23:00 - [157]
 

"bullet time" for eve ugh

anything helps i suppose but just change the sov mechanics , limit what can jump through a cyno and jumpbridge,limit standings (charge per blue) and treat the root cause not just the end product.


Florestan Bronstein
24th Imperial Crusade
Posted - 2011.04.23 12:40:00 - [158]
 

Originally by: Ranger 1
Edited by: Ranger 1 on 22/04/2011 19:58:19
I have to say, petitions from people that don't keep up on such things should be amusing after this goes into effect.

"I lost my ship because the game wouldn't respond to my commands properly. I jumped into X system and a pirate was there waiting for me. I think there was some sort of big fight going on elsewhere in system, as there were wrecks everywhere."

"I immediate turned to run back to the gate, but my ship just sat there. Fortunately, the pirate just sat there studying me. Realizing that I would probably not make it, I clicked to warp to the nearest celestial object and since I wasn't targeted yet I activated my cloak."

"My ship finally started to move, but much to my surprise it turned in the direction of the gate instead of where I wanted to go. Worse yet, the pirate chose that moment to lock me up."

"I decided to fight, which meant I'd have to get into close range. I clicked frantically to go into a close orbit, but instead my ship veered off at an oblique angle and tried to cloak!!! Obviously this failed and I started taking significant damage, the pirate continued to advance and fire."

"I estimated my only chance was to try and run directly away from the pirate, I was a bit faster than he. When I double clicked away from him, my ship instead veered almost directly towards him, ignoring my commands."

"In the end I died, and my ship never did respond to my commands properly."

"I want my ship back!!! Fix your game!!!!"

... ah, good times...



that's a description of lag (queued commands), not time dilation.

Destination SkillQueue
Are We There Yet
Posted - 2011.04.23 15:18:00 - [159]
 

Originally by: DanMck
"bullet time" for eve ugh

anything helps i suppose but just change the sov mechanics , limit what can jump through a cyno and jumpbridge,limit standings (charge per blue) and treat the root cause not just the end product.




That isn't enough because game mechanic changes won't remove server crushing blobs, just mitigate them and reduce their frequency. This is also the tech guy's solution to the issue and is independent of game design solutions. A system that can handle high stress situations more gracefully needs to be made regardless of what happens in game design side of things.

Fights bigger than the servers can gracefully handle will always happen in the foreseeable future. The only choice the tech guys have to make is to either have no system in place to deal with that situation or build a system that handles those situations in a more graceful manner. Seems like an easy choice to make no matter what choices are made in other departments.

Gavjack Bunk
Gallente
Genos Occidere
HYDRA RELOADED
Posted - 2011.04.23 16:03:00 - [160]
 

Einstein says you're not looking at the bigger picture here.

Hyperforce99
Gallente
The Scope
Posted - 2011.04.23 16:40:00 - [161]
 

Love the idea, as an alternative to soul crushing lag, i'd rather have bullet time.

Also, i'm curious how the role players are going to explain it, should be interesting Laughing

damnjita
Posted - 2011.04.23 16:43:00 - [162]
 

Also remember it has been a long stated goal of CCP to make battles more tactical but combat exceeded the speed at which those decisions could be made. More than just fixing lag it create the opportunity for ccp to look into that again.

However this can be a real balance issue with the divisions of nodes. (ie Systems A--B--C, B,C are on one node, Alliance X has a jumpbridge in A, Y has a jump bridge in C. X can supply reinforcements in real time, Y needs to move through a TiDi system to reach the battle) CCP needs a way to dynamically dump a system to a reinforced node (difficult) or create an environment where a system can run a set of commands on a node with seperate parmaters from the other systems, which is harder than just changing the clock on the server. The occupied node needs to recongize the ticks differently.

Ranger 1
Amarr
Ranger Corp
Posted - 2011.04.23 17:53:00 - [163]
 

Edited by: Ranger 1 on 23/04/2011 17:53:45
Originally by: Florestan Bronstein
Originally by: Ranger 1
Edited by: Ranger 1 on 22/04/2011 19:58:19
I have to say, petitions from people that don't keep up on such things should be amusing after this goes into effect.

"I lost my ship because the game wouldn't respond to my commands properly. I jumped into X system and a pirate was there waiting for me. I think there was some sort of big fight going on elsewhere in system, as there were wrecks everywhere."

"I immediate turned to run back to the gate, but my ship just sat there. Fortunately, the pirate just sat there studying me. Realizing that I would probably not make it, I clicked to warp to the nearest celestial object and since I wasn't targeted yet I activated my cloak."

"My ship finally started to move, but much to my surprise it turned in the direction of the gate instead of where I wanted to go. Worse yet, the pirate chose that moment to lock me up."

"I decided to fight, which meant I'd have to get into close range. I clicked frantically to go into a close orbit, but instead my ship veered off at an oblique angle and tried to cloak!!! Obviously this failed and I started taking significant damage, the pirate continued to advance and fire."

"I estimated my only chance was to try and run directly away from the pirate, I was a bit faster than he. When I double clicked away from him, my ship instead veered almost directly towards him, ignoring my commands."

"In the end I died, and my ship never did respond to my commands properly."

"I want my ship back!!! Fix your game!!!!"

... ah, good times...



that's a description of lag (queued commands), not time dilation.


Actually, if you look carefully, it is a description of what will happen under the effects of TD when one person changes their minds frequently (click happy) vs one that chooses a course of action and only issues new commands when necessary (with full knowledge that the response to those new commands will be qued and delayed, and to what extent). In a true lag situation, both parties would be unaware of how much delay (if any) would be present and both would be much more likely to rapidly click and try different courses of action when the game doesn't respond immediately.

On the question of will a retreating force gain the advantage by jumping out of a TD system, it will depend of how often the server recalculates the level of TD. If the server adjusts the TD rate every couple of seconds, as soon as the retreating force jumps through the gate the TD effect will be reduced or eliminated, thus reducing any advantage they may have had significantly. If the level of TD is only adjusted every 10 seconds or so, the advantage would be significant.


Diomedes Calypso
Aetolian Armada
Posted - 2011.04.23 20:53:00 - [164]
 

Have you thought about getting rid of Drones, Missles, and Wrecks at levels of ships in system where you would anticipate server problems?

Alternative damage systems could take effect like in the inursion systems when this sort of thing happens to achieve something Closer (closer, anything between nothing and perfect would be closer.. of course you can't be perfect) to ship balance by that removal . (increased hybrid damage for instance and missles suddenly becoming lasers or projectiles (i think you've moved slightly that way already).

Wrecks? sorry, no loot when the very essence of space begins to tremble with all the electronic effects (shields, ecm, warp radiation flames (yeah no sound in space yet maybe some sort of radiation is released?)


Getting rid of objects that far outnumber the ships would have to help server speed immensely ? right?

Eclorc
Posted - 2011.04.23 21:19:00 - [165]
 

Edited by: Eclorc on 23/04/2011 21:22:12
All sounds good, but there's one thing that the graphs and maths has not taken into account so far afaik, and it's kinda important to plan for and find a way to prevent...

Limits on how many times you can double click in space (for example), or queue a command..

In a time-dilated scenario some restriction on the number of actions that can be sent from the client per-cycle/per-dilated-second will need to be implemented, else if the clock went down to 10% speed, then 10 seconds of queued commands per cycle will just flood the server exactly the same.

To make this command-count-total restriction work "in reality", then some prioritisation of commands and cancel/superceding of issued commands by newer-entered commands would need to be made inside of the client, with each "final set" of commands being sent at the end of the dilated-cycle.

tl;dr: client will need to queue a limited number of commands to be sent to server at END of dilated-second-cycle. New command issue should overwrite similar previously issued command in the client's queue. Command priority should be evident, like warp-GTFO takes precedence over double-click-space or target command so GTFO is sent instead...

tl;dr of the previous tl;dr... Allow for Command Spamming, clock slow, mouse finger same speed...

edit: I now see that Ranger1 kinda pre-empted this above. Bears repeating and clarifying tho.
btw, will this mean that an autocannon will fire more than one shot every five minutes under bad lag in future? Had that happen under normal lag, even without time dilation...

Malcanis
Caldari
Vanishing Point.
The Initiative.
Posted - 2011.04.23 21:38:00 - [166]
 

Originally by: Vile rat
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.






This about sums it up.

+1 to the "really postive reaction" factor. This has the potential to really revitalise big fleet combat.

Cailais
Amarr
Nasty Pope Holding Corp
Talocan United
Posted - 2011.04.23 21:59:00 - [167]
 

Edited by: Cailais on 23/04/2011 22:00:22

In EVE Online all these blobs are yours....


C.


Soldarius
Caldari
Peek-A-Boo Bombers
Posted - 2011.04.24 04:59:00 - [168]
 

Got to page 2 and couldn't stand reading ignorant posts anymore.

If you are ice mining in an area that is lagging, you are about to die because there are literally thousands of people looking to kill anything around them. Do yourself a favor and log out. There is life outside of your mom's basement.

TD has already been explained as a solution to server lag. Thus, it has little to do with what's on grid, and everything to do with server load. If you have issues with only a couple hundred people on node, then its graphics lag caused by your crappy computer and fail overview/graphics setting. Turn your graphics options all the way down, hide all brackets, and use the absolute minimum items on your overview.

As far as cynos, we have to weigh the issues. If they are dilated, yes, outsiders would get the benefit of having a very long duration cyno, allowing for lots of reinforcements. Not that this doesn't happen already. On the other hand, the cyno ship would become a high-priority target.

From an RP perspective, one could say that due to the faster-than-light comms used to send the cyno signal to fleet members, that it simply isn't effected by TD as the rest of space/time is.

Spyke BlackIce
Minmatar
Posted - 2011.04.24 05:48:00 - [169]
 

Good blog CCP Veritas. This is an interesting idea. Who actually came up with the idea of slowing time down to reduce lag and has it been used successfully in other games or clock intensive applications?

Also, I've read the first page and skimmed a few others so I'm hoping this hasn't already been discussed... Since there are questions about what should be affected by TD - how much space/server real estate, which effects, modules, cynos, POS fuel consumption, etc. - and there are questions about how this will affect coming back into normal time, why not just TD the entire game when a large battle takes place? Would this be feasible? I doubt many battles would cause the TD to stay at the lower ranges, say below 50%, for very long so the effect on those outside of the battle wouldn't be much of a bother and it would keep everything synchronized.

Perhaps a small notification could pop up along with the suggested TD indicator announcing that due to a huge hostile engagement in <insert system name here>, time has been slowed temporarily. Heck, it could even be tied into the backstory with something along the lines of -
Quote:
"Due to the enormous amounts of energy and technology, some of which is alien in nature and not fully understood, being employed in these huge fleet battles, the flow of time is affected, slowing down in direct proportion to the size of the fleets involved, but as the combatants begin to dwindle and thus the energies used die down, time begins to return to its normal flow."

Pickaxe Mike
Psykotic Meat
C0NVICTED
Posted - 2011.04.24 08:51:00 - [170]
 

Good blog and mark me down as someone that would really look forward to this change.

The lag is getting better, but I doubt this is a war that the devs can win. CCP needs to think about making the servers fail elegantly. Time dilation is a step in the right direction.

Pneumon Blaster
Quondam Souls of the Universe corporation
THE R0NIN
Posted - 2011.04.24 09:17:00 - [171]
 

Some visual effect would be handy :) also displaying time dilation factor maybe in the same way as incursion progress.

Abdiel Kavash
Caldari
Paladin Order
Fidelas Constans
Posted - 2011.04.24 11:12:00 - [172]
 

Edited by: Abdiel Kavash on 24/04/2011 11:12:18
Originally by: Trebor Daehdoow
Originally by: Abdiel Kavash
I could go on for a bit more. Long story short: slowing down one part of the universe will have a significant impact on the rest of it as well.

Good points, but garden-variety lag can cause similar issues as well. You basically have to pick your poison.

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


Looking at it this way, it is just an introduction of another gameplay mechanic, valid to be used and abused. If we need to introduce a gameplay mechanic to counter lag, it's infinitely better for that to be time dilation rather than, say, arbitrary cap on system population or fleet size.

It could be exploited, yes. But is that really a bad thing?

72inches
Posted - 2011.04.24 11:57:00 - [173]
 

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.


Tbh, its not where hardware is 'going' I haven't owned a 32-bit system for more than 2 years. Porting to multi-threaded seems to me to the first thing you'd want to do, but I'm no tech guy (photoshop had a multi-threaded patch for version 4 wasn't it?)

Since the last patch I have noticed an extra second here and there going thru gates leading to empty systems...I have a fairly strong system so it has zero to do with any graphical upgrades, i run with graphics maxxed at all times.

While I am not looking forward to the hack that will slow down time, I don't currently enjoy fleet fights above 1200-strong either.



Huiron
Posted - 2011.04.24 12:08:00 - [174]
 

Excellent post CCP Veritas.

I was at the fan fest and was actually bringing this up as well during a round table.
Then had a very nice discussion with you about this on the floor.

So I am really happy to see this level of commitment from not only CCP, but also the CSM and other eve players.
I believe you pretty much got it covered in ideas, so not much to add.

Keep up the good work
Huiron

Katrina Bekers
Gallente
Fighters Squadron
Posted - 2011.04.24 18:57:00 - [175]
 

Originally by: The Mittani
I learned more about how lag works in that one blog than I have in years of playing this game, heh.

...And my money is on your allianc/coalition resident "gameplay explorers" being already at work on how to exploit present and future scheduler mechanics.

And that's not a criticism, mind you, but good old flattery.

Exploiting game mechanics and telling the world (grid-fu comes to mind) is a positively aggressive way to have the holes plugged.

Cryuji Eterna
Minmatar
The New Order.
Posted - 2011.04.24 22:08:00 - [176]
 

Hello all! I have read all of the posts on this matter and I have come to the conclusion that we don't need to handle special cases between dilated and non-dilated systems, provided it is implemented properly. How you might ask?

By exploiting the wonderful physics principles that is relativity!

Here is an example for those that are not following my reasoning. I'm going to use jumping between dilated and non-dilated systems as the example basis, since it appears that this is a huge point of discussion. Currently jumping between systems appears to take no time (instant) but we can say it takes a very very small amount of time - lets call this time x, the time it takes to jump between systems that are not dilated.

Consider this time from the perspective of an observer (an observer is someone external to the system, like you the player) to systems A and B. When someone jumps from B to A the observer will perceive that the jump took B seconds relative to the clock of A; vice-versa for A to B jumping. We can make this assertion because the clocks in both systems are running synchronously relative to each other.

Lets introduce time dilation factor of 3 in system B. This means that relative to A, B's system clock is running at 1/3 the speed. Inversely, this means that relative to B, A's clock is running at 3x speed. Note that this is from the observer's perspective. If you are inside any of the systems you wouldn't know that time dilation has occured - it still takes x seconds to jump. But as an observer, we can see a difference since we are comparing the clocks of the two systems to the clock of ourselves (the observer clock is our point of reference)

Going back to the jump (which is a session change) lets think about jumping in a slightly different way. A jumps to B. At this point, the ship vanishes into the warp wormhole. From this point in time, the ship will reappear in B at some later time x.

Non-dilated:
Lets say that the clocks of A and B are running at the same rate of 1 tick per tick of the observer's clocks (O).
According to the observer, the ship will appear after x(B) seconds have elapsed, where x is the number of seconds in that system's clock. It just so happens that the clocks are synchronised from the observer's reference in a non-dilated jump so that x(B) == x(A) == x(O).

Dilated:
So the observer sees the ship disappeared from system A at some point in time. So when does the observer see the ship reappear in system B? The answer is x seconds - it's what kind of seconds that is the hard to grasp part.
- From the reference of A: let the rate of O = rate of A (dxA = dxO). Now since B has been dilated, we can say that dxB = dxA/3. In other words, 1s in B takes 3s in A. Since the observer is synced to A, 1 tick in B also takes 3s in O. So the ship will appear after 3*x seconds for the observer.
- From the reference of B: dxB = dxO; dxA = dxB * 3. In other words, 1s in A takes 1/3 second in B. The ship takes x seconds to appear for the observer. The message to A to say that the ship has appeared in B takes x/3 seconds to appear to O

In the world of EVE us players have always been an observer - we just don't have the technology to sync the physics of our world to that of EVE's (yet :p) so it makes it very very simple to apply time dilation. We just sync the observer clock to the non-dilated systems, and it just appears that the dilated system is running slower for us.

I'm going to end with another example to illustrate my point, continued in the next post :D

Isopar Daquis
Posted - 2011.04.24 22:13:00 - [177]
 

Edited by: Isopar Daquis on 24/04/2011 22:18:11
Edited by: Isopar Daquis on 24/04/2011 22:16:50
Edited by: Isopar Daquis on 24/04/2011 22:14:09
Lets say you want to light a cyno into a dilated system to send backup. My understanding of the cyno process is thus:
[deploy cyno] -> [jump through] -> [pew pew]
lets say in A, the cyno takes 20 seconds to deploy and that ships jump through straight afterwards into B (dilated 2x). What about in B? We would see the cyno take 40 seconds to appear, and the ships start appearing afterwards. It is important to note that the jump is not instant - it has a time of y seconds from the time the cyno appeared. While to you the observer this time may be small in A, in B this time is dilated by a factor of 2. So if it takes you 0.5 seconds to jump through after the cyno was deployed in A, it would take you 1 second to finish jumping after the cyno appeared in B. More importantly, it will take 41 seconds for your ship to join the fight in B from the time the cyno deploy was initiated. Note that this is the time from which the connection between the systems was first made for the cyno jump process. If the cyno was destroyed 5 mins after it was deployed, then the output from the cyno would take 10 mins to disappear in the dilated system (note that this will also allows ships that were able to use the cyno to finish the jump). As you should be able to see, the cyno would dissappear 10 mins 40 seconds from when it was initiated in the dilated system.

We can apply this principle anytime there is interaction between a dilated and non-dilated systems. PI processing? Takes 3x as long. Change PI processing? The change that would normally take 0.5 seconds now takes 1.5 seconds. Remotely managing a POS blueprint copy in a dilated system? Any changes you make will now take longer to register from your perspective, but the change itself won't be quicker or slower to anyone who is in that remote system.

The only thing that we have to consider is messaging. For thos fighting in the dilated systems do we want to delay the messages through the chats from outside? Or do we omit the dilation for the messages (in effect allowing for faster than light communications). My thought is to exempt messaging from the dilation effects - this can be an interesting mechanic that will add dimension to fleet battles.

Note that the way of thinking here also fits into the EVE universe quite well. It is not unthinkable to have areas of space that run on different clocks relative to each other - perhaps due to wormhole effects and/or the collective effect of a lot of ships fighting.

My explanation may not be very good - it is hard to explain relativity at the best of times. I definitely think that this is the way to go. It would also provide a very tangible way of teaching reltivity which is a huge bonus in my opinion :D

(stupid default forum settings. it likes to reset my default char all the time :( )

HeliosGal
Caldari
Posted - 2011.04.25 09:48:00 - [178]
 

love this idea its an anti blob feature the more u throw at it the more youre time will grind on. Might discourage this blob warfare might even discourage caps but gimp the high end of the game which ccp loves to advertise but who cares good move

Taka Taka
Capital Industries Research And Development
Fidelas Constans
Posted - 2011.04.25 11:18:00 - [179]
 

Edited by: Taka Taka on 25/04/2011 11:18:41
In my opinion, the most elegant solution to handle Cyno gens is a mixed one - ships in the non-dilated system have a constant time dictated by the cyno's activation timer (as it is today), whereas the ship lighting the cyno field activated in the dilated system is disabled (i.e. the cyno is lit) for the full duration of the time dilation.

Practically, this would mean that the cyno is lit in system longer than it would be available to jump to from outside.

A much more difficult problem to solve, in my opinion, is for players jumping OUT of system. As I understand, using Veritas' example, at a constant 10 minute timer, in a system where players are warping or jumping in rapidly (say 5% dilation), a pilot jumping out would have only the relative equivalent of 30 seconds from time of cyno-lit to jump. Most definitely a problem if you are in warp or waiting for your cap to recharge. On the other hand, if the ship cynoing out is for whatever reason also affected by Ti-Di, it would be stuck there for over 3 hours (assuming 5% the whole time, which seems unlikely).



hired goon
Posted - 2011.04.25 11:44:00 - [180]
 

As the guy who originally posted this in assembly hall, I am beyond excited that this has now essentially been confirmed for implementation.

As if I wasn't already enough of a CCP fanboy.

Guys I think I'm gonna cry Crying or Very sad


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