Deep reference for every built-in SIR 2.0.0 module, including files, config ownership, commands, integrations, and Legacy migration context.

Modern module reference

Modern SIR ships real module units under module/*, and the runtime extracts them into plugins/SIR/modules/. Each module has its own lifecycle, its own module.yml, and usually its own data files.

This page focuses on the operational questions admins actually ask:

what does this module own
which files matter first
which commands or integrations touch it
what changed compared with Legacy

Shared rules for every module

Every bundled module is governed by modules/states.yml.

That means:

the folder can exist on disk while the module is disabled
reload or migration issues should be checked against modules/states.yml before editing random configs
module.yml describes identity and metadata, while the rest of the files define behavior

Advancements

The advancements module handles progression broadcasts and advancement-triggered reactions.

Files

module.yml
config.yml
data.yml
messages.yml

What it owns

filtering by world or game mode
advancement-specific formatting
player-facing progression messages
command reactions for reward or automation flows

What to review first

world filters in config.yml
advancement groups or categories in messages.yml
any command reactions you expect to still work after migration

Migration from Legacy

This is one of the cleanest Legacy migrations because the old advancements/ folder already behaved like a single-purpose module. The main differences are cleaner file separation and more predictable state handling.

Announcements

The announcements module owns the timed broadcast system and also exposes the built-in /announce command family.

Files

module.yml
config.yml
announcements.yml
commands.yml
lang.yml

What it owns

broadcast rotation timing
random versus ordered playback
announcement payloads
command aliases, permission nodes, and help text for the module-owned command

What it offers

automated server announcements
manual announcement execution
cleaner separation between content, config, and command metadata than the Legacy branch

Admin note

This module is a good reminder that not every command in Modern SIR comes from command/*. Some commands, like /announce, live inside their feature module because they are tightly coupled to that feature's data.

Channels

The channels module is the backbone of the modern chat stack.

Files

module.yml
channels.yml
config.yml
commands.yml
lang.yml

What it owns

channel definitions
default channel selection
audience and access behavior
format layout and presentation rules
the built-in /chat-view command

Channels v2 structure

The current channels.yml is a version 2 file and the runtime can migrate legacy or hybrid channel files into that layout automatically.

Every channel now maps cleanly to the runtime ChatChannel model:

access controls default reachability, prefixes, command shortcuts, and prefix stripping
audience controls radius, same-world behavior, recipient permission or group filters, world filters, and whether the sender is forced into the final audience
style controls tag, prefix, suffix, base color, color permissions, click and hover metadata, and the final rendered chat format
logging controls whether the channel uses dedicated logging and which format is written when it does

That split matters because modern SIR no longer treats a chat channel as just "one format plus one prefix". The route, audience, visible style, and logging rules are all first-class channel parts now.

Why it matters

Legacy treated most chat behavior as one umbrella folder. Modern SIR makes channels the routing layer and then lets other modules add behavior around it.

What admins usually edit first

channels.yml for actual channel definitions
config.yml for global message handling behavior
commands.yml if they want to adjust /chat-view

Runtime contract used by the module

Internally, the stock module now builds channels through com.bitaspire.sir.channel.ChatChannel and its grouped subcontracts:

Access
Audience
Style
Logging

If you compare modern code with older examples, this is the important change: ChatChannel is no longer a flat contract that exposes everything directly. The modern runtime separates routing and formatting concerns so they can evolve independently.

Migration notes

If your old server used resources/modules/chat/channels.yml, this is the primary landing spot. The migration will still feel bigger than it looks because channel routing is now separate from moderation, cooldowns, mentions, and tags.

Cooldowns

The cooldowns module slows down repeated or spammy chat behavior.

Files

module.yml
cooldowns.yml

What it owns

timing definitions for throttled actions
cooldown logic that complements channels or moderation
permission-sensitive pacing where some players or ranks should bypass limits

Why it exists as a separate module

Legacy mixed this logic into the larger chat/ folder. Modern SIR isolates it so operators can disable or tune cooldown behavior without touching channel routing or moderation.

Discord

The discord module handles the stock Discord-facing side of SIR.

Files

module.yml
config.yml

What it owns

mapping SIR events to Discord outputs
selecting server or channel targets
formatting relay messages for stock event flows

What it usually works with

root webhooks.yml
join and quit events
chat events
advancement or progression events

Migration from Legacy

This is the dedicated replacement for resources/modules/hook/discord.yml. The benefit is that the Discord bridge is now a real module with its own state instead of one subsection inside a hook umbrella.

Emojis

The emojis module handles cosmetic token replacement in chat.

Files

module.yml
emojis.yml

What it owns

emoji definitions
token or pattern replacement behavior
permission-aware access to cosmetic replacements

Good use cases

donor cosmetics
server-specific expressions
lightweight chat enrichment without needing a much larger formatting plugin

Migration from Legacy

This is the standalone successor to resources/modules/chat/emojis.yml.

Join and Quit

The join-quit module owns stock player-entry and player-exit messaging.

Files

module.yml
config.yml
messages.yml

What it owns

join, quit, and first-join messages
reconnect cooldown behavior
flags that coordinate onboarding flow

What admins usually review

whether vanilla join and quit messages are disabled
how first-join differs from normal join
whether reconnect spam is rate-limited

Migration notes

This is the structured replacement for Legacy join_quit/. If your onboarding logic also depended on auth plugins, review this module together with login.

The login module is intentionally small on disk but still important in behavior.

Files

module.yml

What it owns

auth-aware coordination points
lifecycle behavior around supported login plugins
a separate enable-state boundary for login-sensitive flows

Why the folder looks small

Most of the value here is integration logic rather than a large standalone config tree. Even so, it matters because it changes how the player lifecycle behaves when an auth plugin is present.

Migration from Legacy

This is the dedicated successor to resources/modules/hook/login.yml.

Mentions

The mentions module handles player pings and mention formatting.

Files

module.yml
mentions.yml

What it owns

player-name mention detection
notify sounds
visible mention styling
rule sets around when a ping should fire

Operational value

This is one of the quality-of-life modules that players notice immediately, especially on active survival or community servers.

Migration from Legacy

This cleanly replaces resources/modules/chat/mentions.yml.

Moderation

The moderation module is one of the biggest structural improvements in Modern SIR.

Files

module.yml
config.yml
caps.yml
format.yml
links.yml
swearing.yml

What it owns

caps checks
link checks
swearing checks
message formatting cleanup
staff notifications
logging of violations
bypass and action rules per moderation lane

Why it is better than Legacy

Legacy stored this whole system in one moderation.yml. Modern SIR splits each lane into its own file, which makes it much easier to:

disable one lane without touching the others
understand which rule caused a violation
audit staff bypass permissions
migrate only one part of the moderation logic at a time

What admins usually edit first

global notify and logging behavior in config.yml
links.yml for allowed domains and punishments
swearing.yml for banned words and replacements
caps.yml for thresholds
format.yml for cleanup or capitalization policy

MOTD

The motd module owns the server-list presentation layer.

Files

module.yml
config.yml
motd.yml
icons/server-icon.png

What it owns

available MOTD entries
random or ordered selection
displayed max-player behavior
icon loading from the module icon folder

Good operational habits

keep a backup of your preferred icon asset
verify client-side formatting after updates
review config.yml if the displayed player count should differ from the real one

module.yml
config.yml

What it owns

rules for how vanished staff interact with chat systems
special gates or key behavior before hidden staff can speak
compatibility logic with supported vanish plugins

Migration from Legacy

This replaces resources/modules/hook/vanish.yml and makes vanish behavior easier to reason about because it has a dedicated state and folder.

Modern Modules

On this page