First Plugin

First Plugin

This page starts with the lowest-friction DaisyCore bootstrap.

The important default

You do not need:

• a text key system
• a DaisyTextSource
• config-backed messages

just to start using DaisyCore.

Direct strings are already the normal path, and those strings are MiniMessage-first across DaisyCore-facing UI and messaging APIs.

Current default

Start with direct MiniMessage strings. Add messages(…) later when your plugin wants one shared reloadable text source across commands, menus, sidebars, and tablists.

Step 1: bootstrap DaisyCore

class MyPlugin : JavaPlugin() {
    private lateinit var daisy: DaisyPlatform

    override fun onEnable() {
        daisy =
            DaisyPlatform.create(this) {
                commands()
                menus()
                scoreboards()
                tablists()
            }
    }

    override fun onDisable() {
        daisy.close()
    }
}

Step 2: understand what this gives you

• one shared DaisyCore runtime owner
• command discovery
• menu services
• scoreboard services
• tablist services
• safe shutdown cleanup through daisy.close()

That bootstrap shape is the stable DaisyCore lifecycle contract for 0.1.0.

Step 3: use direct MiniMessage strings first

reply("<gradient:#7dd3fc:#c4b5fd>Profile opened.</gradient>")

player.openMenu("Profile", rows = 3) { }

sidebar {
    title("<gradient:#7dd3fc:#c4b5fd>Profile</gradient>")
}

tablist {
    header("<gradient:#7dd3fc:#c4b5fd>Welcome back</gradient>")
    footer("<gray>Enjoy your stay</gray>")
}

That is already the intended modern Adventure + MiniMessage style.

Step 4: add shared text only when you want config-backed content

If your plugin already keeps text in config or lang files, install one shared text source and let DaisyCore reuse it everywhere.

The easiest ecosystem path for that is DaisyConfig:

val langHandle = yamlTextConfigHandle(this, "lang.yml")

daisy =
    DaisyPlatform.create(this) {
        messages(langHandle.current.asDaisyTextSource())
        commands()
        menus()
        scoreboards()
        tablists()
    }

That is useful when you want:

• reloadable text
• one shared source across systems
• translation/localization
• config-driven plugin wording

If you do not want that yet, keep using direct strings.

Components still work

If your plugin is already component-first, DaisyCore still accepts Component values in the relevant places.

The intended teaching order is:

1. direct MiniMessage strings
2. components when you want explicit low-level control
3. config-backed shared text when you want scale and reuse

Why lifecycle ownership matters

DaisyPlatform owns the systems you enabled.

Closing it on plugin shutdown is part of the normal runtime lifecycle so DaisyCore can safely clean up:

• menu sessions
• sidebar sessions
• tablist sessions
• command runtime services

Next steps

• Create your first command: First Command
• Learn the shared config-backed text path: Config and Lang Text
• Understand platform ownership: Runtime and Shutdown