Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Creators-of-Create/Create/llms.txt
Use this file to discover all available pages before exploring further.
BlockMovementChecks (in com.simibubi.create.api.contraption) provides five functional-interface registries that control how blocks interact with contraption assembly. When a contraption assembles, Create evaluates each registered check in reverse-registration order — the last check registered has the highest priority. The first check to return a non-PASS result wins; if all checks return PASS, Create falls back to its built-in heuristic.
All registration methods are thread-safe and can be called during parallel mod initialisation.
CheckResult enum
Every check returns one of three values:| Value | Meaning |
|---|---|
CheckResult.SUCCESS | Explicitly allow — this block passes the check |
CheckResult.FAIL | Explicitly deny — this block fails the check |
CheckResult.PASS | No opinion — defer to the next check (or the built-in fallback) |
Check types
MovementNecessaryCheck
FAIL for a block, the contraption assembler treats it as if it were air — the block is skipped and left in place. This is useful for blocks that should always be ignored during assembly (e.g., lightweight decorative blocks that clip through without causing problems).
MovementAllowedCheck
FAIL, the block is treated as immovable — attempting to assemble a contraption that includes this block will fail outright (the contraption cannot form).
Use this to protect blocks that must never move (e.g., spawn anchors, custom world anchors, or blocks with global state that would break if relocated).
BrittleCheck
SUCCESS for blocks that should be treated this way.
AttachedCheck
direction — meaning both blocks should be collected together as a unit. Create uses this to pull in multi-block structures, vine-covered walls, bed halves, and fluid tank groups.
Return SUCCESS if the block at pos is attached towards direction (and the block in that direction should therefore also be collected). Return PASS to defer to Create’s default attachment logic.
Common examples from vanilla Create:
- Ladders are attached to their support block.
- Pressure plates are attached to the floor beneath them.
- Fluid tanks are attached to adjacent tanks in their multi-block.
- Bed halves are attached to each other.
NotSupportiveCheck
SUCCESS to declare that state’s direction face is non-supportive (blocks beyond it won’t be collected). Return PASS to use Create’s built-in logic.
Common examples from vanilla Create:
- Drills are non-supportive on their front face (blocks being drilled are not collected with the drill).
- Carpets are non-supportive on their top face.
- Non-extended sticky pistons are non-supportive on their front face.
Registering checks
Call the appropriate staticregister* method on BlockMovementChecks during mod initialisation. Lambda syntax works well for simple checks.
All five
register* methods are thread-safe. You may call them at any point during parallel mod initialisation without synchronisation.Full registration reference
| Method | Check interface | Query method |
|---|---|---|
BlockMovementChecks.registerMovementNecessaryCheck(check) | MovementNecessaryCheck | isMovementNecessary(state, world, pos) |
BlockMovementChecks.registerMovementAllowedCheck(check) | MovementAllowedCheck | isMovementAllowed(state, world, pos) |
BlockMovementChecks.registerBrittleCheck(check) | BrittleCheck | isBrittle(state) |
BlockMovementChecks.registerAttachedCheck(check) | AttachedCheck | isBlockAttachedTowards(state, world, pos, direction) |
BlockMovementChecks.registerNotSupportiveCheck(check) | NotSupportiveCheck | isNotSupportive(state, direction) |
Priority and ordering
Checks are evaluated in reverse-registration order. The check registered last is evaluated first. This means your addon’s checks will naturally override Create’s built-in defaults, which are registered at startup before any addon code runs.