> For the complete documentation index, see [llms.txt](https://medieval-kingdoms.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://medieval-kingdoms.gitbook.io/docs/getting-started/editor.md).

# Medieval Plugin

## Setup

When creating a plugin for Minecraft using Spigot or PaperMC, the first step is usually to extend the abstract class `JavaPlugin`.\
\
In our case, **MedievalPlugin** serves the same purpose. By extending `MedievalPlugin`, you get the same functionality as `JavaPlugin`, with a few extra lifecycle methods provided by default:

* `onInitialize`
* `onPostInitialize`
* `onShutdown` 

```java
public class TestPlugin extends MedievalPlugin {

    @Override
    public void onInitialize(MedievalPlugin plugin) {

    }

    @Override
    public void onPostInitialize(MedievalPlugin plugin) {

    }

    @Override
    public void onShutdown(MedievalPlugin plugin) {

    }
}
```

## Stages

### Initialize

The **initialize** stage is when the plugin begins loading. This is where dependency checks are performed and core classes are registered into the registry.

### Post Initialize

As the name suggests, the **post-initialize** stage runs after initialization has completed successfully. This is the point where you should register commands, listeners, and other systems that depend on managers, services, or dependencies being available. In other words, this stage occurs while the plugin is being fully enabled.

### Shutdown

The **shutdown** stage occurs when the plugin is being disabled. Any cleanup logic, such as saving data or closing database connections, should be handled here.

## Registering

### Commands

Command registration must occur in the post-initialize stage, after the plugin has completed its initialization stage. You can see more about how commands work [here](/docs/implementation/markdown.md). This is an example of how to register a command.

```java
@Overrid
public void onPostInitialize(MedievalPlugin plugin) {
    registerCommands(new TestCommand());
}
```

### Listeners

Listener registration must occur in the post-initialize stage also. We do not have anything special for listeners, they are just the same old Bukkit listeners. Here is an example on how to register them:

```java
@Override
public void onPostInitialize(MedievalPlugin plugin) {
    registerListeners(new TestListener());
}
```

### Registrable

A **`Registrable`** is a generic interface that marks a class as eligible for inclusion in the registry. Any component that requires lifecycle management or global accessibility—such as managers, services, or other core systems—should implement this interface.

All `Registrable` instances must be registered during the **initialization stage**, ensuring that dependent systems (e.g., command handlers, registries, or managers) have access to their functionality before the post-initialize phase.

For example, a **manager** implementation can be defined as a `Registrable` to guarantee it is available when other components are initialized.

You can see more about how a registrable works [here](/docs/implementation/images-and-media.md). This is how we can register them:

```java
@Override
public void onInitialize(MedievalPlugin plugin) {
    register(PlayerManager.class, new PlayerManagerImpl());
}
```