Frequently Asked Questions

Which branch should I choose for a new server?

Choose Modern 2.0.0.

That branch is the maintained split architecture with:

• modules/
• commands/
• users/
• cleaner migration and state handling

Use Legacy 1.7.0 and below only if your live server already depends on the old resources/ layout and you are not ready to migrate yet.

---

Which branch should I choose if my staff already knows the old commands?

If staff muscle memory and permission names are critical right now, staying on Legacy for a little longer can be the safer short-term move. The usual breaking points are:

• /clearchat versus /clear-chat
• /announcer versus /announce
• sir.chatcolor versus sir.color
• sir.mute.perm versus sir.mute

If you do upgrade, communicate the renamed command labels and nodes before the switch.

---

Why do Modern docs talk about modules and command providers separately?

Because Modern SIR split the feature model into two layers:

• module/* owns system features such as channels, moderation, or MOTD
• command/* owns player-facing command families such as color, mute, or message

Some commands still belong to modules, like /announce and /chat-view, which is why both pages matter.

---

Why is a command missing even though the jar loaded?

The most common causes are:

1. the provider is disabled in commands/states.yml
2. the owning module is disabled in modules/states.yml
3. the command label changed between Legacy and Modern
4. another plugin already owns the same command label

Start with Commands & Permissions, then read the detailed provider or module reference.

---

Why does /chat-view feel different from /mute or /color?

Because /chat-view is module-owned.

It belongs to channels, not to a standalone command/* provider. The same idea applies to /announce, which belongs to the announcements module.

---

Can I copy Legacy folders directly into Modern SIR?

No, not safely.

The two biggest reasons are:

• resources/modules/chat/ later becomes several different modules
• resources/modules/hook/ later becomes discord, login, and vanish

Copying blindly usually creates partial configs that look valid on disk but no longer match the new runtime model.

---

Where do player data files live in Modern SIR?

Legacy stored player-oriented command state inside command folders such as:

• resources/commands/chat_color/data.yml
• resources/commands/chat_view/data.yml
• resources/commands/ignore/data.yml
• resources/commands/mute/data.yml

Modern SIR normalizes that into users/, for example:

• users/chat-color.yml
• users/chat-view.yml
• users/ignore.yml
• users/mute.yml

---

What are modules/states.yml and commands/states.yml really for?

They are the operational source of truth for enable state.

modules/states.yml controls bundled module state.

commands/states.yml controls provider state and command-level state for the command layer.

If something vanished after a restart, these files are often more important than the config file you were about to edit.

---

Which permission renames hurt the most during migration?

The most common pain points are:

• sir.clearchat becomes sir.clear-chat
• sir.chatcolor becomes sir.color
• sir.mute.perm becomes sir.mute
• sir.mute.temp becomes sir.temp-mute
• sir.checkmute becomes sir.check-mute

These deserve a dedicated LuckPerms or permissions-plugin review before you swap jars.

---

Why does Modern SIR feel easier to audit than Legacy?

Because the architecture is more explicit.

Legacy grouped too many responsibilities together, especially in:

• resources/modules/chat/
• resources/modules/hook/

Modern splits those into dedicated feature units, so each subsystem has a clearer folder, clearer files, and clearer state.

---

Does base SIR already support extension jars?

Base SIR is modular, but it is not the same as SIR+.

It can load split feature units and manage modules and command providers, but it does not expose the first-class addon runtime, addon state, and public addon API that define SIR+.

---

What migration sources does base SIR support?

The main migration path explicitly supports:

• SIR
• Essentials

When you choose SIR, Modern can detect whether the source is Legacy or already modernized data.

---

Should I edit the jar resources or the generated plugin folder?

Always edit the generated plugin folder in plugins/SIR/.

The jar resources are only the defaults that get extracted. Your real operational configuration is the runtime data folder.

---

What is the safest reading order before a migration?

1. Getting Started
2. Legacy Branch or Modern Branch
3. Legacy Modules or Modern Modules
4. Legacy Commands or Modern Command Providers
5. Configuration Layout
6. Migration Guide