Shell Creator
Design your own interior shells from scratch with a built-in, grid-based building tool, no external map editor, no CodeWalker, no re-streaming YMAPs. Admins paint floors, drop walls, doors and windows on a snapping grid, stack multiple storeys, then save the result as a reusable shell template that slots straight into the property creation flow like any other shell.
Think of it as a Quasar / Fortnite-style fast-build editor for shell interiors.
Everything here is admin-only and server-gated (spoof-proof). Building happens on a private underground canvas that only the builder sees, nothing is spawned on the live map while you work.
Where it lives
The Shell Creator is driven entirely from the Admin tablet, there are no chat commands to remember.
- Open the Admin tablet (see Admin Registry).
- Go to Shell Templates in the sidebar (the Shell Creator Templates view).
From there you can launch the builder, and preview / edit / delete any template already saved to the database.
Creating a template
- In Shell Templates, type a name into the new template field
(letters, numbers and
_only, it's slugified automatically, e.g.My Loft→my_loft) and press Launch Builder. - You're dropped onto a blank underground canvas in a fly-through freecam, with a single starter floor tile beneath you. Your character body is hidden while you build.
- Build the shell (see below).
- Press Save (top-right of the panel). The template is written to the
database and immediately registered as a shell with id
custom:<name>. It shows up in the property creation wizard for everyone online straight away, with no restart or relog. Edits and deletes apply the same way.
To change one later, hit Edit on its row, the builder re-opens with every part reloaded exactly where you left it.
The builder interface
Camera & movement
The camera copies the Furniture Modeler: the NUI owns the mouse (the cursor drives aiming and the panels), and the camera only turns while you hold right-mouse and drag.
| Input | Action |
|---|---|
| WASD | Fly around |
| Space / Ctrl | Up / down |
| Shift / Alt | Fly faster / slower |
| RMB + drag | Look around |
| Scroll (or the level buttons) | Change the active building level |
| R | Rotate the aimed prop |
| Arrow keys | Nudge the aimed prop |
| PgUp / PgDn | Raise / lower the aimed prop |
| G | Reset nudge |
Left toolbar
- Build / Destroy: the two modes. Build places the selected item; Destroy removes what you aim at (works on floors, walls, ceilings and props).
- Level Up / Level Down: the current storey. A badge shows which floor
you're on; each level is stacked
wallHeight(3 m) above the last, so you can build multi-storey shells. - Undo / Redo: full history, including manual wall edits.
- Preview: drops you inside the shell on foot to walk it exactly as a player will. Press Backspace to return to building.
Item dock (bottom)
A searchable, categorised grid of every buildable piece (pulled live from
Config.ShellGrid.props). Categories include Floors, Ceilings, Walls,
Doorframes, Windows, Doors, Stairs, Pillars, Railings and the Spawnpoint
tool. Aiming shows a translucent ghost of the real prop, not a marker, so
you see exactly what lands.
How building works
The whole shell snaps to a 4 m grid (Config.ShellGrid.cell). Pieces align
to a cell in one of a few ways depending on their align:
floor/ceiling→ snap to the cell (the tile itself)edge→ snap to the nearest shared edge between two cells (walls, doors, windows, railings)cell→ sit at the cell centre (stairs, pillars)spawn→ marks where players enter
Foundation (the smart part)
The Foundation (floor) tool is the heart of the builder. Painting or erasing floor tiles is a hold-and-drag action, sweep the cursor to lay a whole room at once.
Laying a floor tile auto-spawns the surrounding walls; erasing one dissolves walls that are no longer needed. Walls are tracked by a canonical, direction-free edge key, so two adjacent rooms share exactly one wall on their common boundary (never two overlapping ones).
Walls, doorways & windows
The Wall, Doorway and Window tools override the auto-walls: they force the aimed cell's nearest edge to that piece. Use them to punch a doorway between rooms, drop a window in an exterior wall, or partition an open space. These manual overrides are remembered (and undo-able), so the auto-engine respects your openings instead of filling them back in.
Spawnpoint
The Spawnpoint tool marks where a player lands (and where the exit prompt sits) when they enter the finished shell. Place it once, facing the direction players should spawn.
Ceilings & the auto-roof
Shells are capped automatically so nobody looks straight out the top
Config.ShellGrid.autoCeiling (on by default) closes every open-to-sky floor
cell with a ceiling slab when the property is entered. This runs from the stored
parts, so existing templates get roofed on the next entry with no re-save.
Cells that already have a floor directly above them are left alone, that upper floor is the ceiling, and doubling it up would z-fight.
For manual control there's also a Ceiling tool in the dock, which lays a face-down slab at the top of the current level's walls. Manually-placed ceilings are always respected and never doubled by the auto-roof.
Metrics are tuned in-game. Grid size, wall offsets, headings and the
z-fight nudges in Config.ShellGrid are best-guess defaults matched to the
core sc_* props. If you swap in different building props, expect to re-tune
wallLateral, wallZ, wallHeight and the bias knobs so floors sit flush and
walls land on their edges without flickering.
Using a saved template
A saved template behaves like any other shell, its id is custom:<name>.
- Assign it to a property through the normal creation flow: it shows up in the block's allowed-shell picker and the property wizard alongside the built-in shells (see Creating Property and Property Types).
- Preview / Edit / Delete any template from the Shell Templates admin view at any time.
How custom shells spawn
Templates are not hard-coded into the shell config files (shared/shells,
shared/interiors are left untouched). Instead they're loaded from the database
on server boot and registered as ordinary instanced shells. When a player enters
a custom:* property, the server streams the template's part list and the
client spawns each floor / wall / door piece relative to the interior anchor
then applies the auto-roof, exactly like a normal shell in its own routing
bucket.
Parts are stored shell-relative (the same convention as placed furniture see Furniture Modeler), so a template lines up identically on every property that uses it.
Configuration
Everything lives in shared/config_shellcreator.lua under
Config.ShellGrid:
| Key | Default | Purpose |
|---|---|---|
cell | 4.0 | Grid tile footprint (metres) = one floor tile |
wallHeight | 3.0 | Storey height / vertical spacing between levels |
autoCeiling | true | Cap open-to-sky cells on entry (false = open-air) |
ceilingZDrop | 0.04 | How far the auto-ceiling sits below the ceiling plane |
floorModel | sc_floor_4x4 | Core floor slab |
wallModels | sc_wall_4x3, …_door_4x3, …_window_4x3 | Structural wall set |
wallLateral | 2.0 | Cell-centre → shared-edge distance for walls |
wallZ | 0.0 | Vertical offset of a wall vs its floor level |
wallZFightBias | 0.0 | Optional anti-z-fight wall sink (see warning below) |
wallHeadingNS / wallHeadingEW | 0.0 / 90.0 | Wall headings by edge orientation |
buildDepth | 195.0 | Underworld build anchor depth |
maxReach | 200.0 | Server sanity clamp on aim distance |
maxParts | 2000 | Max parts per template |
props | (large table) | The dock catalogue, models, labels, categories, align, icons |
Adding your own building pieces is just a matter of appending entries to the
props table with an appropriate align (floor, ceiling, edge, cell or
spawn); the builder dock picks them up automatically and groups them by
category.
Leave wallZFightBias at 0 unless you know you need it. Sinking walls to
kill top-edge flicker can push an upper storey's wall base down through the
floor below it, showing as a brick strip on the room's ceiling. Prefer letting
the floor-above act as the ceiling untouched; only nudge the bias a hair for
single-storey builds.
Notes & limits
- Admin-gated end to end. Every builder callback (
shellcreator:save,…:list,…:getTemplate,…:delete,…:apply) checks admin server-side. - Multi-storey is supported, stack floors with the level controls.
- Templates are pure shells: they support furniture, stashes, cameras and the rest of the in-property tooling like any other shell.
- Data lives in the
kp_custom_shell_templates/kp_custom_shell_partstables and is loaded once on server start (see Migrations for schema versioning).