let setGo = document.querySelector(".setGo");
let observer = new MutationObserver(mutations => {
if (setGo.classList.contains("going")) {
for (const { target } of mutations) {
if (target.checked == target.disabled) {
target.click();
}
}
}
});
observer.observe(setGo, {attributes: true});
document.querySelectorAll(".theSport input").forEach(checkbox => {
observer.observe(checkbox, {attributes: true});
});
Explanation: instead of messing about with timers, it asks to be informed when any attribute changes (could use attributeFilter to only hear about "class" for setGo and "disabled" for checkboxes, but I didn’t bother). This is faster than can be acheived with setTimeout, setInterval or requestAnimationFrame, as timers are deliberately speed-capped. (Whereas mutation observers create microtasks, so we can go through this whole thing in one frame.)
When the observer gets notified (in a microtask), it checks if we’re going (in order to avoid false starts), and then goes through the checkboxes it’s been told just changed, and checks if they’re enabled and unchecked, and clicks them. In practice, the first mutation will come in with mutation records for setGo and the first checkbox, which we’ll click, which will trigger an event (a task) from the page code which enables the second checkbox, which will trigger an immediate mutation notification (a microtask), &c. until it’s all done, without ever rendering a frame in the meantime.
Dunno quite what your idea was with canceled: your comment doesn’t match behaviour at all. As for dispatching a click event, you can just use .click().
Brute approach (This doesn't account for whether a checkbox is checked or not so I don't actually know if the game prevents everything getting checked programmatically all at once. I had to set the setTimeout to "2" instead of "1" so it would actually record some time!):
I wonder how much of the time is spent in the onclick handler. Each of those clicks has to wait for the onclick handler before the next one executes, IIUC?
Some of us have our stash of ~10 domain names for our side projects (that we renew year after year, with some embarrassment). Tim's got 90 linked from https://theuselessweb.com/
I wonder if he renews them on the cheap somehow, either way there are some really funny ones in there
Are you intentionally setting random tabindex values just to mess with keyboard users? I would like to suggest adding "Checkbox Paralympics" version, where keyboard users could compete too.
import pyautogui as m
from fastgrab import screenshot
m.PAUSE = 0
while 1:
x, y = m.position()
r, g, b, _ = screenshot.Screenshot().capture((x, y, 1, 1))[0][0]
if (r, g, b) in ((50, 205, 50), (127, 224, 127)):
break
m.moveRel(-35, 105)
for _ in range(27):
m.click()
m.moveRel(23, 0)
m.click()
considering how people are already gaming/cheating on this, it's useless stats.
Sure, you can write code to check for bots and the bots will write code to beat it...and so on
This basically told me I need a new / different trackball. The coefficient of static friction is too high in my current one to do this accurately - I need more force to start the ball rolling than I need to move to the next checkbox.
I'm using a Sanwa Supply one now
Looks like it might be a ploopy with BTS instead of their rollerbearings.
Kind of like minesweeper, but without the strategy part?
Because once a minesweeper addict has reached a certain base level of skill, the strategy part stops to be about where the mines are, it becomes all about reordering the click queue for speed. (don't ask me how I know)
On my tablet the slightes movement of the pen causes firefox to select stuff instead of switching the checkbox. Causes extreme slow-down.
Under normal circumstances I don't like websites to try to mess with selection, copynpaste, ... but in this case it would be both helpful and justified.
