Add merge-block grid-naming controls (priority + unmerge name) + dedicated control panel

Hi Keen,

This is a feedback item that’s been bugging me for awhile in SE1: the merge block needs more control over the resulting grid name on both sides of the merge/unmerge cycle. This shows up most on large-grid setups (stations, capital ships, mobile bases) where modular assembly is the dominant use case.

The problem

The merge/unmerge cycle is asymmetric in two ways today, and both ways lose information:

At merge time, the surviving grid is whichever one is rooted (static), or if neither is rooted, whichever has more blocks (per MyCubeGrid.ShouldBeMergedToThis). The other grid is absorbed and its DisplayName is discarded. So when “Hauler Mk3 - Cargo Pod” docks to a larger unnamed station, the combined large grid takes on “Large Grid 8392” — the carefully-chosen name is gone.

At unmerge time, the original (surviving) grid keeps its name, but a fresh grid is created for the broken-off side via MyCubeGrid.CreateGridForSplit — and that method doesn’t copy DisplayName from the original. The new grid gets the default “Large Grid N” auto-name. So even if you docked something meaningfully named, on undock it comes back as “Large Grid 12491”.

Net effect: anyone doing modular ship assembly (rocket staging, drone docking, base segments) ends up manually renaming grids after every merge/unmerge — every time.

Concrete use case: task-specific tool heads. I run a main ship with a merge block + connector pair on the front, and I swap between a couple of dedicated tool heads depending on what I’m doing — a drill head for mining runs, a grav scoop tool for Factorum encounters. The swaps are infrequent (once per task), but they’re the kind of swap that should just work without me having to re-name grids each cycle. The merge block handles structural fusion so the head doesn’t wobble; the adjacent connector handles conveyor flow for ore, ammo, components.

With this proposal:

Main ship’s front merge block: Priority High, Unmerge Grid Name auto-filled with the ship’s name at placement

Each tool head’s merge block: Priority Medium (or Low) (default; no edit needed), Unmerge Grid Name auto-filled with the head’s name when the head was built

On dock: combined grid keeps the main ship’s name because Main is High. On undock: the ship stays itself, the drill head goes back to “Drill Head” instead of “Large Grid 47213”. Zero manual renaming across the swap, every time.

The idea

Add the following to the merge block’s terminal — two new persisted fields plus a helper button:

Unmerge Grid Name — text input. When this merge block’s side splits off after an unmerge, the resulting grid is named whatever is in this field. Static — what you type stays what you typed. Auto-fills with the grid’s current name when the block is first placed, so for typical use the player doesn’t have to type anything.

Sync button — small button next to the Unmerge Grid Name field, labelled “Sync from grid name” (or just “Sync”). One click overwrites the field with the grid’s current DisplayName, for re-syncing after the player renames the grid post-placement. Action only, no persisted state.

Merge Priority — dropdown with three values: Low, Medium, High. Default is Medium. When two grids merge, the higher-priority block decides which grid name survives:

• High vs anything-lower → High wins (keeps its grid name)
• Medium vs Medium → SE’s current behavior (no change from today)
• Low vs anything-higher → Low loses (accepts the other side’s name)
• Same-priority ties → SE’s current tiebreaker decides (Medium vs Medium is the default, so unmodified merge blocks behave exactly as today)

Out of the box, every newly-placed merge block ships at Medium with the unmerge-name auto-captured from the grid name (merge blocks already present in existing saves load with the field empty — no retroactive migration). Merge-time naming at the Medium/Medium default falls through to today’s rule (rooted-or-bigger wins), so merge behavior is unchanged. Unmerge behavior is genuinely better at the default, though: the auto-filled UnmergeGridName replaces the “Large Grid N” auto-name on the split-off side, so a previously-meaningful name survives the round trip without any player effort.

Why this works for multi-merge-block setups

Recommended pattern: set High on one merge block per grid, leave the rest at Medium. Whichever seam closes first, the High block’s vote applies via the multi-seam rule (each side’s effective vote is the highest priority among its participating seam blocks). The auto-filled Unmerge Grid Name on the Medium blocks still kicks in if those happen to be the seam — so the grid name survives the split even when the seam isn’t the High block. Player doesn’t have to track which seam is which.

Bonus suggestion: a dedicated control panel

While you’re touching the merge block UI, please consider giving it a dedicated terminal panel like the Projector block received. Right now the merge block’s terminal is just enable/disable + ownership, which is fine when the block is one of many on a fully-built grid — but it’s painfully thin given how much state the block already computes internally that the player never sees.

The panel would naturally host the three new controls described above (Unmerge Grid Name, Sync button, Merge Priority), plus a couple of small, merge-block-specific additions that are otherwise invisible today:

Resolved-name preview: a read-only line showing what the resulting grid name would be if a merge happened right now, based on this block’s priority and the paired block’s priority. Updates live as the player toggles Priority on either side. Genuinely new state — it doesn’t duplicate anything elsewhere in the UI, and it’s the most direct way to confirm a multi-merge-block setup is configured the way you intended.

For the physical placement of the access panel on the block model itself, please put it on the opposite end from the merge face. The merge face is reserved for magnets (this is the dummy MyShipMergeBlock.LoadDummies binds the magnetic constraint shape to), and the back face is its geometric counterpart — for the small-grid merge block the SBC defines both ends as full 3×3 mount surfaces, so the back is the natural operator surface by symmetry. It’s also the most likely face to stay accessible in the bootstrap case where a player places a single fresh merge block to start a new build. In finished builds the back face will often be covered by structure — that’s acceptable; the access pattern is “configure once at setup, then forget about it.”

The Projector block’s expanded panel made it dramatically more usable for blueprint projection workflows — the merge block deserves the same treatment for modular-assembly workflows.

Edge cases

If a merge block is destroyed (combat, grinding, etc.) while the grids are fused, the seam breaks and that block can’t apply its Unmerge Grid Name — that side falls back to SE’s current auto-naming. Acceptable; mirrors the destruction taking the block away.

When a merge block is placed solo in open space, the new grid is named by MyCubeGrid.MakeCustomName() (“Static Grid N” / “Small Grid N” / “Large Grid N”), and the auto-fill captures that meaningless string. Player can rename the grid and click Sync to recover. This case is rare relative to the dominant case of placing a merge block onto an existing named grid.

Summary

Add two persisted fields (Unmerge Grid Name + Merge Priority dropdown) plus a Sync helper button to the merge block terminal

Defaults preserve current merge behavior exactly (Medium/Medium = today’s rooted-or-bigger rule)

At unmerge, the auto-filled UnmergeGridName replaces today’s “Large Grid N” auto-name on the split-off side — an improvement in the common case (a merge block placed on an existing named grid); solo-placement and destroyed-block edge cases fall back to today’s behavior, see “Edge cases”

Especially useful on large-grid modular assembly (the common case): stations, capital ships, mobile bases

Consider promoting the merge block to a dedicated terminal panel like the Projector, with the access face placed on the opposite end from the merge face

Thanks for reading! Happy to discuss tradeoffs in the comments. Voting if you want this would be much appreciated.