Legacy module reference

Legacy SIR keeps most of its behavior under plugins/SIR/resources/modules/. The important thing to remember is that these folders are broader than the ones used in 2.0.0 and SIR+.

This page is best read with two goals in mind:

• understand what each Legacy folder actually owns
• understand how that folder later splits into Modern and SIR+ modules

---

Folder map at a glance

---

Advancements

Legacy advancements/ is the dedicated progression-broadcast module. It is one of the easiest Legacy folders to understand because it already behaves like a standalone feature instead of an umbrella.

Files

• config.yml: filters and switches for where advancement messages should run
• lang.yml: operator and player-facing text for this module
• messages.yml: formatted outputs and command reactions for different advancement types

What it does

• listens for completed advancements
• filters events by world, game mode, or advancement key
• formats messages differently for tasks, goals, and challenges
• can run commands when a completion should trigger a reward or automation

What admins usually edit first

• world filters if progression spam should stay out of lobbies or minigame worlds
• challenge formatting if rare advancements should look more important than normal tasks
• reward commands if your server uses advancement completions as progression checkpoints

Why it matters in migration

This folder maps almost one-to-one into the modern advancements module, so it is usually low risk compared with chat/ or hook/. The main work is verifying message keys and any custom commands stored in messages.yml.

---

Announcements

Legacy announcements/ owns the periodic broadcast system that later becomes the modern announcements module.

Files

• config.yml: interval and rotation behavior
• announces.yml: actual announcement payloads

What it does

• rotates server announcements automatically
• supports sequential or random playback
• lets staff start, stop, reboot, or preview the announcer through the legacy command family
• can combine text with sounds, titles, bossbars, or commands depending on how each entry is written

Operational model

This folder works hand in hand with the Legacy /announcer command family. In other words, the module holds the content while the command controls the playback lifecycle.

Migration notes

When this moves to Modern or SIR+, it becomes cleaner:

• the folder is renamed to modules/announcements/
• the module gains commands.yml and lang.yml
• the old /announcer workflow becomes /announce

If your staff has muscle memory for /announcer start or /announcer preview, document that change before going live.

---

Chat

Legacy chat/ is the biggest and most important folder in the whole branch. It is not one small feature. It is the old umbrella for almost the entire communication stack.

Files

• channels.yml
• config.yml
• cooldowns.yml
• emojis.yml
• mentions.yml
• moderation.yml
• tags.yml

Why this folder is special

If you are upgrading from Legacy, this is the folder you must study most carefully. In newer branches it does not stay together. It explodes into several independent modules with their own state, files, and enable toggles.

channels.yml

This file defines the real chat-routing model.

It usually controls:

• the default channel
• extra channel definitions under channels
• per-channel access or audience behavior
• format layout and display style
• the general idea of who can speak where

This later becomes the modern channels module plus the module-owned /chat-view command.

config.yml

This is the global behavior file for the chat umbrella.

It is where you normally see decisions such as:

• whether vanilla formatting is replaced
• whether empty messages are blocked
• whether muted users are intercepted early
• whether simplified logging is enabled
• what fallback formatting should be used when a channel does not override it

This file matters because it influences how all the specialized files behave together.

cooldowns.yml

This file throttles chat behavior and helps stop repetitive spam.

Typical uses:

• delay repeated messages
• slow down specific chat actions
• create staff or donor bypass behavior through permissions

This later becomes its own cooldowns module, which means cooldowns can be toggled independently from channels or moderation.

emojis.yml

This file maps tokens or patterns into cosmetic replacements.

Typical uses:

• converting short codes into symbols
• giving donors or ranks special chat cosmetics
• adding lightweight expression features without a larger formatting plugin

This later becomes the emojis module.

mentions.yml

This file controls player ping behavior.

Typical uses:

• detecting when a player name is mentioned
• sending notify sounds or visual feedback
• styling the visible mention format differently from ordinary text

This later becomes the mentions module.

moderation.yml

This is the old all-in-one moderation pipeline.

It usually covers:

• bad word filtering
• caps control
• link control
• format cleanup
• warning messages
• follow-up actions such as console commands
• bypass permissions for staff or trusted roles

This later becomes one of the biggest structural changes in Modern SIR, because moderation is split into caps.yml, links.yml, swearing.yml, format.yml, and a shared config.yml.

tags.yml

This file provides permission-aware tags or decorative chat markers.

Typical uses:

• rank markers
• donor styling
• chat decorations that are easier to manage than hard-coded prefixes

This later becomes the tags module.

Migration checklist for chat/

When translating this folder into Modern or SIR+:

1. map channels into the new channels/ folder first
2. split moderation logic out of moderation.yml
3. move cooldowns, emojis, mentions, and tags into their own modules
4. review permission names because several command-side nodes are renamed
5. test player data migration for chat color, chat view, ignore, and mute separately

---

Hook

Legacy hook/ is the other big umbrella folder. It groups external integrations that later become dedicated modules.

Files

• discord.yml
• login.yml
• vanish.yml

discord.yml

This file is the bridge between SIR events and Discord-side output.

It is commonly used for:

• join and quit relays
• chat relays
• advancement relays
• formatting messages for Discord bridges or webhook-style delivery

This later becomes the discord module, while shared webhook targets keep living in the plugin root webhooks.yml.

login.yml

This file coordinates with authentication plugins.

It is commonly used for:

• login-aware spawn flow
• delaying visible onboarding behavior until the player is authenticated
• keeping first-join or join behavior aligned with login protection

This later becomes the login module.

vanish.yml

This file controls how vanished staff should behave inside chat-sensitive systems.

It commonly covers:

• whether vanished staff can speak freely
• whether a special key or rule must be satisfied first
• how hidden staff are treated in public-facing chat flows

This later becomes the vanish module.

Why hook/ deserves special care

Unlike purely local modules, this folder is sensitive to external plugins. That means a migration can look correct on disk and still behave differently if your Discord bridge, login plugin, or vanish plugin changed at the same time.

---

Join and Quit

Legacy join_quit/ controls the player-entry and player-exit presentation layer.

Files

• config.yml
• messages.yml

What it does

• replaces vanilla join and quit broadcasts
• separates first-join messaging from ordinary join messaging
• applies reconnect cooldowns to reduce spam
• can coordinate with spawn or onboarding behavior

What messages.yml usually owns

• first join text
• normal join text
• quit text
• priority or sound definitions if your configuration uses them

What config.yml usually owns

• whether vanilla messages are disabled
• cooldown behavior for reconnects
• onboarding flags that should happen before or after other login-aware systems

Migration notes

This becomes the join-quit module in newer branches and often works together with the separate login module. That is why a Legacy server that felt like it had one onboarding system may look like two coordinated modules after migration.

---

MOTD

Legacy motd/ controls how the server appears in the multiplayer server list.

Files

• config.yml
• motds.yml
• icons/server-icon.png

What it does

• rotates or selects MOTD entries
• controls displayed max-player or custom-player-count behavior
• loads icons from the module icon folder
• styles the final text seen in the client server list

What admins usually edit first

• motds.yml if they want multiple advertisements or rotating text
• config.yml if they want to force a certain icon or change random behavior
• the icon file if branding changed

Migration notes

This folder becomes modules/motd/. The feature concept stays familiar, so the main work is checking file names and confirming that the generated icon path still matches your preferred asset.

---

Recommended reading order

1. Legacy Branch
2. Legacy Commands
3. Configuration Layout
4. Migration Guide