Paste mixed two frames. The pointer comes from the Scene View, which
draws every object moved by the editor offsets of it and its parents.
Paste turned that point into a local position through the parents'
plain world transform, so the copy landed beside the pointer by the
offset of the parent it went into. Without a pointer, an original with
an offset of its own had its copy placed beside its game position,
which the view does not show.
- A copied root now remembers where the view showed it
(`ClipRoot.shown`, from `editorTransform`) instead of its world
position.
- New `editorLocalPositionFor` in `properties/transform.ts` turns a
shown point into a local position through the parent chain with the
editor offsets, as the view draws it. Paste uses it.
- The copy itself still gets no editor offset of its own, as since
#240. In the game it stands where it was drawn, minus the offsets of
its parents.
- Re-parenting under a parent with an offset still keeps the game
position, so the object jumps in the view by that offset. That is a
different rule from paste and is left as it is.
Tests:
- Unit (clipboard, groups, references, transform): 50 passed, 2 new.
- e2e 51 on melektaus-atx: ALL PASSED, 12 checks, 1 new (51f).
- Gate on melektaus-atx: 195 files, 2829 tests, CHECK EXIT 0.
- Counter-checks: without the paste fix both new unit tests fail
(copy at 540/470 instead of 500/500) and 51f fails by exactly the
60/-40 offset. With the root remembering its world position again,
the own-offset unit test fails.
- No full run. The e2e total of 1591 is 1590 plus 1.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Copy and paste only existed for animation keys. Building a scene or a
graph meant placing every object and node again by hand, even when the
same arrangement was needed twice.
- Ctrl+C copies the selected objects with their whole subtree, or the
selected nodes with their links, groups and comments. Ctrl+V pastes
into the scene, container or graph of the visible tab.
- The copy is a snapshot in the editor's own clipboard, in memory. It
holds asset ids, so the system clipboard is not used. It is cleared
when another project opens.
- A paste lands under the mouse pointer when it is over the view, and
keeps its arrangement. Otherwise it lands one grid step beside the
original. Each further copy that still exists moves one step on, so
an undone copy does not count.
- Objects get new ids for the whole subtree. They paste into the one
selected object and keep their look under the new parent. If that
object is the original or an earlier copy, the paste lands beside it
instead of nesting deeper with every Ctrl+V.
- A placed container stays a container. Content copied out of a
container pastes as plain objects. Pasting a container into its own
template is refused.
- Nodes paste only where the palette would offer them. A second Start
or End, a State in a behavior or a behavior calling itself is left
out, and a notice names what was dropped.
- Menus: Copy and Paste in the object menu, a new Paste menu on empty
scene space, Copy in the node and box menus, Paste in the palette.
- Ctrl+V still imports a picture from the system clipboard when the
copy does not fit the tab. While objects are copied, the scene and
container tabs use Ctrl+V for them, as the timeline does for keys.
Not checked in the browser: paste in the container tab, in state
machine, shader and particle graphs, and from the hierarchy menu. The
shared code path covers them.
Tests:
- ./check.sh: 175 files, 2531 tests, CHECK EXIT 0
- e2e 51 (new): ALL PASSED, 11 checks with real keys and clicks
- 13 unit tests in tests/editor/clipboard.test.ts, one of them pins
the grid step after undo found during e2e
- 7 counter-checks all fail as expected (6 unit, 1 in the browser)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
adminandClaude Opus 5.5