Overview of the current SIR branch, its structure, and what changed from the older line.

What defines SIR 2.0.0?

The modern SIR branch is the current Gradle multi-project version of the plugin. It keeps the all-in-one philosophy, but the codebase and runtime output are much more structured than Legacy.

The repository is split into:

core for shared APIs and managers
plugin for the Bukkit entrypoint, migration logic, and main command
module/* for bundled feature modules
command/* for bundled command providers

This split is the biggest architectural difference between 1.x and 2.0.0.

What you get in Modern SIR

Modern SIR adds a much clearer separation between features, state files, and operator workflows:

dedicated module folders under module/*
dedicated command-provider folders under command/*
/sir modules for module state management
/sir commands for provider state management
/sir migrate [source] for supported migration paths
GUI management for modules and providers on supported server versions
a cleaner modules/, commands/, and users/ data layout

Modern SIR is the branch you want for any fresh install unless you deliberately need the Legacy runtime tree.

Runtime layout

After first startup, the modern branch is built around folders like these:

plugins/SIR/
  config.yml
  bossbars.yml
  webhooks.yml
  users/
    ignore.yml
    mute.yml
    chat-view.yml
    chat-color.yml
    nick.yml
  modules/
    states.yml
    advancements/
    announcements/
    channels/
    cooldowns/
    discord/
    emojis/
    join-quit/
    login/
    mentions/
    moderation/
    motd/
    tags/
    vanish/
  commands/
    lang.yml
    main/lang.yml
    states.yml
    clear-chat/
    color/
    ignore/
    message/
    mute/
    nick/
    print/
    settings/
  back-ups/

What these folders mean

Path	Purpose
`users/`	Persistent player data such as ignores, mutes, chat-view state, and chat color selections
`modules/`	Per-module config folders plus `modules/states.yml`
`commands/`	Shared command language files, per-provider files, and `commands/states.yml`
`back-ups/`	Snapshots created by migration routines so you can audit or roll back old data

nick.yml may appear when nick data is migrated from external sources such as Essentials-style userdata. Even if your stock install does not use every user file immediately, the migration system knows how to populate them when needed.

Built-in feature inventory

Modules

Modern SIR ships these modules:

advancements
announcements
channels
cooldowns
discord
emojis
join-quit
login
mentions
moderation
motd
tags
vanish

Command providers

Modern SIR ships these command providers:

clear-chat
color
ignore
message
mute
nick
print
settings

The detailed file-by-file reference for both sets lives in Modules & Providers.

Shared files you should always review

File	Why you should care
`config.yml`	Global behavior and plugin-level defaults
`bossbars.yml`	Shared bossbar presentation used across commands or events
`webhooks.yml`	Shared webhook target definitions
`commands/lang.yml`	Shared command-side messages such as no-permission text
`commands/main/lang.yml`	`/sir` admin command language and migration feedback
`modules/states.yml`	Source of truth for module enable state
`commands/states.yml`	Source of truth for command provider enable state and per-command override state

Admin workflow in 2.0.0

Modern SIR centers most administration around /sir:

/sir modules
/sir commands
/sir reload
/sir about
/sir support
/sir migrate

On 1.14+, opening /sir modules or /sir commands with no extra arguments gives you a GUI instead of just a text response. On older versions or automation scripts, the CLI form still matters.

For the exact permission nodes and provider commands, open Commands & Permissions.

Extensibility without SIR+

Even base SIR is more modular than Legacy:

ModuleManager persists module state in modules/states.yml
CommandManager persists provider state in commands/states.yml
both managers can inspect bundled jars and external jar-based extensions placed in the expected module or command locations

What Modern SIR does not add is the SIR+ addon runtime. There is no /sir addons layer here and no addons/states.yml.

When should you pick this branch?

Pick Modern SIR when:

you are starting a fresh server setup
you want the maintained 2.0.0 branch
you need the split module/provider architecture
you want the built-in migration path from Legacy SIR or Essentials-style data

If you need a public addon runtime, provider override controls from the admin command, and addon state management, you want SIR+, not base SIR.

What changed from Legacy?

The most important conceptual changes are:

resources/modules/chat is no longer one broad bucket
resources/modules/hook is now split into discord, login, and vanish
command behavior is represented per provider instead of one giant command config
state is persisted in modules/states.yml and commands/states.yml
permissions are cleaner, but some legacy nodes are renamed

If you are upgrading from 1.x, do not copy folders blind. Compare the file trees first in Configuration Layout, then follow Migration Guide.

Modern Branch (2.0.0)