A Tower Creator pushbox pattern uses a source object, a Clone Object Reference, an activation input such as a Trigger Button, and usually a way to remove or reset spawned clones. Build the first version on a flat enclosed test floor. Spawn one clearly colored box, confirm the player can move it, then remove or reset it before adding a goal, multiple boxes, or a larger puzzle.
Prepare the source box and test floor
Create a simple box with visible collision and enough space around every side. Avoid decoration, slopes, conveyors, or narrow doorways during the first test. Place low walls around the floor so the object cannot fall out of reach while you learn its physics.
Choose a spawn location that is not inside the player, a wall, or another object. Mark it with a distinct non-collidable visual guide if the current properties allow. Place the source or reference geometry away from the live route so the player interacts only with the spawned object.
Record the source object’s size, color, collision, anchoring or physics-related state, and version. Community sources describe cloned pushboxes as inheriting properties from a linked part, but the exact transferable fields must be tested in the current build.
Connect the minimal spawn chain
Place the current Clone Object Reference and a supported activation input. Community Rescripted notes describe Trigger Button as an activator and mention multi-spawn behavior on clone references. Use the live linking interface to connect the input, reference, and source in the order it shows.
Leave Edit Mode and activate once. Confirm exactly one box appears at the intended location. Activate again only after identifying whether the puzzle should replace, ignore, or add another box. Multiple spawns can create collisions and performance problems, so keep them disabled unless the design needs them and the current property is understood.
If nothing appears, replace the input with the simplest supported option, remove delays, and recheck every link. If the box appears in the wrong place, fix the source or reference transform before changing physics.
Make the box movable and readable
Test pushing from each side using ordinary player movement. The box should move predictably without launching, tunneling through walls, or pinning the player. Adjust geometry and the current physics-related properties in small steps. Do not paste historical density, friction, elasticity, or mass values without verifying how the live object interprets them.
Use shape and color to distinguish the pushbox from scenery. Show the destination with a matching outline, recess, or label. Make the route wide enough for the player to get behind the box. A puzzle that can become stuck in a corner needs an accessible reset.
Test the lowest and highest slopes in the route, doorway clearance, contact with other moving parts, and behavior after the player jumps onto the box. Add only one complexity at a time.
Add a goal, remover, and reset
Define what completing the puzzle changes: open a door, activate a visible part, allow a button, or clear a path. Build that result independently before connecting it to the box. Then choose a current input that can detect the intended pushbox interaction, such as contact or a color-specific check where the live object supports it.
Community documentation names Clone Object Destroyer or Remover for cleaning up clones. Place it where failed boxes can be deliberately removed without destroying the source. Test whether it removes only the clone and whether a new activation creates a clean replacement.
Provide a visible reset control near the puzzle entrance. Reset should remove extra boxes, restore the goal state, and allow another spawn. Test reset before completion, after completion, and while two boxes exist if multi-spawn is possible.
Test failure and multiplayer cases
Push the box into every wall and corner. Drop it from the highest point the route permits. Reset the character while touching it. Leave the area and return. Rejoin the server. The goal is not to prove that failure is impossible; it is to make failure recoverable.
With two players, test simultaneous pushes, one player activating while another stands at the spawn, and repeated reset. Decide whether spawned objects and goal state are shared. A client-visible box that another player cannot see or move should not control a shared required route.
If multiplayer differs from solo, simplify to one box and one flat corridor, record the exact current objects, and ask for current-version guidance rather than adding more triggers.
Pushbox troubleshooting
Move the working test into the tower
Copy the system only after spawn, movement, goal, reset, multiplayer, and rejoin checks pass. Inspect every copied link because a duplicate may still point to the original source or remover. Build the route around the pushbox with extra clearance, then test from the real entrance.
Keep a known-good backup before integrating the puzzle with a cutscene, camera, or timed door. If a presentation layer fails, the physical pushbox should still have a safe reset. Continue with the Cutscene tutorial only when the puzzle works without it.
Current confidence boundary
Clone Object Reference, clone removal, Trigger Button activation, multi-spawn concepts, and pushbox usage are community reported in Rescripted-era Parts and update documentation, with visual support from a 2026 trigger walkthrough. Exact wiring, inherited properties, collision ownership, reset, and rejoin behavior require a current in-game test.