DaisySuite

Kotlin-First Paper Tooling

One Daisy suite for modern Paper plugins: DaisyCore runs runtime systems, DaisySeries owns canonical values, and DaisyConfig owns typed YAML.

One docs surface for the whole suite: runtime ownership in DaisyCore, parser-safe values in DaisySeries, and typed config plus managed lifecycle and module bundles in DaisyConfig.

Normal flow: DaisySeries parses values -> DaisyConfig stores typed config -> DaisyCore renders and runs the feature.

Start with DaisyCoreWhich product do I need?

DaisyCoreCommands, menus, sidebars, tablists, MiniMessage text, placeholders, items, and lifecycle ownership.

DaisySeriesCanonical keys, aliases, and parser-safe modern Paper values like materials, sounds, biomes, attributes, difficulties, particles, and more.

DaisyConfigTyped YAML codecs, managed lifecycle, module bundles, DaisySeries-backed decoding, and DaisyCore text bridging.

What can you build?

Profile runtime flow

Use DaisyCore when one feature spans a command, menu, sidebar, and tablist in one runtime-owned flow.

Config-heavy plugin data

Use DaisyConfig when YAML shape, migration safety, module bundles, and shared text ownership become the real maintenance problem.

Canonical parser layer

Use DaisySeries when config-heavy Paper values should stop leaking enum helpers through plugin code.

Full stack plugin

Use all three together when config ownership, canonical values, and runtime systems all matter in the same plugin.

Related Product

DaisyCore is the runtime owner at the top of the chain

DaisyCore renders text, owns UI systems, and runs the actual player-facing flow.

Open DaisyCore docs

Related Product

DaisySeries sits at the bottom of the dependency chain

Canonical values and aliases should come from DaisySeries instead of being copied into config or runtime docs.

Open DaisySeries docs

Related Product

DaisyConfig turns DaisySeries values into typed config state

Use DaisyConfig when those canonical values live in YAML and need managed lifecycle, module bundles, and reload-safe ownership.

Open DaisyConfig docs

Start the normal path

1

Pick the product that owns your problem

Use Which product do I need? if you are choosing between runtime, parsing, or typed YAML ownership.

2

Start with DaisySeries when parsing is the actual problem

Use Install DaisySeries first when canonical values, aliases, and parser-safe inputs are the real issue.

3

Move to DaisyConfig when YAML ownership becomes the maintenance problem

Use Install DaisyConfig when config shape, versioning, module bundles, and shared text ownership matter more than parser or runtime concerns alone.

4

Use the normal stack when all three layers matter

Read Build the Normal Stack for the intended Daisy flow: DaisySeries parses values, DaisyConfig owns typed YAML plus module lifecycle, and DaisyCore renders the runtime result.