You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e849864
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: README.md
+12-9Lines changed: 12 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,20 +2,22 @@
2
2
PaperExamplePlugin
3
3
</h1>
4
4
5
-
A template repository for creating Paper (Minecraft) plugins with Kotlin. It comes with an auto-registration system for commands, listeners, permissions, and GUIs — just extend a base class, drop it in the right package, and the plugin handles the rest.
5
+
A template repository for creating Paper (Minecraft) plugins with Kotlin. It comes with an auto-registration system for
6
+
commands, listeners, permissions, and GUIs — just extend a base class, drop it in the right package, and the plugin
7
+
handles the rest.
6
8
7
9
## Getting Started
8
10
9
11
1. Click **"Use this template"** on GitHub to create your own repository.
10
12
2. Replace the placeholder values below with your own:
Copy file name to clipboardExpand all lines: docs/COMMIT_STRUCTURE.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,10 @@
1
1
# ExamplePlugin - Commit Structure
2
2
3
-
To maintain a clean and organized codebase, all developers must follow the standardized commit message format. This ensures that changes to features are easy to track.
3
+
To maintain a clean and organized codebase, all developers must follow the standardized commit message format. This
4
+
ensures that changes to features are easy to track.
4
5
5
6
## Basic Structure
7
+
6
8
Every commit message must follow this syntax:
7
9
`<tag>: <message>`
8
10
@@ -18,6 +20,7 @@ Every commit message must follow this syntax:
18
20
|**Update**| Plugin version changes. |`Update: 1.0.0 release`|
19
21
20
22
## Best Practices
23
+
21
24
***Use Present Tense:** Write "Add feature" instead of "Added feature."
22
25
***Be Specific:** Instead of `Fix: bug`, use `Fix: Handle undefined member in /role command`.
23
26
***No Period at End:** Do not end the commit message with a period.
Copy file name to clipboardExpand all lines: docs/DEVELOPER_GUIDE.md
+57-43Lines changed: 57 additions & 43 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,19 +1,24 @@
1
1
# ExamplePlugin - Developer Guide
2
2
3
-
This guide explains how to create **commands**, **listeners**, and **GUIs** using ExamplePlugin's registration system. All three follow the same pattern: extend a base class (or implement an interface), place the file in the correct package, and the plugin handles the rest automatically at startup.
3
+
This guide explains how to create **commands**, **listeners**, and **GUIs** using ExamplePlugin's registration system.
4
+
All three follow the same pattern: extend a base class (or implement an interface), place the file in the correct
5
+
package, and the plugin handles the rest automatically at startup.
4
6
5
7
## How Auto-Registration Works
6
8
7
-
ExamplePlugin uses a `PackageScanner` to discover classes at runtime. When the plugin starts, it scans specific packages for concrete (non-abstract) classes and registers them automatically. You never need to edit `plugin.yml` or manually wire anything up.
9
+
ExamplePlugin uses a `PackageScanner` to discover classes at runtime. When the plugin starts, it scans specific packages
10
+
for concrete (non-abstract) classes and registers them automatically. You never need to edit `plugin.yml` or manually
Subpackages are also scanned, so you can freely organize classes into folders like `commands/game/`, `listeners/player/`, or `guis/menus/`.
20
+
Subpackages are also scanned, so you can freely organize classes into folders like `commands/game/`,
21
+
`listeners/player/`, or `guis/menus/`.
17
22
18
23
## Constructor Requirements
19
24
@@ -32,52 +37,59 @@ The plugin instance is injected automatically when a `JavaPlugin` constructor is
32
37
33
38
To create a command, extend `PluginCommand` and place the class anywhere inside the `commands` package or a subpackage.
34
39
35
-
By default every command is registered as a **sub-command** of `/exampleplugin` (alias `/ep`). For example, a command with `name = "reload"` becomes `/exampleplugin reload`. Set `isMainCommand = true` to register the command as a standalone top-level command instead.
40
+
By default every command is registered as a **sub-command** of `/exampleplugin` (alias `/ep`). For example, a command
41
+
with `name = "reload"` becomes `/exampleplugin reload`. Set `isMainCommand = true` to register the command as a
42
+
standalone top-level command instead.
36
43
37
44
When a player types `/exampleplugin` in-game, tab-completion automatically lists all available sub-commands.
38
45
39
46
### Categories
40
47
41
-
Commands are automatically categorised based on their **subpackage** (folder) inside the `commands` package. The category is used by the built-in `/exampleplugin help` command to group commands for display.
48
+
Commands are automatically categorised based on their **subpackage** (folder) inside the `commands` package. The
49
+
category is used by the built-in `/exampleplugin help` command to group commands for display.
The plugin ships with a built-in `/exampleplugin help` command. It lists every registered command grouped by category, sorted alphabetically within each group, and formatted with colours for readability. Every command should provide a meaningful `description` so the help output is informative.
59
+
The plugin ships with a built-in `/exampleplugin help` command. It lists every registered command grouped by category,
60
+
sorted alphabetically within each group, and formatted with colours for readability. Every command should provide a
61
+
meaningful `description` so the help output is informative.
|`name`|`String`|*(required)*| The command name (e.g. `"reload"` for `/exampleplugin reload`) |
68
+
|`description`|`String`|`""`| A brief description shown in `/exampleplugin help` — always provide one |
69
+
|`usage`|`String`|`"/<command>"`| Usage hint shown when the command fails |
70
+
|`aliases`|`List<String>`|`emptyList()`| Alternative names for the command (applicable to main commands only) |
71
+
|`permission`|`String?`|`null`| Permission node required to use the command (auto-registered at startup) |
72
+
|`isMainCommand`|`Boolean`|`false`| When `true`, the command is registered as a standalone top-level command |
63
73
64
74
### Automatic Permission Registration
65
75
66
-
When the plugin starts, the `PermissionRegistrar` scans every registered command for a non-null `permission` value and automatically registers it with Bukkit's `PluginManager`. This means:
76
+
When the plugin starts, the `PermissionRegistrar` scans every registered command for a non-null `permission` value and
77
+
automatically registers it with Bukkit's `PluginManager`. This means:
67
78
68
79
* Permissions are visible to permission-management plugins (e.g. LuckPerms) without manual configuration.
69
80
* Each permission defaults to `PermissionDefault.OP` — only operators have it unless explicitly granted.
70
81
* The command's `description` is used as the permission description.
71
82
* Duplicate permissions (already registered by another source) are detected and skipped.
72
83
73
-
You do **not** need to declare permissions in `plugin.yml`; simply set the `permission` property on your command and the system handles the rest.
84
+
You do **not** need to declare permissions in `plugin.yml`; simply set the `permission` property on your command and the
0 commit comments