I know this is not how the calculation is done to measure the time taken for server spool up regarding player capacity, and it will probably be much different when shards come into play, but for this freefly, I did a little rough test to time how long it took for approximately 50 connections to update from a queue # of 1487 to 1437. This was done by simply waiting until the Free Fly went live, updating the patch quickly and launching the game. It took about 54 seconds to move from 1487 to 1437. Now I'm sure that some in that queue would have joined an existing server that had a remaining capacity, which would have skewed that stop-time. We definitely also know that the main goal is to reduce the chances of (and pretty much eliminate the factors for) server-side crashes. But keeping the wild estimation of 54 seconds just for rough-estimation sake: 1. When we do get the ability to recover from server-side crashes, does this mean that roughly 50-ish seconds would be the time clients will need to hang until information is transferred from a dying server to a fresh one (assuming the developments on the network end is how it is now, even though it may not be then)? 2. Or is the time much smaller and methodology behind it more comparable to the 'handshake' needed for server meshing and information transfer if we're talking about going from a server governing a planet (Hurston) to one that is governing open space? 3. Will there be servers prepared in advance to account for these events, dependent on the volume of connections required? 4. As a lot of information and confirmation of client-side inputs is governed by the servers, does this mean that you will need a lot of servers prepared (just in case) in the event where server instability is high? Or will there be some server-instability sensitivity threshold to keep the server-spool quantity 'low'? Thanks for any info!