FairPlay Scaffold Placement Geometry Checks Explained

What do the placement geometry checks watch?

Placement geometry checks compare where a block lands with the player's body, the face that was clicked and the line of the bridge. Seven FairPlay checks sit in this group: ScaffoldPositionPlace, ScaffoldInsidePlace, ScaffoldInvalidGeometry, ScaffoldImpossiblePlace, ScaffoldInvalidPlace, ScaffoldCardinalDistance and ScaffoldBridgeBalance. Each one flags a combination of position and placement that the expected geometry does not explain. None of them decides intent by itself.

Which scaffold and bridge behaviors do they target?

These checks aim at placements that seem to come from a position the player could not occupy, or at blocks that appear inside or beside the player's own space. Several of them also look across a short run of placements, because a steady bridge leaves a different geometric trail than a player who moves sideways, backward or straight up.

ScaffoldInvalidPlace compares placements with the player's recent horizontal movement. ScaffoldCardinalDistance checks how far the placed block sits from the player along one of the four compass directions.

• A block placed from a side of the clicked face that the player's position does not support (ScaffoldPositionPlace).
• A block that appears inside the player's body or eye area (ScaffoldInsidePlace).
• A placement whose resulting position is invalid for the block placed (ScaffoldInvalidGeometry).
• A placement rate that the player's movement does not explain (ScaffoldImpossiblePlace).
• A bridge line that drifts from a steady horizontal offset over several placements (ScaffoldBridgeBalance).

What legitimate building can look like these checks?

Several normal building styles put the player in an unusual spot at the moment of placement. A player who places from a rising or falling body, moves in a tight zigzag, or builds straight up can produce geometry that resembles a cheat. The checks cannot see the reason behind that position, so the reason has to come from staff.

• God-bridging, where the player jumps and places blocks from a rising or falling body position.
• Ninja-bridging, which alternates the bridge direction and the body offset quickly.
• Tower-ups, where the player places a column almost straight up under their own feet.
• Mobile and Bedrock input, where the tap position and camera angle differ from a desktop mouse.
• Lag, which can delay the server view of the player's position until after the block is placed.

How should staff read these alerts?

Read an alert as a question about one placement, not as a verdict. Open the alert details, note the block, the face, the position at placement and whether the player was jumping, sprinting or climbing. Then look at the same player across several separate bridges. One geometry alert during a jump or tower-up is weak evidence. A repeated odd offset across long bridges, in calm conditions, is a better reason to review.

• Record the client type, if the player has told you or your tools show it.
• Check whether the player was jumping, sprinting or climbing at the placement.
• Compare the same geometry across several bridges on different days.
• Ask for a short screen recording of a normal bridge when the case is unclear.
• Write the decision and the evidence in your staff log, including alerts you clear.

What should you tune only in staging?

Any geometry-related setting changes how often these checks alert on normal building. Change those settings only on a staging server, using test accounts. Run a fixed routine of god-bridges, tower-ups, straight bridges and a mobile or Bedrock session before and after each change. Keep a copy of the original settings so you can compare alert output side by side.

Do not copy tuning from another server. Versions, client mix and player habits differ, so a setting that looks reasonable elsewhere may not fit your network.

How do geometry alerts fit with the other scaffold groups?

Geometry alerts describe where a block sits. They do not describe how the camera moved or how the clicks were timed, so a useful review pairs this group with the other scaffold groups. A geometry alert with a calm camera history and a steady click rhythm reads differently from one that appears next to sharp turns or bursts.

When the same player shows up in several groups, check whether the alerts share a time window or a bridge. Shared timing points to one situation, such as lag or a long session. Separate alerts on separate days point closer to a habit, and that deserves a longer review.

• Pair geometry alerts with the cursor aim group when the placement sat on a block edge.
• Pair them with the camera rotation group when the alert happened during a turn.
• Pair them with the movement momentum group when the player was sprinting or jumping.
• Keep a note of which groups fired, even when the final decision is to clear the case.

What have we not verified?

This page does not publish detection rates, error rates or results from any specific cheat. It describes what each check compares, based on the check names. Confirm the behavior on your own server, with your own versions and clients, before you rely on a geometry alert for enforcement.