Ask the game whether a blueprint grid position moves its entities, and pin it

[wormeyman]

PR #222 adds a second X/Y pair to the alignment dialog, "Grid position", separate from the pair beside Absolute. Its premise, written into Blueprint.translateEntities and tests/blueprint-grid-position.spec.ts:

typing into "Grid position" writes NO blueprint field at all. It moves every entity's own position by the NEGATION of whatever was typed, baked straight into the exported entity coordinates, then resets to 0.

That was inferred from a screenshot of the game's dialog rather than measured, and it is the whole reason translateEntities and Entity.forceMoveBy exist. #226 measured which snapping mode carries position-relative-to-grid; it never touched this.

The answer

Measured on 2.0.77, the binary #226 used. Two chests at (0.5, 0.5) and (8.5, 8.5), snapping on, absolute:

grid position set	model after	exported	round-tripped	position-relative-to-grid
none	#1(0.5,0.5) #2(8.5,8.5)	same	same	absent
{0, 0}	#1(0.5,0.5) #2(8.5,8.5)	same	same	absent
{3, 5}	#1(0.5,0.5) #2(8.5,8.5)	same	same	{3, 5}
{10, -7}	#1(0.5,0.5) #2(8.5,8.5)	same	same	{10, -7}

Setting a grid position moves no entity. The game writes the key and leaves every coordinate alone. So position-relative-to-grid is the whole feature and there is no second thing to model.

The control is the part worth reading

A result like this is mostly zeros, and zeros are what a broken probe produces too. The shifted-entities case places the same two chests three tiles left and four up through set_blueprint_entities, touching no snapping property:

baseline         #1(0.5,0.5)   #2(8.5,8.5)
shifted-entities #1(-2.5,-3.5) #2(5.5,4.5)

Without it, "the coordinates never changed" reads identically whether the finding is real or the probe is comparing a value with itself. That is the #133 item 4 lesson in its null-result form, and it is the only reason the zeros above are evidence.

One new API fact

#226 found that setting blueprint_position_relative_to_grid turns blueprint_absolute_snapping on, and warned to set position before absolute.

This found the reverse: setting blueprint_absolute_snapping = false clears the position. The readback control caught it on the one relative row in the sweep, which came back holding no position at all. That row is recorded and left unscored rather than counted as "did not move", per #133 item 4, since asking whether its grid position moved anything is a question about a value that is not there.

It also confirms #226 from the opposite direction: relative snapping cannot carry a position because the game takes the position away, not only because the exporter drops it.

What it changes

Nothing in packages/. This is measurement, and tests/ stays offline as always.

What it changes is #222, where two blockers I raised turn out to resolve by deleting code rather than fixing it. That is written up in the PR.

Also adds the probe-blueprint-snapping.mjs row that #226 left out of the script table.

Verification

vp check          0 errors, 0 warnings, 174 files
vp test           180 passed (13 files)

Two consecutive captures of the fixture are byte-identical, so a third that disagrees is a finding rather than noise.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DxZFeyzpXmxjwVHXxDo8zb