QHuman

Wait for it, then go

A render bar fills to 100% at a steady rate, and Continue only counts when the bar is full. Build a macro that watches for the finished state and clicks only then. Click on a timer and you will guess wrong; an early click is logged as a mistake.

wait for 100% progress bar timing Free 15 min

Most automations fail because they click too soon. A fixed delay is a guess, and a guess breaks the first time a job runs slow. The pattern that holds is to wait for a condition, then act: watch for the done state and fire only once you see it. Detection is how QHuman does that, and it is Free. The Render Queue is built to catch you guessing, and it counts every early click so you cannot talk yourself out of it.

Open the target first. It opens in a new tab. Point QHuman at it and read its counters as you go.

Open Render Queue

One job, one bar, one button.

Look at what does not change: the button is never disabled, so an early click always lands and always counts. The colour is the only signal, which is exactly why this is a detection job. The readout is honest too: it holds at 99% until the job is genuinely done, so 100% and a grey button is a state you will never see. Each job takes a fresh random 3.5 to 6.5 seconds, and R resets everything.

Build the macro

  1. Record the Continue click Record a macro that does one thing: click the Continue button. Click it whenever you like, even at 12%, and let it score the early click. That one is yours, from recording, not the bot's, and R clears it (counters and the event log) before the real run, so the bot is judged from a clean 0. Stop on the floating indicator, since the main window hides itself while recording, and save it as Render Continue. Nothing about the timing matters here. You are recording where, and detection will decide when.
  2. Open the detection flow for that macro Click Detection in the left rail, then choose Render Continue in the Macro: picker. Not the toolbar's New Detection button: that one asks for a name and makes a brand new empty macro, which would leave your recording behind. This view is where a plain replay learns to watch the screen.
  3. Add a "Wait" step Press Add step... and type Wait into Step name:. Because it is the first step in the flow it becomes the start on its own, with nothing to set. Leave its Do list empty. Doing nothing is this step's entire job: it sits and watches.
  4. Add a "Click" step and give it the click Add a second step called Click. Open it and use Add sequence... to play your recorded Render Continue. This step is the end of the run, so tick Terminal (entering it ends the run): the bot clicks once and stops, which is the whole job here. Without it, a step with no way out just re-runs its click every poll and hammers the button forever. (Looping it to re-arm for the next render is this lab's Make it yours.) Build this step before the transition: the wiring dialog can only offer steps that already exist.
  5. Wire Wait to Click on the blue button Open Wait, and under Then: go to the next step (first match wins) press Add. Set Go to step: to Click and leave Move on: on When a target is found / absent. Capture a tight snippet of the blue Continue button and set it to move on when the target is found on screen. Snip only the button's flat fill: catch its edge and the grey version may match too, which would fire the click at 12%.
  6. Check the wiring, and refuse the timer Two steps, one edge between them, and Click is terminal so nothing leaves it. Back on the macro's Detection tab the label should read configured - 2 states, starts at 'Wait'. Do not add a second, timed transition as a safety net. It is the guess this whole lab exists to kill, and this target will prove it: every job picks a fresh random length between 3.5 and 6.5 seconds, so any number you write down is wrong about a third of the time.
    The whole lab is that one edge. Wait cannot click too early because it has nothing to click with, and Click cannot fire early because the only way in is the match. The timer underneath is the guess: too short and it clicks at 80%, too long and it is just slow.
  7. Rehearse with Try it (dry run) Press Try it (dry run) and then Start, and only then press R on the target. That order matters: the bar starts filling the instant you reset, so resetting first burns the render you came to watch. In Event timeline the flow should sit on Wait the whole way up and cross to Click on the frame the button turns blue. Nothing is clicked for real, which makes this the only free look at your timing.
  8. Run it for real Go back to Macros in the left rail, since Play All lives there and not in the Detection view, and make sure Render Continue is loaded in the editor. Press R on the target, which clears the early click you scored while recording, then play. It should sit there doing nothing, which feels wrong and is exactly right, then click the moment the button turns blue. The run ends on that one click, since Click is terminal, so press R and play again to handle the next job. To bail out, slam your mouse into any screen corner: the fail-safe is on by default, under Settings → Playback.
Checkpoint

One number decides this lab, and it is Early clicks at 0. If it ticks up your condition matched something that was on screen too soon; if Completed jobs never moves, it never matched at all.

Three jobs, no red. The two millisecond tiles are how long the button sat blue before your macro noticed, so lower is sharper, but they are not the pass mark: waiting a slow two seconds is untidy, not wrong. Your numbers will differ. Early clicks is red even at 0, and the log tags really are lowercase.
Make it yours

Now make one bot clear a whole queue. Point the same flow at Order Desk, where a done-state appears for each order in turn instead of one shared READY chip, and reuse your wait-for-the-blue condition. Two small changes turn your single-shot bot into a repeating one: on the Click step, untick Terminal (entering it ends the run) so the run no longer stops there, and add a Then transition from Click back to Wait set to Always (every time). Now it waits, clicks, and loops back to watch for the next order, re-arming until the queue is empty. Same wait-then-act idea, just repeating.

If it went wrong

  • Early clicks climbing The condition matched before 100%. Tighten the capture region onto the blue button only, and use Test detection… against the target at 100% versus mid-fill so the match fires only when the button is QHuman blue.
  • Completed jobs never moves The condition never matched, so the Click step was never reached. Re-capture the READY button while the bar is actually at 100% and confirm the Wait transition points at the Click step.
  • It clicks the wrong spot The target moved or resized since you recorded. Keep the Render Queue tab in the same place, press R, and run again, or use Add click… so it clicks on the detected button wherever it lands.
  • The flow never leaves Wait Check that Wait is the start step and that its transition targets Click. The Detection tab label should read configured - 2 states, starts at 'Wait'.

Stuck?

Grab the finished flow. Download it and open QHuman's Import shared file... to load it, then compare its Wait and Click steps to what you built. It is a reference to read, not a macro to run: the detection snippet inside was captured on another screen, so it will not match your display. Run with the one you took in the lab instead.

Download the solution (.qhz)

Keep going

Want the full picture on steps, conditions, and transitions? Read the detection guide. Ready for the next lab? Next up is Read the number, stop at N, where you read a status word and a count off the screen and branch on what they say.