steamSummerMinigame
steamSummerMinigame copied to clipboard
wchill
Use game events to improve responsiveness
Instead of multiple interval timers that could desynchronise with server ticks after lag and cause sub-optimal clicking.
Are we sure updates occur with the same frequency that we want to do clicks? Does the game update when it sends data or when it receives it?
Script seems to be working okay for me so far.
These update events occur immediately when data is received from the server, meaning the script never misses anything it might want to act upon. Commands will continue to be sent at a time the game decides (when now > lastSent + g_msTickRate). Now that you mention it, the click counter is reset to 0 just before sending so I should really hook into that to set the click related variables.
Actually, I just spotted that the game never has more than 1 request/response in flight. It always waits for the response to its last request before sending anything else, so regardless of when we want to click we're already bound by the game, server lag and network latency. This also means the click variables I thought I needed to move are actually fine where they are, every request sent to the server will contain the command for 20 clicks.
I also have a suspicion that this change fixes a race condition somewhere in something the script does. Testing the original code with timers, I occasionally see TypeError: this.m_data is undefined enemies.js:126:1, testing this branch I have not seen that error at all. Perhaps the timer method sometimes runs after all enemies in a level are killed but before the next level has been received from the server?
@welwood08 Yeah I would guess that is what happening. Had to deal with the enemy data being undefined and it would usually occur when the boss would die: https://github.com/oedw/steamSummerMinigame/commit/cc0cbd560c81b4ac5491077b87687e5fc6f8b5bb#diff-2400c5b9c09e41abca684af32c0de223R1103
Currently using timeouts :( Would be awesome to just "block" the refresh when a boss appears and "unblock" refresh when a boss dies a la C/UNIX signal mask
Yes, auto-refresh would be much easier to control from MainLoop - we don't need to have any setInterval or setTimeout calls in the script.
Following the successful merge of #99, I have just rebased this branch on bf9ccf1.
Squashed (that was a painful first experience!) and rebased onto 9bffe0a09cfd0eb5f542597779c593df6dee4d05. Running this code in my game now to test Greasemonkey. Only problem I'm noticing is lots more stale data messages, but I think that's come from steamdb.
OK, some of the stale data messages were from code brought in from elsewhere - I have encountered another game-stopper though so don't rush into merging or anything just yet. :p
Is anyone else testing this branch? It's more time-consuming fighting the merge conflicts every time I rebase. I can report a second successful night of continued functioning with auto-refresh disabled.