Click Randomization

When click randomization is enabled in your macro settings, TapForge doesn't tap the exact center of a matched object every time — it picks a slightly different spot within the object on each run.

Which functions are affected?

When the toggle is on, randomization applies to every tap and gesture. Where TapForge knows the size of the object being tapped, the offset scales to it; for raw coordinates it uses a small fixed offset instead:

• findAndTap — randomized. The match gives TapForge the object's width and height, so jitter is applied before the tap fires.
• findAndLongPress — randomized. Same as above: match-based, dimensions are known.
• tapAt("objectName") — randomized. Same as above: the object's dimensions are known.
• tapCurrentMatch() — randomized. The match data from findAllObjects is used.
• tapAt(x, y) / longPress(x, y) with raw coordinates — randomized with a small fixed offset. TapForge has no object size to scale against, so it applies a fixed ±8 px jitter around the point you specify. Pass randomizeClickRadius to set your own radius per call.
• swipe — randomized. The whole gesture is shifted by a small fixed offset (start and end move together, so the swipe's direction and length are preserved).

What exactly gets randomized?

Only the touch position (X and Y coordinates). For a matched object, the offset is sampled from a uniform circular area centered on the match whose radius is 25% of the object's smaller dimension — so on a 100×60 px element, touches can land anywhere within roughly 15 px of center. For raw coordinates the same uniform-disc sampling is used with a small fixed radius (±8 px), or whatever randomizeClickRadius you pass. The distribution is flat across the whole circle, not concentrated in the middle, so you get genuine spread rather than clustering.

What is never randomized?

• Timing — delays between steps are not affected. If you want variable timing, add a wait with a range in your script (or use the randomizeDelay option).
• Text input and key events — no randomization applies.

Why enable it?

Games that track repeated input patterns may flag or rate-limit actions that land on the exact same pixel every time. Randomization makes each tap land in a slightly different spot, which looks closer to natural human input. It also helps if a button has a slightly different hit area at runtime than the center of your template suggests.

Does it affect accuracy?

It shouldn't for any reasonably sized element. For matched objects the jitter stays within the object's bounds, and on a very small target — say, under 20 px — the radius collapses proportionally, so the spread is still contained. For raw coordinate taps the fixed ±8 px offset is deliberately small; if you're tapping a tiny on-screen control by coordinate and see misses, lower it with randomizeClickRadius. If you see missed taps on a matched object, check whether it's being found at the right position first (use findObject to inspect the match) before suspecting randomization.