FairPlay Scaffold Click Cadence Checks Explained

What do the click cadence checks watch?

Click cadence checks watch the rhythm of block placements. Six FairPlay checks sit here: ScaffoldFastPlace, ScaffoldDelayVariance, ScaffoldPlaceBurst, ScaffoldClickPattern, ScaffoldRightClickPattern and ScaffoldPostSwing. They compare how quickly placements follow each other, how even the gaps are, and whether placements arrive in bursts or right after an arm swing.

Which click rhythms do they target?

These checks target placements that come too fast, too evenly or in tight bursts. Each one looks at a different slice of the same rhythm, so a single alert rarely tells the whole story.

• Placements that follow each other faster than the check's expected bridging pace (ScaffoldFastPlace).
• Gaps between placements that stay too even (ScaffoldDelayVariance).
• A dense cluster of placements inside a short span (ScaffoldPlaceBurst).
• Repeating click timing patterns across recent windows (ScaffoldClickPattern).
• Right-click rate and steadiness during placement-only clicks (ScaffoldRightClickPattern).
• Placements that arrive right after an arm swing (ScaffoldPostSwing).

What legitimate clicking can resemble these checks?

Fast, steady clicking is a normal part of bridging for many players. Lag and network jitter also change the rhythm the server sees, because placements can arrive in bunches after a delay.

• Experienced bridgers who hold a steady right-click rhythm.
• Lag that delays several placements, then delivers them together.
• Mobile players who hold a tap with steady timing.
• Combat that mixes swings and placements in one short span.
• Client-side timing that differs from what the server receives.

How should staff read click alerts?

Click alerts are easiest to read next to latency. A burst that appears only when the player's connection drops is a different case from a burst on a stable connection. Look at the session, not the single moment.

• Check the player's latency during the alert, if your tools show it.
• Note whether the placements happened in combat or during pure bridging.
• Compare the rhythm across several bridges and sessions.
• Ask the player to repeat the bridge on their normal connection.
• Log the outcome and the reason for clearing or escalating.

What should you tune only in staging?

Click checks depend on how placements are timed and how many are needed before an alert. Change those settings only on staging. Test steady bridging, bursts, combat mixed with placements, and a session with added latency on your own test connection. Compare output before and after each change.

How do lag and client type change the click rhythm?

Lag changes the rhythm the server sees. When a connection stalls, several placements can reach the server together, which looks like a burst even though the player clicked at a normal pace. Mobile players often hold a tap instead of clicking, and that hold can produce steady timing that looks unusual next to a mouse. Controller and keyboard setups add their own habits.

Build staging routes with added latency on your own test connection. Run the same bridge with a stable connection, with a delayed connection and on a mobile client, then compare the alert output for each run. A burst that appears only under lag is a different case from a burst on a stable connection.

• Stable connection, mouse: the baseline rhythm for steady bridging.
• Delayed connection, mouse: expect bunched placements when the stall releases.
• Mobile client with taps: expect steadier timing than a mouse user.
• Combat mixed with placements: note the swings, because post-swing timing shifts with them.

What belongs in a click alert review?

A click review needs the rhythm and the context together. Note the number of placements in the burst, the spread of the gaps, whether combat was happening and the connection state. A burst inside a fight and a burst on a quiet bridge are different situations, and the notes should say which one it was.

Review more than one alert before deciding. A single burst during a lag spike is weak evidence. A rhythm that repeats across quiet bridges on a stable connection is worth a longer look.

Keep the session length the same across runs. A longer session can change how bunched the placements look, so a fair comparison needs equal session length, equal bridge length and the same device. Log the connection type and the device with each run so the results stay comparable when you revisit them later.

• Number of placements in the burst.
• Spread of the gaps between placements.
• Combat or pure bridging at the time of the alert.
• Connection state, such as stable, lagging or reconnecting.
• Input device, and whether taps or clicks were used.

What have we not verified?

No detection rate, error rate or staging result is reported here. The description covers what each check measures. Confirm how the checks respond to latency and to your players' clicking on your own server before relying on them.