What the addon runtime actually is

SIR+ adds a dedicated addon loader on top of the normal module and provider system. Instead of patching the base plugin, you can drop jars into the addon runtime and let SIR+ manage them.

At a high level, the loader:

1. scans addon jars
2. looks for addon.yml
3. loads the main class
4. verifies dependency conditions
5. initializes the addon
6. registers addon commands if the addon is also a CommandProvider
7. persists enabled or disabled addon state

Runtime layout

The addon runtime lives under plugins/SIR-Plus/addons/:

plugins/SIR-Plus/
  addons/
    states.yml
    my-addon.jar
    another-addon.jar

What each piece is for

addon.yml requirements

The loader expects an addon.yml file at the jar root. If it is missing, SIR+ skips the jar.

Typical descriptor:

main: com.example.siraddons.ExampleAddon
name: example-addon
title: Example Addon
description:
  - Adds custom logic on top of SIR+.
depend: []
soft-depend: []

Descriptor fields

Addon dependencies here are addon-to-addon dependencies, not Bukkit plugin dependencies.

Loader behavior and dependencies

SIR+ enforces several checks while loading:

Addon hard and soft dependencies

• depend must already be present as another addon, or loading is rejected
• soft-depend is optional and only affects ordering or optional behavior

Bukkit plugin dependencies

If your addon implements PluginDependant, SIR+ also evaluates plugin dependencies such as PlaceholderAPI, Vault, or anything else your addon names.

If the dependency is missing, the loader can defer the addon until the dependency becomes available instead of failing permanently.

Main class contract

The main class must extend SIRAddon. If it does not, SIR+ refuses to load the jar.

Addon lifecycle

Your addon normally extends SIRAddon and implements:

• register()
• unregister()

The common lifecycle expectation is:

• use register() to create files, register listeners, schedule tasks, and hook placeholder expansions
• use unregister() to undo those registrations and release resources

Because SIRAddon extends the shared extension model, you also get helper behavior such as:

• getDataFolder()
• getLogger()
• getResource(path)
• saveResource(path, replace)

Addon commands

If the addon also implements CommandProvider, SIR+ will ask the command manager to load commands from the addon after the addon registers successfully.

That means an addon can contribute:

• one or more SIRCommand implementations
• a commands.yml descriptor at the jar root
• provider metadata understood by the same command system used by the stock built-in providers

This is what makes addon commands feel native instead of bolted on.

Bundled addon jars

SIR+ can also inspect bundled addon jars packaged inside the plugin resources under addons/.

In practice this means the runtime can:

• discover bundled addon jars
• copy them into the data folder when saving defaults
• or temp-load them directly when needed

That design keeps the addon system flexible for both stock distribution and custom server deployments.

Managing addons in production

The operational controls are:

The result is persisted to addons/states.yml, so the enabled state survives restarts.

Troubleshooting checklist

If an addon jar is ignored or fails to work, check these first:

1. addon.yml exists at the jar root
2. the main class extends SIRAddon
3. hard addon dependencies listed in depend are present
4. plugin dependencies declared through PluginDependant are available
5. the addon is enabled in addons/states.yml
6. if it exposes commands, commands.yml exists and the addon implements CommandProvider

If you are writing the addon itself, continue with Addons API.