FairPlay Scaffold Camera Rotation Checks Explained

What do the camera rotation checks watch?

Camera rotation checks watch how the view turns between placements. Seven FairPlay checks sit here: ScaffoldRotation, ScaffoldCumulativeRotation, ScaffoldRapidRotations, ScaffoldRotationCombo, ScaffoldRepeatedPitch, ScaffoldZeroYawHighPitch and ScaffoldRotationGcd. They compare turn size, turn speed, pitch repetition and the shape of yaw and pitch changes against the blocks placed.

Which camera patterns do they target?

These checks target placements that happen while the camera moves in an unusual way. Some look at one large turn, others at totals across a bridge line, and others at small values that repeat.

• Large camera changes clustered around placements (ScaffoldRotation).
• Total turning across a bridge line, compared with the blocks placed (ScaffoldCumulativeRotation).
• Very quick yaw and pitch changes between placements (ScaffoldRapidRotations).
• Yaw and pitch changing together in a short burst, noting whether the player was bridging on the ground (ScaffoldRotationCombo).
• Pitch that repeats the same value across placements (ScaffoldRepeatedPitch).
• Zero yaw paired with a high pitch at placement (ScaffoldZeroYawHighPitch).
• Camera step sizes that share a common pattern (ScaffoldRotationGcd).

What legitimate camera movement can resemble these checks?

Camera movement is part of normal bridging. Players look ahead to the next line, keep the pitch high on tower-ups and make small corrections between blocks. Mouse setup and touch input also shape the steps the server sees.

• Players who turn to look ahead to the next bridge line during a quick bridge.
• Tower-ups, where the pitch stays near one high angle for many placements.
• Players with a steady mouse setup, whose turn steps can look regular.
• Players who strafe while looking down during a god-bridge.
• Touch camera drags on mobile, which arrive as larger, uneven steps.

How should staff read rotation alerts?

Rotation alerts often cluster. Check whether one bridge produced many alerts, or whether many bridges each produced one. A cluster on one bridge points to a single unusual moment. An alert spread across the session points to a habit worth a closer look.

• Count alerts per bridge, then per session.
• Check the player's movement and whether they were jumping or sprinting.
• Compare the same camera pattern with the player's normal bridging on other days.
• Ask about mouse, touch or controller setup before reading a step-size alert.
• Record the outcome in the staff log, including cleared cases.

What should you tune only in staging?

Rotation checks depend on how many recent placements and camera samples they hold, and on the size of the changes they consider. Change those settings only on staging. Test a regular bridge, a tower-up, a camera-heavy bridge and a mobile session, and compare alert output before and after every change.

How do bridge shapes change rotation patterns?

Each bridge shape asks the camera to do something different. A straight bridge keeps the yaw nearly fixed, while a diagonal bridge sweeps it through a range. A tower-up keeps the pitch near one value for many placements, and a god-bridge swings the pitch across each jump. Reading an alert without this context usually leads to the wrong conclusion.

Mouse and touch input add a second layer. A mouse gives small, regular steps on a steady setup. Touch gives larger, uneven steps. A controller gives steps that depend on the stick response. Ask which device the player used before comparing their steps with another player's.

• Straight bridges: a fixed yaw is expected, so judge the size of the occasional turns.
• Diagonal bridges: a sweeping yaw is normal, so repeated sweeps alone prove little.
• Tower-ups: a repeated pitch is the shape itself, so compare it with the player's other towers.
• God-bridges: pitch swings at each jump, so line up the alert with the jump timing.

What mistakes do staff make when reading rotation alerts?

Most mistakes come from treating one alert as proof or from comparing unlike situations. The list below covers common errors that reviewers can make. Use it as a checklist before you write a decision in the staff log.

• Reading a single alert as proof instead of one data point in a pattern.
• Comparing a tower-up with a flat bridge and expecting the same rotation pattern.
• Ignoring the input device the player used during the alert.
• Forgetting that latency can bunch camera samples and make a normal turn look sudden.
• Clearing a case without writing down the bridge shape and the device.

How long should a rotation review run?

A short look at one bridge rarely settles a rotation question. Watch several bridges of different shapes in one session, then compare that session with the same player on another day. Note how long the review ran and whether the alerts came from the bridge itself or from a side activity such as combat or travel. Keep that note specific so the next reviewer can repeat the same watch.

If the watch ends early, write down why. A cut-short review is still useful evidence about what was checked, and it stops a partial look from being read as a full one.

• Watch flat, diagonal and tower-up bridges within one session.
• Compare the session with another day of the same player.
• Note any combat or travel that happened during the watch.
• Record the reason when the watch ends before the plan is complete.

What have we not verified?

This article reports no detection rate, error rate or staging result. The behaviors described come from the check names and what each one compares. Confirm them on your own server with your own client mix before using any rotation alert as evidence.