Feature Build Profiles - bh679/dungeon-train-mc GitHub Wiki
Home > Features > Build Profiles
Saving in the Train Builder has only ever written a file on your own machine. A build profile gives every player a record of what they've made that lives on the mod's relay instead: builds travel with you between worlds, show up in one place, and can be submitted to the train so a carriage of yours turns up in anyone's run.
Status: in testing — off by default. The switch
builderProfileEnabled(dungeontrain-server.toml) opts a server in; uploading additionally requires the player's own client to have granted network consent. Nothing leaves a machine until both are true.
- Save, and it's yours everywhere. Saving a build in the Train Builder also uploads it to your profile. Every kind the builder authors goes up — carriages, carriage rooms, shell parts, track tiles, tunnels, portal rooms — not just the ones a train can hold.
- My Builds, from the builder's pause menu (directly under Save): every build you've made, drawn as a 3D tile of its own blocks, labelled with where it currently lives — saved or on the train.
- Submit for Review offers a build to the developer, whatever kind it is — a carriage, a carriage room, a shell part, a track tile, a portal room, a whole group. The tile then shows where it stands: waiting on review, accepted, or not accepted. Withdraw Submission takes an undecided one back. v0.1066.0 (PR #1705): submitting also announces the build on the community Discord — author, name, kind, the reviewer answers and a picture of the build, rendered from its tile on your machine at the moment you submit. Release builds post to a dedicated build-submissions channel; dev builds post to the dev channel. Withdrawing announces nothing.
- What acceptance leads to still differs by kind. An accepted carriage can be leased into other players' worlds exactly as any shared carriage is; the other kinds are collected and reviewed, and placing them in a run is later work. The screen promises a review, never a ride.
- A build stays private to you until you submit it. Saving is not publishing.
- Submitting works on any build of yours, including one the relay restored to your profile or one you first uploaded from a different world — the game recovers the permission it needs from the relay rather than asking the world you happen to be standing in.
| Where it lives | Who can meet it | |
|---|---|---|
Saved (visibility=profile) |
Your profile, and your machine | Only you |
On the train (visibility=published) |
The shared pool | Anyone, in any world |
The relay enforces the line rather than trusting the game to: a lease only ever serves a build that is both published and a carriage, as literals in the query rather than options a caller passes. A portal room can never be handed to a train slot however it is asked for — submitted, accepted, or neither.
Review is a second, separate axis from that: none → submitted → accepted / not accepted answers
"has a person accepted this into the game", while the moderation flag answers "is this content
acceptable". Every kind travels the review axis; only a carriage can cross the published-and-leasable
line at the end of it. A build waiting on review, or already accepted, is also held back from the
relay's storage eviction — the queue is not something a busy author's next upload should delete.
A build you submit for review comes back with a verdict, and the verdict comes back with a note. The tile in My Builds shows which one by its border and corner icon, and the line under the action buttons spells it out with the reviewer's comment quoted after it:
| Verdict | Tile | What it means |
|---|---|---|
| Waiting on review | blue, hourglass | Submitted; nobody has looked yet. |
| Accepted | green, tick | In the game — a carriage can ride the train. |
| Feedback given | yellow, speech bubble | Looked at and sent back with notes. Edit it and submit again. |
| Needs resubmit | orange, circular arrow | Sent back for a particular Dungeon Train version — "Resubmit from Dungeon Train 0.1130.0 or above". It stays here until you submit it again from a client on that version; Submit for Review on an older client tells you which version it needs. |
| Not accepted | red, cross | Turned down. Still saved to your builds. |
The status chip filters on any of these. The same comment and rule show under your own answers on the editor's Submitted answers page, and if you have a chat thread with the dev the verdict also arrives in your in-game inbox. Accepted, feedback and resubmit verdicts are announced in Discord's build-submissions channel (a decline is not).
The reviewer decides from inside the game: on a dev build with the relay's admin URL, somebody else's build in the editor shows four icon buttons on its Submitted answers page — accept, feedback, resubmit in a version, decline — each opening a comment box (see Development). Shipped in PR #1796.
Building from the platform (Train Outside) parks a whole run of carriages, and all of them are yours to edit. A save there writes one carriage-group template covering the run, rather than one template per carriage — which carriage follows which is part of what you made, and three separate templates would keep the blocks while losing the composition.
A group's carriage count is its footprint (carriages × length), not a number stored beside it, so
it can't claim a size it hasn't got. A world whose train is a different length refuses the group rather
than stamping it short — the same posture the carriage-dimensions gate already takes.
Groups are not yet submittable to the train: nothing places a group on a train, so they live in your profile and reopen in the builder. Placing one is a later piece of work.
A published build is out in the pool, so the game claims it back before writing to it, and gives up rather than fighting for it: if another world is actively holding your build, the save stays local and says so, and taking a build off the train is refused while someone is riding it. Nothing you build is ever lost to that — the file on your own disk is the build, and the profile is a second home for it.
You can browse another builder — by name, or from your favourites — and load one of their builds into your own editor. It lands in your template library like any other template: openable, editable, stampable into a train.
What it also lands with is who made it. The build is captioned "Built by <name>" in the Train Builder's info panel, beside the name, kind and stage rows, and that byline is written down rather than merely displayed:
- It is filed once. Editing the build, saving it, renaming it or reopening it never quietly turns it into your work.
- It travels. If you pass the build on and somebody loads it from you, they are still told who originally built it — not who they got it from.
- Your own builds carry no byline at all, including one the relay hands back to a fresh world. The line simply isn't there, rather than reading "Built by you".
The record is kept per install, in your active content package, and names the builder by the identity the relay knows them by — the displayed name is the one they had when you loaded the build, so a builder who later renames themselves keeps the old name on copies already downloaded.
-
Where builds are kept. Carriage groups live in
config/dungeontrain/user/carriagegroups/, alongside the existingwholecarriages/andtemplates/stores. A group and a carriage may share a name without shadowing each other. - Builder worlds are creative, and that's fine. The ordinary Free Play rule keeps cheated runs from feeding the pool; the Train Builder is the authoring tool, where creative is the point, so builds made there join the normal pool.
- What gets reviewed. The same serve-now text scan the shared-carriage pipeline runs — sign, book and named-item text — applies to a builder upload. A build held back from the train for review says so on its tile in My Builds, which is the only place its author could learn why.
- Uploads are capped at roughly half a megabyte of blocks; an over-size build is kept locally and the game says why rather than failing silently.
- Untouched copies of built-in templates don't count as builds. Opening a stock part or carriage in the builder and saving it unchanged still uploads it, but the relay recognises it (its blocks hash matches a template the mod ships) and leaves it out of Find a Builder's counts, out of other players' view of your profile, and out of All builders. It stays in your own My Builds with a note saying so. Change a single block and it is your build again. Nothing is deleted — this is a read-time filter (PR #1434, relay #580).
Every stat the game kept used to be about riding: carriages reached, distance, deaths, books. An evening in the Train Builder counted for nothing. It is now tracked as a stat of its own.
- What counts. Time in a Train Builder world, and time up at the editor plots in an ordinary world. Both feed one figure; standing on the train does not.
-
Where it lives.
config/dungeontrain-stats/<uuid>.json, underbuilding— the same cross-world file that already holds lifetime carriages, distance and deaths, so it follows you between worlds rather than resetting with a save. - Two new leaderboard books. Longest Building ranks that figure. Most Builds Approved ranks the builds a player authored, submitted to the train, and had approved — builds captured automatically off a running train are not counted, because nobody authored those.
There is no idle cutoff: a builder world left open counts the whole time it is open.
Reporting is on the same footing as every other relay figure — the server's worldInfoToRelay
setting plus the player's own network consent. A player who has not consented sends nothing and
cannot appear on either board.
Each player's builds also appear on their page in the relay's data explorer (Builds), with the same 3D viewer the Carriages gallery uses, showing kind, size, stage, moderation state and which pool a build is in.