Snap Points

A snap point is a named connector on a library object. Where the generic bounding-box magnetism just aligns edges, snap points carry meaning: a conveyor’s roller output mates with a roller input of the same type, and with nothing else.

That is what turns placing objects into assembling a line. Drag an object near a compatible partner and the planner reveals the matching connectors, pulls the object into the aligned pose, and locks both ends into a connection so the two move as one chain from then on.

What makes two snaps compatible

Two conditions, both required:

The type matches. Each snap carries a type id — convroll, belt, flange-1, whatever the author chose. The match is exact and case-sensitive.
The flows fit. Every snap is an input, an output or bidirectional:

input output bidirectional
input ✗ ✓ ✓
output ✓ ✗ ✓
bidirectional ✓ ✓ ✓

Two inputs or two outputs would clash, so they never engage.

	input	output	bidirectional
input	✗	✓	✓
output	✓	✗	✓
bidirectional	✓	✓	✓

Two things are deliberately not compatibility filters. The axis in the snap’s name is only a hint for choosing between several matches — the actual outward direction is derived from where the connector sits inside its object, which is what makes snapping survive rotation. And a snap that is already occupied is simply excluded, so a connector never takes a second partner.

Snap points are authored, not drawn

Snap points come from the model. They are empty nodes whose name encodes their role, in the form Snap-<AXIS><FLOW>-<TYPEID>:

Name	Meaning
`Snap-ZN-convroll`	Z-axis input for type `convroll`
`Snap-ZP-convroll`	Z-axis output for type `convroll`
`Snap-ZB-convroll`	Z-axis bidirectional `convroll` snap — a turntable, for example
`Snap-XB-flange-1`	X-axis bidirectional connector of type `flange-1`

N is input, P is output, B is bidirectional. There is no separate metadata to maintain — rename the node and you have changed the connector.

Snapping while you drag

Drag an object and the planner looks, every frame, for the closest compatible pair within the magnet radius (400 mm by default). When it finds one, the dragged object is placed snap-aligned to its partner. Release and the connection is recorded.

Three snap systems can be active at once; when more than one applies, the stronger wins: snap points override bounding-box snap, which overrides grid snap.

Visual feedback comes before the commitment. Matching connectors on nearby objects appear as markers as the cursor comes near them, and the planner’s Show All Snaps toggle pins every free marker visible regardless of hover.

A roller-conveyor layout in the planner with Show All Snaps on: a green marker sits at every free connector — the open ends of the conveyors and the turntables — while the ends that are already joined carry none

You can also work the other way round: click a free snap marker and pick from a popup that lists only the library entries which actually have a compatible connector — the catalog filtered down to what fits, whether it comes from the built-in library, a local folder or a remote catalog.

Chain mode

With chain mode on (the default), dragging one object of a connected line moves the whole chain with it, each member keeping its exact relative position. Hovering an object in a chain lights up everything that would move, before you have moved the cursor at all.

Two ways to move one object on its own:

Hold ALT while dragging. The object is detached from its connections and moves solo.
Turn chain mode off. Same effect for every drag.

Either way the connections that object had are severed — a solo drag is a decision to disconnect, not a temporary exception.

Connections are also released when the object is deleted, and when a drag stretches an edge far beyond the magnet radius.

Flipping an object’s orientation

A placed object with two compatible connectors of the same type — a belt with an inlet and an outlet, for instance — can be turned around its connection without being deleted and placed again. The object is unpaired from the connector currently in use, rotated 180°, and re-paired through the other one.

Two ways to trigger it, both doing the same thing:

Right-click the object → Flip orientation (180°). The entry appears only when the object is actually paired through one connector and has a same-type sibling connector.
Click the circular-arrow icon that appears above a flippable object while you hover or select it. It disappears while you drag with the gizmo so it does not compete with the transform handles. The icon can be switched off with the visual setting Show snap-flip icons; the context-menu entry is always there.

Flipping twice restores the original pose exactly. It is blocked while the simulation is running, because drives may be moving the hierarchy at that moment. The new position is recorded like any other layout change, so it undoes, saves and replicates to other participants normally.

Objects with three or more compatible connectors — crossings, junctions — are not covered by the flip.

Rules a placement has to satisfy

Before a placement through a snap marker commits, the planner checks that:

the target connector is free,
the object has the connector it is being placed by,
the two type ids are identical,
the flows are compatible,
the object has uniform scale — a non-uniformly scaled object cannot be rigidly aligned without skewing.

A failure is reported inline in the picker with its reason, rather than producing a placement that looks almost right.

Locked objects

Every placed catalog item carries a Locked flag. With it set:

Edits to anything inside the object are rejected — nested drive, sensor or signal properties cannot drift away from the catalog defaults.
The object’s own row stays editable, so you can clear the flag in the inspector without unwinding anything first.
Transform, set-position and delete actions skip locked objects.

Deleting a placed object also discards every property override stored under it. Placing the same catalog item again therefore starts from the model’s own defaults — nothing leaks across from the previous instance.

Persistence

Connections are not stored as a separate table. They are rebuilt on load from the placed objects and the connectors in their models, which means a saved layout comes back with exactly the chain graph it had.