Why your flick missed: the click window, late inputs and latency

When a prayer flick misses, it is almost never because you were too slow. It is because a click landed on a different tick from the one you meant. In practice that comes down to four things: the click fell in the window before or after the right one, two taps meant for one tick ended up on two ticks (or two taps landed where you wanted one), your silent count drifted, or, in the live game, latency moved the click. The first three are things you can see and fix in a drill. The fourth you can only plan around.

Everything below uses Microgrind's Ward Flicking drill, where a ward stands in for a protection prayer: it blocks a shot if it is up on the tick the shot fires, and drains one energy for every tick it stays up after the tick it was raised. The tables are produced by running the drill's own code. If those two rules are new to you, start with Prayer flicking explained tick by tick.

Miss 1: the click landed in the wrong window

A click is applied on the next tick after you make it, so the click for a shot on tick T has to be made in the 0.6-second window that ends at T (how input queueing works). One window off in either direction gives very different results:

Early costs energy, late costs the shot. That asymmetry is why the usual advice is to click comfortably inside the window rather than on the beat itself: a click a few milliseconds after the beat belongs to the next window. On the results screen after a Ward Flicking run, a shot that got through shows as a hollow red circle on the run timeline, and every tick the ward drained shows as an amber bar, so you can see at a glance which side you missed on. The timing chart under it shows where inside the tick your clicks fell; clicks in the last 50 ms are drawn in red, because they very nearly slipped into the next window.

Miss 2: two taps, one tick

A ward press is a toggle, and every press made inside one window is applied on the same tick, in order. Two presses in one window cancel each other out. That is exactly what a 1-tick flick relies on, and exactly what breaks a single flick when a key bounces or a nervous double-tap happens:

The split 1-tick flick is the classic one. The off-and-on pair has to sit inside a single window. If the first press of the pair is a little early, it lands on the first shot's tick, together with the raise, and drops the ward before that shot is checked:

Tick Sense is forgiving here: two strikes inside one window still count as one strike. Wards are not, because each press flips the ward. The replay of a Ward Flicking run spreads several presses on one tick apart so you can see each one, which makes a split pair easy to spot.

Miss 3: the count drifted

Without a metronome or a charge-up, you are timing shots from your own count, and a count that runs slightly fast or slow adds up. In Tick Sense 4: Silent Count only the first 2 beats after each call-out are audible, so you count up to 4 beats in silence; in Ward Flicking 3: Cold Cadence there is no tell and no metronome, and a shot comes every 4 beats. Using the same clock rule as the drills, this is how many silent beats it takes for a steady error to push a click onto the wrong tick:

The column matters as much as the row. A count that starts in the middle of the window has room to drift either way. One that starts with clicks 50 ms before the tick has plenty of room to run fast, but slips within a few beats of running slow. The fix is the same as for miss 1: sit in the middle of the window, so drift has room in both directions. In Tick Sense the result appears straight away as an "Early" or "Late" call, and the timing chart's median tells you whether you habitually click near the start or the end of the tick. Keeping a steady count over many beats is its own skill, covered in 3-tick and 2-tick rhythm.

Miss 4: latency in the live game

A Microgrind run never waits on the network. The tick clock and the input queue both run in your browser, and the input log is only sent to the server after the run has ended, so a slow connection cannot move a click to another tick. Microgrind does not try to measure or correct for delay in your keyboard, mouse or display.

The practical upshot follows from the window rule rather than from any measurement: if part of your timing is outside your control, do not spend the part that is. Clicks in the last moments of a window are the first to slip, so aim earlier, and keep the two presses of a 1-tick flick close together.

Which drill fixes which miss

If none of these match what you see, the drills' practice aids can slow the tick down so you can watch each press land. Slowed runs do not rank. The prayer flick trainer guide sets out the whole Ward Flicking ladder in order, with what each level trains. For alternating styles, the same window rule decides when a protection switch has to land.

Quick answers

Why does my prayer flick not work?

Almost always because a click landed on a different tick from the one you meant, not because you were too slow. The usual causes are a click in the window before or after the right one, two taps split across ticks or doubled on one, a silent count that drifted, and in the live game, latency.

Does ping affect prayer flicking?

In the live game, yes: your clicks are processed by the game server, and the OSRS Wiki puts typical ping to the nearest world at roughly 20 to 150 ms. Clicks in the last moments of a window are the first to slip, so aim earlier. In Microgrind the tick clock runs in your browser, so a slow connection cannot move a click to another tick.

Why does my 1-tick flick fail?

Usually because the off-and-on pair was split across a tick boundary. If the first press of the pair is a little early, it lands on the first shot's tick together with the raise and drops the ward before that shot is checked. Both presses have to sit inside a single window.