Credit and Being Credited

Every pack's listing page shows two things you never write yourself: Uses — the packs this one is built on, each with its creator, its licence and a link — and Used by — everything built on this one.

There is no credits box, on purpose#

Nothing on a listing page is typed in by an author. There is no credits field on the manifest, no credits panel in the editor and no free-text box anywhere in the publish flow.

Credit is derived from the dependency graph. When you add a dependency on a published pack — importing an Asset pack by reference, or assigning somebody else's Room or Table — the pin lands in your manifest's dependencies, and the platform loads that pack in order to run yours. The listing simply reads that. Which means:

• You cannot forget to credit something you depend on.
• You cannot credit something you do not actually use.
• A reader can check the claim, because the pin names an exact version and commit.

That is the whole reason the Uses list is worth reading, and it is why adding a field an author fills in would make it worse rather than better.

What the list shows#

Column	Where it comes from
Pack name and link	The registry entry for the pinned pack id
Creator	The DiceyTable account that published it, falling back to the GitHub owner
Licence	license in that pack's manifest, exactly as published
Version	The exact pin your manifest declares — never a range
Commit	The commit that version resolved to, when the registry recorded one

If a pack you depend on has since been unpublished, deleted or taken down, the row stays and says so. A credit does not stop being owed because the upstream vanished.

Licences are shown, never checked#

DiceyTable displays each pack's licence string as its creator published it, and does nothing else with it. There is no compatibility check, no SPDX validation and no green tick — a machine verdict derived from two strings would be false confidence, and the files are public on GitHub regardless.

Read the licence of anything you build on. It is shown on the pack's card when you add it, on its own listing page, and on yours once you depend on it.

Copied content: the "Also credits" section#

Importing an Asset pack vendored ("Copy in"), or lifting a room, a table or a prefab out of a published pack, deliberately does not create a dependency. The bytes become part of your pack, and there is no pin for the graph to read — which is exactly what that mode is for.

Because the graph cannot see it, the editor writes a record instead: a file at attribution/lift-outs.json in your repo, naming the pack, the exact version and commit, its licence, and the specific items you took. It is committed and published with everything else, and it appears on your listing page under Also credits.

Two things are worth being plain about:

1. It is not verified. DiceyTable does not check that the recorded credit is accurate or complete, and nothing refuses a publish whose ledger has been edited or deleted. The listing says so, and shows recorded credits in their own section rather than mixed in with derived ones.
2. But it cannot be quietly withdrawn. The record is read at the commit your version was published from, and a published version can never be repointed at a different commit. So a credit you published stays published — deleting the file changes only what your next version records. That is tamper-evident, which is a weaker guarantee than verified and a much stronger one than nothing.
3. It is still the right thing to publish. A vendored copy with no record is indistinguishable from original work. Leave the file alone, and it does its job.

If you want a credit that is verified, import by reference instead of copying. See Importing an Asset Pack and Lifting Content Out of a Pack for what each mode does to your project.

"Used by" — who is building on you#

The reverse listing on your pack's page shows every published pack that pins yours, newest first and paginated. It is derived from their published manifests, so it is exactly as complete as what has been registered: a pack that depends on you but has never been published does not appear, and neither does one whose own publish was refused.

Two consequences worth knowing:

• An entry names a version. A dependent pins one immutable version of your pack, so the list tells you which of your releases people actually build on.
• Publishing a new version does not move anybody. Dependents resolve the version they pinned until their author explicitly bumps it. See Registration & Multiplayer Play for how a pinned version is served.

Browsing by type#

Packs are browsable by what they are — Games, Rooms, Tables and Asset packs — at /packs. A pack's type is fixed at first publish and cannot be changed afterwards, which is what makes that listing trustworthy; see Manifest Reference for the type field.