Auto-Loaded Commands

Auto-Loaded Commands

DaisyCore command registration is provider-based. You define one or more providers, annotate them with @DaisyCommandSet, and DaisyCore discovers them when the command subsystem starts.

Right now, DaisyCore does this with a runtime scan of your plugin jar. That keeps setup simple while the command system stabilizes.

Example

@DaisyCommandSet
object IslandCommands : DaisyCommandProvider {
    override fun commands(): List<DaisyCommand> =
        listOf(
            command("island") {
                description("Island management")

                sub("create") {
                    enabled { plugin.config.getBoolean("commands.island.create") }
                    executePlayer {
                        reply("Island created.")
                    }
                }
            },
        )
}

Bootstrap

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

What DaisyCore does

• scans your plugin jar for classes annotated with @DaisyCommandSet
• loads valid DaisyCommandProvider implementations
• collects their commands
• filters disabled roots and subcommands
• validates root collisions
• registers the active command set with Paper

Availability controls

Use enabled { ... } when a command should depend on config or plugin state at startup.

command("debug") {
    enabled { plugin.config.getBoolean("commands.debug") }

    executePlayer {
        reply("Debug command enabled.")
    }
}

Use ignore(true) as a short way to force a command or subcommand off.

command("oldadmin") {
    ignore(true)
}

Why this exists

The normal path should be clean. You should be able to define commands and let DaisyCore wire them in, instead of maintaining a manual registration list in every project.