EVE General Discussion

I recently participated in a fleet battle (well, more of a fleet massacre...) that was under the effects of "Space-Time Dilation" and found it to be a pretty miraculous marvel of game design, but I can't quite understand how it works. A player participating in the fleet action perceives everything as moving slowly, so at say, 1PM real-life time they are at "Space-Point A", and at 1:05PM they are at "Space-Point B"; the player outside of the Time Dilation would presumably perceive that Space-Ship as having started at point A at 1:00 and reached point B at 1:05, but how does this reconcile with the slowed-down players experiencing in-game time more slowly than the non-slowed players?

A (space) wizard did it ?

Huh, interesting stuff. I only understood about 1/3 of it , but I guess that goes to show much work went into some of the features in this game.

I also have to wonder if something like this could have implications beyond EVE. Are there any possible real-world applications of Time-Dilation?

Note that its important not to enter the makrosingularity (which was created by the red matter) , or else someone really could go back in time and do a J.J. Abrams style reboot of Eve.

:)

From what i hear that's exactly why the cluster is off limits for any bitter vet as he would reset the game to 2003. Some ppl say it already happened once but was corrected, can't tell you more, temporal prime directive, sorry.

What do you mean by "real-world"? I don't get it.

Can't really help you there, i don't like to speculate on metaphysics.

Indeed, but the general consensus was that correcting it was a mistake.

The original time dilation:

Galactic Zones Diagram, Fire Upon the Deep

I would like to know if CCP multi-threads the processing of the "tasklets".

They could have one task queue per thread.

A given user is assigned to a thread, so an individuals logical set of tasks always work in order.

CCP mentioned times up in the 1+sec, so synchronizing threads shouldn't be an issue. You might have a work queue asynchronously join with the other related queues, after each cycle.

You might say, but wait, what if one user's tasklets are changing that user's data while one of the work threads has another users's tasklet accessing said user's data?!

Well, use some form of versioning. At the beginning of processing a work queue, have a "stable version" of all other queue's user data that will not be changed during that cycle. This could simple as double buffering user data and flipping which data is "stable".

When all of the queue's are finished processing for that cycle, you can change out the prior "stable version" for the current "stable version". This would be probably all single threaded and is done during some clean-up between cycles of processing tasklets.

Then someone might say, but then you're one cycle behind and you can get race conditions with which data is being used!

But aren't there already a ton of race conditions in the system? Players are asymmetrically positioned around the Earth, there is latency, there is jitter, there is reaction times, there's relativity, etc etc. What's one more thing to add to the bunch of potentially flipping two non-dependent events?

What I propose is you accept up to "one cycle" of potential "race-conditions", in exchange for a way to thread the heck out of the processing of tasklets. Then you can reduce the cycle time and reduce the window of race-conditions in the first place. If the new design is 1 cycle behind, but you can do at least 2x more cycles, then you're pretty much back to where you were, but now with better scaling.

I'm just rambling... sorry.. I know nothing about how CCP has their stuff coded.