Skip to content

First Tablist

This page shows the honest current DaisyCore tablist path:

  • per-player header and footer sessions
  • MiniMessage-first strings by default
  • shared config-backed text only when it is useful

Step 1: start with direct MiniMessage strings

Section titled “Step 1: start with direct MiniMessage strings”
fun profileTablist(player: Player) =
tablist {
header("<gradient:#7dd3fc:#c4b5fd>Welcome back</gradient>\n<white>${player.name}</white>")
footer("<gray>Coins: <white>1,250</white>")
}

That is the normal path.

Those strings are already DaisyCore-facing MiniMessage strings.

val session = daisy.tablists?.show(player, profileTablist(player))
session?.refreshNow()
session?.close()

Step 4: use shared config-backed text when the plugin already stores header/footer there

Section titled “Step 4: use shared config-backed text when the plugin already stores header/footer there”
fun profileTablist(player: Player) =
tablist {
headerLang("profile.tablist.header", viewer = player, "player" to player.name)
footerLang("profile.tablist.footer", viewer = player, "coins" to "1,250")
}

Those keys are just your own plugin config paths.

They only become useful when you want:

  • shared text across multiple systems
  • translation/localization
  • reloadable wording
  • config-managed UI text

If your plugin is already component-first, the tablist builder also accepts Component values directly.

The recommended order remains:

  1. direct MiniMessage strings
  2. components when you want explicit control
  3. key-backed text when the plugin already stores text that way

The current public tablist API intentionally focuses on:

  • header
  • footer
  • options
  • session refresh and cleanup

It does not currently claim richer tab entry formatting or packet-heavy customization.

Current default

Use direct MiniMessage strings first. Shared config-backed text is the scaling path, not the starting requirement.