EVE General Discussion

it's lovely you'd like that from ccp

i'd like a unicorn

i think this is a great idea, reshipping issues as already mentioned are good for economy

but isnt lag a wider issue of game design? if 3 years ago fights were 3x smaller surley in 3 years theyl be 3 times bigger, which means more lag. dont there need to be game design changes to stop lag aswel?

Already forgetting how Time Dilation will work? Perchance some have not read this yet then? Perhaps read it first then make comments second. Time Dilation, again

Carbon IO is a system that allows for lightweight communication between the cluster and the clients. In other words, it's a new mechanism by which our computers talk to your computer. It has nothing conflicting with Time Dilation.



It has very little benefit to cluster capacity by itself. It enables us, the programmers in Eve, to use a new communications method in new code, which we're planning to do but nothing has happened yet.



TiDi will kick in when a node has become overloaded and will stop when that node is no longer overloaded. Do note that only that node is effected, not the whole cluster.



We already have some C++ systems. Carbon IO allows C++ code on the server to communicate directly to C++ code on the client via BlueNet, which is a new capability that makes it easier for us to move performance-critical systems over to C++, which was already on our roadmap to do. That it's easier and more effective for us to do now means it's higher on our priority list than it was before.



Common decency forbids me from answering this.

So, if a node have a small skirmish in another system with like 4-10 ships, it will be affected too, right?

Have you decided yet if you will be showing which systems are using TiDi on the map like other states of the game or will FC's have to send scouts out to see what the state of other systems are?

Is there any correlation between the "locations" of the systems and which nodes they run on? IOW would a shared node tend to handle multiple systems in the same constellation or is it more or less random?

If the former that's probably actually a good thing since it will address some of the concerns about people taking advantage of the timeflow difference to bring in reinforcements.

In fact it seems like it would be a good idea to spread the dilation affect out 2 or 3 systems from the affected system to address that concern.

Actually the way to do it is to split the work up into separate processes and have the processes communicate over IPC. It's been done since Unix was young, but seems to be something of a lost art. Googles Chrome seems to have resurrected interest in the approach.

I can't go into the details, but I have been in contact with the dudes working on the EVE/DUST interaction and we have solutions.

The thing about time dilation is it's just a different version of what you're already experiencing in laggy fights.

It isn't fundamentally changing anything, you're still experiencing basically the same latency in your actions and the same performance, it's just being normalized so that responsiveness is preserved.

Instead of not knowing whether or not the input you issued is going to take effect and having to wait for an unclear amount of time to find out, and this being repeated on every input you're making, you're certain that your inputs are being processed and just have to put up with your actions being slowed down. They're slow, but definitive.

Time dilation is an inherent property of simulation. It will happen to you, you will never avoid it. However, it either happens as a chaotic emergent property that makes issuing inputs a massive confusing hairball, or it happens by design in a manner that preserves more sane control at the human interface end.