Allow part configurations to be copied and pasted with the Wrench

[rubensworks]

Closes #859

What

The Wrench gains three configuration modes. Shift+right-clicking a part copies into the Wrench, right-clicking another part pastes.

Mode	Copies	Paste target
Copy All	settings + aspects	same part type only
Copy Settings	update interval, priority, channel, target side, target offset, and the offset variables	any part
Copy Aspect	the active variable, the aspect properties, and the aspect setting variables	any part

Every variable inventory belongs to exactly one section, so the offset variables travel with the settings and the active and aspect setting variables travel with the aspects. Copy All is exactly Copy Settings + Copy Aspect.

Only non-default values are copied. A setting left alone on the source part is not stored, so pasting never resets it on the target. Copying a part that is still entirely default says so instead of storing an empty configuration.

Blank Variable Cards are checked before anything is consumed. Each pasted card costs one blank Variable Card (skipped in creative). If there aren't enough, the settings still apply, the cards are skipped, and the player is told how many more are needed. The Wrench tooltip lists the requirement up front, scoped to what the current mode will actually paste:

Wrench
Mode: Copy All
Copied from: Redstone Writer
Includes: settings, aspects
Blank Variable Cards needed: 1

The active mode is visible on the item — a small coloured badge per mode in the corner of the Wrench texture, driven by a wrench_mode item property and one model override per mode.

Cards already in the target part are given back to the player (dropped if the inventory is full), and pasted cards always get a new variable id.

Implementation

• core/part/PartConfigSection: PART_SETTINGS and ASPECT, plus forInventoryName which decides which section a variable inventory belongs to.
• core/part/PartConfigSnapshot: versioned, codec-backed, stored as a CompoundTag in a new wrench_part_config data component. Every part setting is an Optional, so absent means "was default, don't touch".
• core/helper/PartConfigHelpers: snapshot/apply, non-default filtering, card copying, blank consumption, inventory resolution.
• IPartType#snapshotConfig / #applyConfig and IPartState#getDefaultUpdateInterval, all default methods so addons keep compiling.
• The paste result reports what was actually applied; warnings (offset out of range, skipped cards) go to the chat, since together with the result line they do not fit on the action bar.

Tests

• Unit tests for the snapshot codec roundtrip, the non-default part settings, and the inventory-to-section mapping.
• 17 game tests in GameTestsWrenchConfig: full copy/paste, part type mismatch, each mode in isolation, the offset variables belonging to Settings and the active variable to Aspect, subset across part types, card ids and ejection, insufficient blanks, creative, out-of-range offset, copying a default part, pasting not resetting untouched settings, sneak-clicking not removing the part, and mode cycling.

./gradlew build passes and all 959 game tests pass.

Verified in a dev client

Driven with clientdevbridge-cli. Confirmed in-game: the six mode badges are distinct; each mode's tooltip lists only what that mode pastes; a part with a changed update interval and an active variable copies as partSettings:{updateInterval:40} under Copy Settings, as variableCards:[$active] under Copy Aspect, and as both under Copy All; a default part reports nothing to copy; sneak-clicking in a config mode copies without removing the part; the full mode refuses a different part type while the subset modes accept it; and with no blank cards the settings still apply with the warning legible in chat.

Three bugs were found and fixed this way: the subset modes fell through to the part-removal branch, the combined result message ran off both edges of the screen, and the counts read as "1 blank Variable Cards".

🤖 Generated with Claude Code

https://claude.ai/code/session_01LBAgcFp6jWcYRWz9N8h7AF

[coveralls]

coverage: 48.022% (+1.1%) from 46.886% — claude/wrench-part-config-copy-paste-7u5bus into master-1.21-lts

[rubensworks]

Also do these things:

• Even when the default of offset mode is shown, it shows in the tooltip the copied target and "Included". This is not necessary; hide it for those modes.
• Can you manually test using clientdevbridge that this copying also works correctly for Integrated Tunnels interfaces, exporters, and importers?
• Don't modify the changelog yourself.

[rubensworks]

Regarding max offset, could we make it so that offset enhancements can also be copied? And then taken care of in the same way as variables; the player needs the correct amount of them to paste. It also needs to be shown in the tooltip.

[rubensworks]

Done in 74649c1. The maximum offset is now part of PartSettings (so it belongs to the Copy Settings section), stored only when it is above the default of zero.

Pasting raises the target part to that maximum offset by consuming Offset Enhancements from the player, in the same shape as the variable cards: if the player is short, nothing is consumed and PartConfigApplyResult reports how much value is still needed, as a chat warning. A target that already has a higher maximum offset is left alone, and creative players do not pay. Applying it happens before the target offset, so the copied offset now lands instead of failing on a fresh part.

One thing worth flagging: enhancements cannot be split, so if the player only has enhancements that do not add up exactly (needing 8, holding a 4 and a 5), they spend 9 and the part gets 9. consumeOffsetEnhancements takes the smallest ones first to keep that waste as low as possible.

The tooltip shows Offset Enhancement value needed: N next to the blank card requirement, for the sections the current mode pastes. Covered by five new game tests (consuming, insufficient, creative, keeping a higher existing offset, and the Aspect mode not touching it) plus unit tests for the new snapshot field.

---

Generated by Claude Code

[rubensworks]

Please move this to the ItemWrenchConfigClient. (if this class does not exist yet, make it. This pattern should exist for other configs that require client-only things)

[rubensworks]

Done in 74649c1. There was no item-level client config in this repo yet, so I added ItemWrenchClientConfig, following the BlockCableClientConfig pattern: it extends CyclopsCore's ItemClientConfig and registers its own mod event bus listener. ClientProxy no longer knows about the wrench.

Two notes on how it is wired:

• I named it ItemWrenchClientConfig rather than ItemWrenchConfigClient, to match BlockCableClientConfig and CyclopsCore's own ItemClientConfig/BlockClientConfig. Say the word if you prefer the other order.
• This required moving ItemWrenchConfig from ItemConfig to ItemConfigCommon, as only the latter has the getItemClientConfig hook (the same split BlockCableConfig already uses). The other item configs in this repo still use ItemConfig; I left them alone. Since getItemClientConfig is not cached by the base class, the config caches its instance so the listener is only registered once.

Verified in a dev client that the mode still shows on the item.

---

Generated by Claude Code

[rubensworks]

Sorry, I acted on your inline comments first and missed the three points in the review body. All three are handled now.

Tooltip in non-config modes (7dad1fb): the copied source and Includes lines are now gated on the mode actually pasting a configuration, so Default, Save Offset and Save Offset and Side only show the mode line. The configuration itself is still kept in the Wrench when switching modes.

Changelog (7dad1fb): reverted, CHANGELOG-1.21.1.md is back to what is on master-1.21-lts.

Integrated Tunnels, manually tested with clientdevbridge: I ran a dev client with IntegratedTunnels 1.21.1-1.11.1 in the mods folder and copied between pairs of parts, configuring each source through its own gui:

Part	Configured on source	Result on target
Item Exporter	15 ticks/operation, priority 2, Export All Items channel 7	all three pasted
Item Importer	19 ticks/operation, priority 4	both pasted
Item Interface	17 ticks/operation, priority 3, Interface Channel 5	ticks and priority pasted, Interface Channel not

Copy All correctly refused to paste an Item Interface configuration onto an Item Exporter, and the tooltip named the source part properly (Copied from: Item Exporter).

One gap worth deciding on: the Item Interface's Interface Channel (channelInterface) is Integrated Tunnels' own part state, not one of the settings this snapshot knows about, so it stays at its default on the target. The same holds for any other addon-specific part state. PartConfigSnapshot has a fixed set of fields, so Integrated Tunnels cannot add to it even though snapshotConfig/applyConfig are overridable per part type.

If you want that covered, the smallest change on this side is an extra CompoundTag in the snapshot plus a pair of overridable no-op hooks on IPartType for a part type to write and read its own state, which Integrated Tunnels would then implement for the interface channel. Say the word and I will add it here; I left it out for now since it is an API addition and the Integrated Tunnels half lives in another repo.

---

Generated by Claude Code

[rubensworks]

Added the extension point in c599bc6, kept generic so any addon part type can use it.

PartConfigSnapshot gains a Map<PartConfigSection, CompoundTag> extraData, an opaque bucket per section that a part type fills and reads itself, and IPartType gains three default methods:

CompoundTag snapshotConfigExtra(ValueDeseralizationContext ctx, S state, PartConfigSection section);

void applyConfigExtra(ValueDeseralizationContext ctx, PartTarget target, S state, PartConfigSection section,
                      PartConfigSnapshot snapshot, Player player, PartConfigApplyResult result);

List<Component> getConfigExtraRequirements(PartConfigSnapshot snapshot, PartConfigSection section);

Design points:

• Per section, so the subset Wrench modes stay honest. The Interface Channel belongs to PART_SETTINGS, so Copy Aspect neither copies nor pastes it, and Copy Settings does.
• The whole snapshot goes to applyConfigExtra, so an implementation can check snapshot.sourcePartType() before reading a tag. That matters because the subset modes paste across part types, and a tag written by one part type should not be read blindly by another.
• Only called when there is something to do: applyConfigExtra is skipped for sections whose tag is empty, and an empty tag from snapshotConfigExtra is not stored at all, so it never inflates a snapshot or makes an otherwise default part look configured.
• hasSection and isEmpty account for it, so a part whose only non-default state is addon state still copies, and "nothing to copy" stays accurate.
• Reporting is available too: PartConfigApplyResult.addApplied(Component) joins the "Pasted: ..." line and addWarning(Component) goes to the chat warnings, so an implementation that has to consume something from the player can say so, in its own words. getConfigExtraRequirements puts the matching line in the Wrench tooltip, resolved on the part type the snapshot came from.

For the Item Interface, Integrated Tunnels would override the first two on its interface part types and move channelInterface through them.

Two game tests cover the plumbing, using a part type proxy that stores and reads back a value: one asserts the value survives a copy and paste and that the part type's own message reaches the player, the other asserts Copy Aspect neither stores nor pastes a PART_SETTINGS tag. I checked they bite by removing the applyConfigExtra call, which fails the first one with Expected The part type did not read its own state back to be 42, but was -1. Unit tests cover the codec round trip and the section accounting.

---

Generated by Claude Code