Enhanced AutoReconnect

[HoratioGamer]

Is your feature request related to a problem? Please describe. AutoReconnect could be a lot smarter... so that one could avoid using an AutoReconnect time of 35 seconds, and get better Q positions on 2b2t.

Describe the solution you'd like First there has to be a 2b2t mode, and a other severs mode -- for other servers, just use a simple wait.

In 2b2t, one has to recognize the difference between Failed to Connect to Server and Refused Connect to Server.

 - Failed to Connect to Server
     while (1) {
         while (1) { 
             if (ping -1 2b2t.org==success) { break; }
             wait 400 ms;
         }
         consecutive_failures = 0;
         start_time = timer();
         wait_time = 12 or 15 seconds by default, adjustable;
         while (1) {
             if (ping -1 2b2t.org==failure) {  
                consecutive_failures++;
                if (consecutive_failures==2) { break; }
             } else {
                consecutive_failures = 0;
             }
             if (timer-start_time >= wait_time) {
                Initiate an Attempted connection
                end this process
             }
             wait 500 ms;
         }
     }

 - Refused Connect to Server
       wait for 35 seconds by default, adjustable;
       Initiate an Attempted connection
       end this process

Describe alternatives you've considered This is the algorithm I implement manually to get a good Q position after a restart.

Additional Considerations The behaviour of Anti-AFK on reconnect has to be made safe first, because, one will often get online within less than a prio Q wait after a restart. This will inevitably be used as a poor-man's prio, that works on every restart. If it leads to aberrant Anti-AFK behaviour with regularity then it will can be very damaging.

[HoratioGamer]

There are only 5 possible responses to this algorithm from 2b2t:

• Getting directly into the server -- problem solved.
• Getting in Q, hopefully with a good Q position -- problem solved.
• Failed to Connect again -- the process above restarts
• Refused Connect -- the process above restarts
• Refused to connect -- refresh token by logging out of minecraft and back in -- this is a rare message, and something Lambda cannot resolve.

The actual optimal wait time to get into 2b2t has varied with time. Something about the manner in which the server comes up has changed over the course of months. The order in which the server accepts connect attempts, prio first or non-prio first by a couple of seconds -- yes that has changed over time too. Anyone who tells you it is prio first was right at some point. Anyone who tells you it is non-prio first was also right at some point. Also, there are times, with 3 accounts that if I connect them 1,2,3 at N seconds after the first consistent sign that the server is back up, it is possible for 1 to get in Q, and either 2 or 3 to still get Failed to Connect, so, even after N seconds, it is possible the server is not consistently accepting connections. This algorithm running on each separate instance handles all of these cases -- a Failed to Connect leads to an instant retry.

Strategically Setting the Wait Time So, with experience one has learn what the currently-prevailing optimal N seconds is. Now comes the interesting part. Setting for N, 4 months ago, one could get 2 out of 3 non-prio accounts directly into the game -- a complete Q-skip. Now, getting directly in with a non-prio account is rare, but so is a Q position > 50, 30 is more typical, leading to about a 30 minute wait to get into the game -- this is comparable to waiting the prio-Q. N+1 is typically 40-80 Q positions from N. N+2 is typically 80-120 Q positions from N. Say the restart is due (because of the roughly 12 hour schedule of restarts ) to come at 1pm local time, but one does not get home from work or school until 3 or 4pm. One can intentionally set the time to reconnect to be N+4 meaning, the account will probably come on-line within an hour of getting back to their computer, or N+7 to try to get online after supper. I have done this. It works reasonably well, as long as one has a good idea what the currently prevailing N is. If one comes home and finds the restart was a couple hours late, then one will get on-line a couple hours later. If one comes home and finds the restart has not happened yet, then one just changes the wait time to be N and aims to get directly into the game, or, get a very good Q position. Restarts are rarely less than 12 hours, and usually only in the case that someone has been lagging the server or something else where the server starts crapping out unexpectedly. It is not a perfect plan for all realities, but, a good one the vast majority of the time.

Naturally as more people use Lambda because of its superior restart gaming, the results of both N and N+1 etc will change with time. The Lambda user who is paying attention will adjust their choice of N to best game the restarts as conditions change. The latest.log file will have logged at what Q position a particular N landed the player, allowing evidence-based adjustments of N.

This enhancement allows particularly non-prio players to better-schedule their gaming, despite the Q in 2b2t. This enhancement allows players with one prio and one non-prio account the opportunity to have both accounts online with a reduced burden of gaming the non-prio Q.

[Avanatiker]

well thought out idea. we will look into that when time is allowing!