Frequently Asked Questions

When should I choose SIR+ instead of base SIR?

Choose SIR+ when you need more than the stock module and provider catalog.

The biggest reasons are:

• addon jar loading
• addon state management
• per-command override control
• the public SIRApi artifact for addon development
• wider migration coverage, including CMI

If you only want the bundled feature set and no addon runtime, base SIR 2.3.1 is usually enough.

Are the built-in modules different from base SIR?

The stock module and provider inventory is essentially the same foundation as Modern SIR.

What changes in SIR+ is the runtime around them:

• addon jars
• addon state
• extra admin subcommands
• per-command override management

That is why the built-in module and provider docs still matter on an addon-focused server.

Where do addon jars go?

Inside:

plugins/SIR-Plus/addons/

Addon enable state is persisted in:

plugins/SIR-Plus/addons/states.yml

If an addon exists on disk but does not load, inspect:

• the jar root
• addon.yml
• addons/states.yml

Why is an addon not loading?

The most common causes are:

1. addon.yml is missing from the jar root
2. the main class does not extend SIRAddon
3. the addon is disabled in addons/states.yml
4. a required addon dependency declared in depend is missing
5. a required Bukkit plugin dependency is missing

The runtime side of this is documented in Addon Runtime.

Why is an addon command not overriding another plugin command?

In SIR+, provider state and override state are separate concerns.

Check commands/states.yml and confirm:

• the provider is enabled
• the specific command override state is enabled if you expect SIR+ to own that label

This is especially important when you use:

/sir commands [provider] override [command] [state]

Which extra admin permission does SIR+ add?

The permission to remember is:

sir.admin.addons

Without it, staff can manage modules and providers but not the addon runtime.

Can addons replace built-in modules?

Addons extend the platform, but they do not magically erase the built-in module layer.

In practice, addons usually:

• register extra commands through CommandProvider
• use SIRApi to integrate with existing managers
• add extra listeners, integrations, or workflows

You should still treat modules/, commands/, and addons/ as distinct operational layers.

Can SIR+ migrate from Modern SIR too?

Yes.

SIR+ can detect already-modern SIR layouts and copy structured data directly, including:

• users/
• modules/
• commands/
• root shared files such as config.yml, bossbars.yml, and webhooks.yml

This is why SIR+ is a comfortable upgrade target from base SIR 2.x.

What migration sources does SIR+ support?

The main migration path explicitly supports:

• SIR
• Essentials
• CMI

When you choose SIR, the runtime can distinguish between a Legacy source and an already-modern source.

Do I need the API jar just to use SIR+ on a server?

No.

Server operators only need the main plugin jar.

The API artifacts in Addons API are only for developers who want to compile custom addons against SIRApi.

Should I bundle the API jar inside my addon jar?

Usually no.

The normal model is compileOnly or provided, because SIR+ already supplies the real classes at runtime. Bundling the API jar into your addon usually creates unnecessary duplication and can complicate class ownership.

Can an addon and a stock provider coexist?

Yes, but you should decide the ownership model clearly.

Typical patterns are:

• keep the stock provider and let the addon add extra commands
• keep the stock provider but disable override for one conflicting command
• let the addon own a command label completely and relax the stock override

That decision belongs in your runtime plan, not only in the addon code.

What is the fastest troubleshooting order in SIR+?

Use this sequence:

1. confirm the module or provider is enabled
2. confirm the addon is enabled if the feature comes from an addon
3. inspect commands/states.yml for provider and override state
4. inspect addons/states.yml for addon state
5. inspect descriptor files such as commands.yml or addon.yml

Then continue with Command Providers, Addon Runtime, or Addons API depending on what failed.