Deep reference for every bundled SIR+ module, including files, runtime responsibilities, configs, and how addons should coexist with them.

SIR+ built-in module reference

SIR+ keeps the same stock module inventory as Modern SIR, but those modules now live inside a runtime that can also load addons. That means every built-in module has two contexts:

the normal feature context inherited from SIR 2.0.0
the addon-capable runtime context unique to SIR+

Read this page when you want to know what the built-in platform already gives you before you decide to add or replace behavior with an addon.

Shared rules in SIR+

Every bundled module still uses:

modules/states.yml for enable state
its own extracted folder under plugins/SIR-Plus/modules/
its own module.yml metadata file

The new rule in SIR+ is that addons should usually complement these built-ins instead of trying to pretend they do not exist.

Advancements

The advancements module is the stock progression-broadcast system.

Files

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

What it owns

world and game-mode filters
advancement-specific message formatting
command reactions tied to advancement completion

What it offers in practice

progression broadcasts without writing a custom listener
filtering so lobbies or restricted worlds stay quiet
reward or automation hooks through command execution

If an addon wants to react to progression, the safest design is usually to extend around this module instead of replacing it. Let the built-in module keep the default user-facing broadcast layer and use addons for extra effects or server-specific logic.

Announcements

The announcements module owns timed broadcasts and the stock /announce command family.

Files

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

What it owns

interval and randomization behavior
announcement content rotation
module-owned command metadata
announcement language feedback

What it offers in practice

rotating server notices
manual announcement execution
content and command logic kept in one feature boundary

SIR+ angle

Addons can coexist with announcements, but most servers should keep stock broadcast rotation here and reserve addons for custom business logic, seasonal systems, or advanced scheduling behavior.

Channels

The channels module is still the core chat-routing system in SIR+.

Files

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

What it owns

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

Channels v2 runtime model

SIR+ follows the same channels v2 structure as modern SIR. That means a channel is now represented by a grouped runtime contract instead of one flat interface.

The stock runtime separates channel state into:

Access for prefixes, command triggers, default accessibility, and prefix stripping
Audience for radius, same-world checks, recipient filters, world filters, and sender inclusion
Style for tag, prefix, suffix, colors, hover, click metadata, and the final chat format
Logging for per-channel logging enable state and custom log output

In practice, channels.yml now maps much more directly to the runtime object model, which makes addon-side integrations easier to reason about.

Why it matters

Most chat-oriented addons have to coexist with this module. Even if an addon adds extra logic, channel routing remains the stock source of truth for where messages should go and who should see them.

SIR+ angle

Before writing an addon that touches chat, decide whether it should:

enrich messages after channels resolve them
add commands that cooperate with channel state
or truly replace a stock route

That decision affects whether you need addon logic, provider override changes, or only channel config edits.

API angle for addon authors

If an addon reads or wraps channels, target com.bitaspire.sir.channel.ChatChannel.

That is the canonical contract used by the current SIR+ runtime. Older examples that imported com.bitaspire.sir.ChatChannel are now relying on the deprecated compatibility bridge kept for pre-0.3.2 addons.

Cooldowns

The cooldowns module controls stock anti-spam pacing.

Files

module.yml
cooldowns.yml

What it owns

throttling rules for repeated chat actions
permission-sensitive cooldown lanes
baseline pacing behavior that protects chat quality

SIR+ angle

Addon authors should usually not duplicate cooldown logic everywhere. If a feature belongs to normal player communication, it is often better to respect this built-in pacing layer and only add custom behavior where truly needed.

Discord

The discord module is the stock bridge from SIR events into Discord-aware output.

Files

module.yml
config.yml

What it owns

event relay mapping
server and channel targeting
formatting for stock Discord-facing events

What it usually works with

webhooks.yml
join and quit events
chat relays
advancement relays

SIR+ angle

If an addon wants to publish extra messages to Discord, keep the ownership split clear:

built-in Discord module for stock events
addon logic for custom domain-specific events

That makes troubleshooting easier because operators know whether to inspect the module config or the addon jar.

Emojis

The emojis module handles stock cosmetic replacements in chat.

Files

module.yml
emojis.yml

What it owns

emoji definitions
token replacement behavior
permission-aware cosmetic enrichment

SIR+ angle

This is a good example of something that should usually stay built-in. Addons can build around it, but most servers do not need a separate addon just to manage tokens or simple replacements.

Join and Quit

The join-quit module owns stock onboarding and leave messaging.

Files

module.yml
config.yml
messages.yml

What it owns

join messages
first-join messages
quit messages
reconnect cooldown behavior

Why it matters

This is still the first stop for entry UX even on addon-heavy servers. A server can have five addons and still rely on this stock module for the actual first impression players receive.

SIR+ angle

If an addon reacts to joins, decide whether it should:

extend the onboarding flow after the stock message
replace a stock message entirely
or only add invisible backend logic

That decision avoids duplicate announcements or conflicting onboarding behavior.

The login module remains small on disk but important in lifecycle behavior.

Files

module.yml

What it owns

login-aware coordination points
supported auth-plugin integration behavior
a clear enable-state boundary for login-sensitive flows

SIR+ angle

If your addons depend on players being fully authenticated before they initialize per-player state, design them with this module in mind. Otherwise you can accidentally run addon behavior too early in the player lifecycle.

Mentions

The mentions module handles stock name ping behavior.

Files

module.yml
mentions.yml

What it owns

detection of player-name mentions
notify sounds and feedback
visible styling of mentions

SIR+ angle

Addon authors can complement this with richer notification systems, but the built-in mention workflow is still the lowest-friction way to deliver normal player pings.

Moderation

The moderation module is the stock chat policy system.

Files

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

What it owns

caps control
link control
swearing control
formatting cleanup
staff notifications
logging of violations
bypass and actions per moderation lane

Why it matters in SIR+

This is a place where admins are often tempted to write custom addons too early. In most cases the built-in moderation module already covers the common policy surface and should remain the default enforcement layer.

When addons make sense here

Addons are more appropriate when you need:

custom data sources
external web-service checks
niche event handling
server-specific escalation logic that does not belong in the stock module

MOTD

The motd module owns server-list presentation.

Files

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

What it owns

available MOTD entries
selection behavior
player-count presentation
icon loading from the module folder

module.yml
config.yml

What it owns

hidden-staff chat behavior
gate or key rules before vanished staff can speak
compatibility with supported vanish plugins

SIR+ angle

Any addon that touches chat, private messaging, or moderation should be tested with vanished staff online. This module remains the stock source of truth for that behavior.

Built-in Modules

On this page