Use this branch if your server still depends on the classic SIR configuration tree and deployment flow.

What counts as Legacy?

The legacy line is SIR 1.7.0 and below. This is the older Maven-based generation of the plugin, built around a single project and a large runtime tree rooted in plugins/SIR/resources/.

If your current production server still uses folders such as resources/modules/chat or resources/commands/chat_color, you are on the Legacy line.

Legacy architecture

Legacy SIR is still an all-in-one plugin, but the separation between features happens mostly in generated resource folders instead of in the repository itself.

That means the plugin is organized around:

a shared root configuration layer
a resources/modules/ tree for server features
a resources/commands/ tree for command behavior and player data
a smaller permission model declared in plugin.yml

Unlike Modern SIR, Legacy does not split features into Gradle subprojects like module/channels or command/mute.

Runtime layout

Typical Legacy output looks like this:

plugins/SIR/
  config.yml
  bossbars.yml
  webhooks.yml
  resources/
    modules/
      modules.yml
      advancements/
      announcements/
      chat/
      hook/
      join_quit/
      motd/
    commands/
      commands.yml
      announcer.yml
      clear-chat.yml
      msg-reply.yml
      print.yml
      sir.yml
      chat_color/
      chat_view/
      ignore/
      mute/

Shared root files

File	What it controls	Why it matters during migration
`config.yml`	Global plugin behavior and defaults	Still exists in newer lines, but many feature-specific settings move into split folders.
`bossbars.yml`	Shared bossbar messages and display presets	Migrated forward by the Modern migration service.
`webhooks.yml`	Shared webhook and webhook-style message targets	Also carried forward during migration.
`resources/modules/modules.yml`	Module enable or disable state	Becomes `modules/states.yml` in Modern and SIR+.
`resources/commands/commands.yml`	Command enable state, aliases, and permission layout	Becomes `commands/states.yml` plus per-provider `commands.yml` in Modern and SIR+.

Legacy modules

Legacy SIR grouped many chat features into broader folders than the modern branch does. The table below shows the exact folders and how they map conceptually.

Legacy folder	Main files	What it offers	Modern destination
`advancements`	`config.yml`, `lang.yml`, `messages.yml`	Advancement announcements, text formatting, and advancement-related messages	`modules/advancements/`
`announcements`	`announces.yml`, `config.yml`	Timed or manual announcements and broadcast content	`modules/announcements/`
`chat`	`channels.yml`, `config.yml`, `cooldowns.yml`, `emojis.yml`, `mentions.yml`, `moderation.yml`, `tags.yml`	The largest Legacy bucket: channel routing, cooldown rules, emoji replacement, mention pings, moderation checks, and tag formatting	Split into `channels`, `cooldowns`, `emojis`, `mentions`, `moderation`, and `tags`
`hook`	`discord.yml`, `login.yml`, `vanish.yml`	Third-party hook behavior for Discord, auth/login handling, and vanished staff chat rules	Split into `discord`, `login`, and `vanish`
`join_quit`	`config.yml`, `messages.yml`	Join, first-join, quit, and onboarding text	`modules/join-quit/`
`motd`	`config.yml`, `motds.yml`, `icons/server-icon.png`	Server-list MOTD rotation and icon assets	`modules/motd/`

How to read Legacy module files

config.yml usually contains switches and behavior toggles.
messages.yml or lang.yml usually contains player-facing strings.
Domain-specific files such as mentions.yml or cooldowns.yml are the real feature payloads.
modules.yml is the global state file, not the detailed per-feature configuration.

The biggest migration pain point is the old chat/ folder. In Legacy, it feels like one module. In Modern, it becomes several independent modules with their own state and files.

Legacy command tree

Legacy command data is split between top-level command files and subfolders that store player state or menu data.

Legacy path	What it controls
`resources/commands/commands.yml`	Global command registry, aliases, enabled flags, and command permission defaults
`resources/commands/announcer.yml`	Help text and validation messages for the announcement command family
`resources/commands/clear-chat.yml`	Help text and success feedback for chat clearing
`resources/commands/msg-reply.yml`	Private message and reply formatting, sounds, vanish handling, and console formatting
`resources/commands/print.yml`	Raw output help, selector syntax, and feedback for chat, action-bar, and title output
`resources/commands/sir.yml`	Main `/sir` help text, support text, and reload confirmation
`resources/commands/chat_color/data.yml`	Per-player chat color selections
`resources/commands/chat_color/lang.yml`	Messages for color changes
`resources/commands/chat_color/menu.yml`	GUI/menu layout for color selection
`resources/commands/chat_view/data.yml`	Per-player channel visibility data
`resources/commands/chat_view/lang.yml`	Messages for channel visibility toggles
`resources/commands/ignore/data.yml`	Ignore relationships and per-player ignore data
`resources/commands/ignore/lang.yml`	Ignore command messages
`resources/commands/mute/data.yml`	Mute storage and mute state data
`resources/commands/mute/lang.yml`	Mute command messages

Commands and permissions in Legacy

Legacy exposes a smaller, more umbrella-style permission model in plugin.yml:

Permission	Purpose
`sir.*`	Full Legacy access, including admin, print, and announcer families
`sir.admin.*`	`/sir` administration actions
`sir.print.*`	Raw output command family
`sir.announcer.*`	Announcement preview and task control

The concrete child nodes declared in plugin.yml are:

sir.admin.about
sir.admin.modules
sir.admin.help
sir.admin.reload
sir.admin.update
sir.print.targets
sir.print.action-bar
sir.print.chat
sir.print.title
sir.announcer.help
sir.announcer.preview
sir.announcer.start
sir.announcer.stop
sir.announcer.reboot

Important Legacy naming differences

Legacy resources/commands/commands.yml also references older command nodes that do not match Modern SIR one-to-one. Examples:

Legacy sir.clearchat becomes Modern sir.clear-chat
Legacy sir.chatcolor becomes Modern sir.color
Legacy sir.chatview no longer appears as a dedicated shipped node in the modern channels command YAML
Legacy sir.mute.perm becomes Modern sir.mute
Legacy sir.mute.temp becomes Modern sir.temp-mute
Legacy sir.checkmute becomes Modern sir.check-mute

If you hard-coded permission nodes in a permissions plugin, this is one of the first places you must audit before upgrading.

When should you stay on Legacy?

Legacy is still the safer choice when:

your server is already stable on 1.7.0
your staff depends on the old permission nodes
your deployment or backup automation expects the resources/ tree
you are not ready to split the old chat and hook behavior into modern modules

If you are starting from zero, the better long-term target is Modern Branch.

Migration mindset

Treat Legacy as a maintenance target, not as the baseline for new installs.

The healthiest upgrade path is:

inventory your active Legacy modules and command folders
map them to the modern split modules
review renamed permission nodes
run the migration path on a copy first
validate modules/states.yml, commands/states.yml, and the generated per-module folders before going live

Legacy Branch (1.7.0 and below)