- 版权类型
- 原创
- 适配版本(Java)
- 1.21
- 1.20
- 1.19
- 1.18
- 1.17
- 1.16
- 1.15
- 1.14
- 1.13
- 1.12
- 1.11
- 1.10
- 1.9
- 1.8
做插件做了这么久,经常遇到想写一个新插件,但是新建项目好麻烦,导入依赖好麻烦等等等等。
安装 Minecraft Development 也不太顶用,用它自带的插件模板依然要做很多重复工作消磨热情,比如添加仓库等等。
今后我新做的 Sweet 系列插件,如果不是功能非常简单,基本都会用这个依赖库来写。
我简单总结一下,这个依赖大约覆盖了以下功能:
至于为什么不把生成器做到 IDEA 插件的项目模板,是我不想去维护插件,要随 IDEA 更新插件太麻烦了。
项目生成器网站:https://bukkit.mcio.dev/
开发相关的详细内容请阅读开发文档,有一定的学习成本,不推荐Bukkit新手使用。
这个项目的设计目标,除了减少我的工作量以外,还有一点是使得我的插件基本都是使用同一套逻辑。
界面管理器保证了只要我的插件里出现了自定义界面,那么配置文件格式都大差不差;
本地化管理器保证了只要我的插件里有文字,那么语言文件格式都大差不差;
操作执行器保证了只要有一些操作是需要管理员去自定义的,那么操作格式都大差不差。
这些相同的逻辑能帮助我、我服务器的管理员、其它服务器的管理员,更方便地编写和使用我的插件。
猫猫的通用技术交流群:1047497524
安装 Minecraft Development 也不太顶用,用它自带的插件模板依然要做很多重复工作消磨热情,比如添加仓库等等。
今后我新做的 Sweet 系列插件,如果不是功能非常简单,基本都会用这个依赖库来写。
我简单总结一下,这个依赖大约覆盖了以下功能:
- 在结构设计上,设计了必须要将其 shadow 打包到插件里面的机制,不需要用户额外安装依赖插件。
- 很多功能都是可选的,比如基于 HikariCP、Adventure(Bukkit+MiniMessage)、item-nbt-api 等等的功能,只要你不添加依赖,不启用功能,就不会给你的插件额外增加无用的大小。
- 默认使用 spigot-api,封装了一些 paper-api 的 fallback,比如 adventure 支持(需要自己开启),以兼容非 paper 系的服务端。
- 支持在聊天、物品名、物品Lore使用 MiniMessage 格式消息。
- HikariCP 数据库连接池支持 (MySQL/SQLite)。
- 一些基本的工具,比如字符串转数字、字符串转 Material 等等。
- 模块注册机制,可以将单个功能做成一个单例的模块类(继承
AbstractModule
),然后添加注解@AutoRegister
,模块会在插件启用时自动实例化并注册,还可以设定有哪些软依赖插件已安装时才注册模块。以及设定优先级,调整模块的初始化和读取配置执行顺序等等。 - 界面管理器,安全地为玩家打开你想要的菜单,虽然还没做翻页什么的还是有点鸡肋,但基本能用。另外附带了操作执行器(
ActionProviders
),可以从配置文件读取一些简单操作(控制台命令、玩家命令、聊天提示等等)去执行。 - 本地化(语言)管理器,基于枚举的本地化条目注册,可自由地将条目读取为
String
或List<String>
,并且两者都支持String.format
格式化和自定义变量替换,喜欢用什么方式就用什么方式。 - 本地依赖库加载器,默认关闭,我自己用得不是很多。一般都是用来加载额外的 JDBC 驱动(SweetMail)或者需要特定时机加载附属(SweetAutoResidence)。
至于为什么不把生成器做到 IDEA 插件的项目模板,是我不想去维护插件,要随 IDEA 更新插件太麻烦了。
项目生成器网站:https://bukkit.mcio.dev/
开发相关的详细内容请阅读开发文档,有一定的学习成本,不推荐Bukkit新手使用。
这个项目的设计目标,除了减少我的工作量以外,还有一点是使得我的插件基本都是使用同一套逻辑。
界面管理器保证了只要我的插件里出现了自定义界面,那么配置文件格式都大差不差;
本地化管理器保证了只要我的插件里有文字,那么语言文件格式都大差不差;
操作执行器保证了只要有一些操作是需要管理员去自定义的,那么操作格式都大差不差。
这些相同的逻辑能帮助我、我服务器的管理员、其它服务器的管理员,更方便地编写和使用我的插件。
猫猫的通用技术交流群:1047497524