Briefly toggles on render for 1 frame (20ms) every 60s that pass while render is off, this is to refresh onscreen gui with new information, as well as prevent leaving render off longterm defaulting to the zoomed out minimap image that is common. The call for render toggle is on game message, so this only works while botting (that is ideal) and will trigger if time is right and a game message appears. Then onPaintTick is active at that point, so we let that call the 1 frame toggle off. Using game message now could take a while to get another game message.
Stormy said this should not affect the bot resource usage at all really.
LoginListener - Increase Wait times, Testing showed that being logged in ensures current time in ms > next_attempt and client will always log in 1 time immediately if you leave autologin on and manually click logout (preserving current behavior, and reminding the user they left autolog On) thus timing was increased for subsequent attempts.
Keyboard Handler/BotFrame - Full screenshot functionality rewrite. Added interlacer and gfx temporary toggle support, bot will turn off interlacer, toggle on graphics, take the screenshot, then restore them to previous states. thread.sleep allows time for drawcallback to render a couple new frames before image is taken. Added folder and playerName generation, will create folder structure
*/screenshot/playername/filename_playername_date_time.png
before saving the image. This is because java Image.write will NOT save a file if the folder path is non-existant. Using the file name structure generates a new file name 1x per second, unfortunately same file names will overwrite, but this allows 1 screenshot per second for infinity. It also perfectly mirror runelite screenshot naming convention.
Sets lowest time to 35 seconds, after 10 attempts goes up to ~2 mins minimum, increasing to 4 mins quickly, and 6-7 mins after long periods. Fixed the multiple next_attempts per login Attempt, feature is functioning correctly now.
Also slightly increases autolog time, as Ken suggested we can decrease it later if the problem resolves with this fix.
Also makes the random variable larger for i>11. now a random range of 10s
This is because APOS can't run a loop with the way Login Listener is written, this will start at 5s(+=1s) autolog for 2 attempts, then 15s(+=5s) autolog for the next 8 attempts (2 minute total) (there is currently only a 5s autolog, no WONDER there are issues when server reboots. ) then it will start at around a 1min login delay and ramp up to ~2.7 min delay at n = 50, and a ~ 4.2 min delay as n => 500. and a 4.6 min delay as n> 500k (so no worries about leaving a client autologging, it will converge on ~4.6666 (6 repeating) mins at infinity).
Toggling autologin will not reset your autologin counter, but when done the bot controller will always immediately attempt to log in, and if it cannot then it will go back to waiting. Perhaps a future addition can reset the counter?
system.out.println shows exactly how long till next autolog attempt, shown in seconds, as well as how many auto login attempts (since you were last online, this resets when you login)
1 small bug, onLoginResponse appears to process 2 times before bot goes back to
`if (System.currentTimeMillis() < next_attempt) return;` to wait for next_attempt system time.
This does produce 2x chat messages in the client console, as well as counts "i" twice as fast as intender. HOWEVER, the bot only logs in 1x per cycle, and it still produces the intended login timing results when tested (5s, 5s, 15s, 15s, ... , 30s, ... , 60s, ... ,120s)
this calculator can be used to visualize the different equations as "i" increases in value.
https://www.desmos.com/calculator
Graphs are an interesting way to visualize it. The value of the number x in
x = (i*15)/(i+60)
will begin to converge on a fixed value as "i" approaches ~240, notice we don't get too much increase in the beginning, that is good. Then we apply that x(i) to the equation y = (Math.random() * 30000) + (30000x(i)) + 30000. we want large values of i to converge on y = 5 for about a 4 - 5 min login retry timer after ~150-200 retrys. The size of (60) determines how flat our curve is initially (it has a reducing effect on the growth of the numerator). The Size of 15 determines where on the y axis our curve will converge to. convergence doesn't matter too much because we are only going to i=240, so we wont check very large values. All said and done we get this result (calculated with excel):
stormy