mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-30 12:15:56 +00:00
ca56e9577d
* feat: add minecraft-plugin-development skill * docs: expand minecraft plugin skill patterns * docs: add minecraft skill examples * docs: generalize minecraft skill patterns * docs: expand minecraft progression guidance * docs: add minecraft plugin validation workflow --------- Co-authored-by: jiang <helloworld@jiang.cn>
101 lines
3.5 KiB
Markdown
101 lines
3.5 KiB
Markdown
# Bootstrap And Registration
|
|
|
|
Use this reference when changing `onEnable`, `onDisable`, command setup, event wiring, or startup ordering.
|
|
|
|
## Bootstrap pattern from real plugins
|
|
|
|
### Match-heavy minigame bootstrap
|
|
|
|
Common traits:
|
|
|
|
- connect database first
|
|
- register configuration serialization when needed
|
|
- initialize multiple config managers
|
|
- create gameplay managers and GUI helpers
|
|
- apply lobby UI to already-online players
|
|
- register many listeners explicitly
|
|
- start repeating tasks
|
|
- register commands and tab completers last
|
|
|
|
This pattern works well when startup must assemble many gameplay subsystems before the server can safely accept interactions.
|
|
|
|
### Persistent class-brawl bootstrap
|
|
|
|
Common traits:
|
|
|
|
- save default config and bundled resources first
|
|
- construct config wrapper and progression config
|
|
- connect database and create repository/service layers
|
|
- construct scoreboard, map, hero, and game services
|
|
- wire service dependencies together
|
|
- start background tasks
|
|
- preload async cache, then schedule main-thread UI refreshes
|
|
- register listeners and commands after service graph is ready
|
|
|
|
This pattern works well when player data and async services are first-class dependencies.
|
|
|
|
## Command registration rules
|
|
|
|
Observed practices:
|
|
|
|
- Match-heavy minigames often declare all commands in `plugin.yml`, then set executors and tab completers in code.
|
|
- Persistent brawl modes may declare a small command surface such as `leave`, then null-check `getCommand` before assigning the executor.
|
|
|
|
Recommended rules:
|
|
|
|
- always add new commands to `plugin.yml`
|
|
- if a command may be optional or renamed, null-check `getCommand`
|
|
- if tab completion exists, register it in the same change
|
|
- keep usage, permission, and permission-message aligned with actual code behavior
|
|
|
|
## Listener registration rules
|
|
|
|
Observed practices:
|
|
|
|
- both plugins register listeners in one place during startup
|
|
- listener constructors receive only the services they actually need
|
|
|
|
Recommended rules:
|
|
|
|
- keep registration centralized in the main plugin class or a clearly named bootstrap helper
|
|
- inject services explicitly instead of having listeners discover globals everywhere
|
|
- if a listener depends on a task, GUI, or manager, construct that dependency first
|
|
|
|
## Repeating tasks and startup ordering
|
|
|
|
Observed practices:
|
|
|
|
- Match-heavy minigames often start periodic gameplay tasks directly from startup for boundary checks and spectator UI refreshes
|
|
- Persistent brawl modes often start background tasks via services such as player data and game services
|
|
|
|
Recommended rules:
|
|
|
|
- start repeating tasks only after required state holders exist
|
|
- cancel them in shutdown
|
|
- if the task mutates gameplay state, ensure it runs on the main thread
|
|
- if the task does I/O or cache rebuilds, prefer async execution and hop back to main thread for Bukkit work
|
|
|
|
## Shutdown expectations
|
|
|
|
Observed practices:
|
|
|
|
- Match-heavy minigames delete games, unload maps, flush pending stats, close DB resources, and clear sidebars
|
|
- Persistent brawl modes shut down game service, player data service, map manager, then disconnect database
|
|
|
|
Recommended rules:
|
|
|
|
- stop tasks
|
|
- flush dirty data
|
|
- detach or clear UI objects
|
|
- unload temporary worlds if your plugin creates them
|
|
- close database pools last
|
|
|
|
## Contribution guidance for this skill
|
|
|
|
When generating code for startup or shutdown, mention:
|
|
|
|
- which config or resource files must exist
|
|
- which commands or listeners must be registered
|
|
- what tasks must be started or canceled
|
|
- what resources require cleanup on disable
|