NARDAC
NIGHTMARE FACTORY INDUSTRIES
Claimed.
18
   |
Posted - 2013.02.01 00:26:00 -
[1] - Quote
Sephira Galamore wrote:
I thought about that, too, while reading the blog.
And I think the most likely scenario to ever do that would be to enable 0% TiDi. That is possible and does exactly what we want -
TiDi is basically multiplying the time something will happen, when you put it into the queue. Normal module cycle time is 60 seconds? So, if the server receives an "activate module" message at 1356976800000 (representing the number of milliseconds since Jan 1, 1970) and would normally add 60,000 (number of milliseconds cycle time) it queues up the module to repeat (or become available to activate again) at 1356976860000.
With TiDi at 10% then instead of adding 60,000 milliseconds to the queue time, it adds 600,000 milliseconds.
If missiles should course correct every 1 second (1000 milliseconds) they course correct every 10 seconds (queued up at 10,000 milliseconds.
Ditto drones. Ditto ship location updates. Ditto everything else.
So, to set TiDi to 0%, every queued up event would have to be set to infinity. or, say max time, which is 2038 for 64 bit machines (Y2K was NOTHING compared to what is coming in 2038).
BUT, the problem has nothing to do with when events will happen.
It has to do with active TCP/IP sessions. When you session change, such as undocking or jumping system to system, your existing tcp/ip session is destroyed and a new one is created. This sometimes takes time, and you can appear in the new system, long before your client has created the new connection to the new server. This is why you are cloaked when you jump and why you are invulnerable when you undock or come out of warp. How much would it suck if instead of jumping to a new location, you appeared in station because the people on the other side of the gate killed you before you even commected to the server and loaded the grid?
I've been in fleets of 200-300, and jumping from one system to another can take 5-10 minutes... this is why the traffic control. That is basically a guess from the server as to how long it will be to get to you, based on how many people are waiting in front of you... like when you call customer service and they say your call will be answered in 2 hours.
When they move a solar system, they just DC every connection, and move the environment. Then people re-establish their connections to the new box one by one as they log in.
So, it seems to me, what they would need to do is stop processing the queue. Copy rather than move the VM. Then one-by-one move ships from one server to the new instance of the solar system, as if they were gate jumping to the new system... say 1 second per x 3000 =oh... an hour.
So, freeze the system, tell everyone the fight will resume in an hour, clone it to the beefy server, no one else can jump into or undock into that system for an hour... then, when everyone is moved add 3,600,000 milliseconds to every event in the queue and... I don't know... give a 1 minute countdown to when the fight is going to start up again?
I'm not sure people will be real happy about the hour of frozen in place time... time for each side to position reinforcements, to jump into the fight as soon as it unfreezes.... just making it every bit as laggy on the new hardware when the fight increases to 6000 ships instead of 3000. |