本帖最后由 William_Shi 于 2022-3-26 09:52 编辑
省流：我不支持使用 Paper，但也没能说服使用 Paper 的开发者。
Paper 强行把传入 String 的方法标记过时，几乎不值得强行辩白。Adventure 由于其出现晚，能从高版本的角度设计 API，在 ChatColor 的架构上优于 Bungee Chat。
日前，一新人开发者问于开发区，诉某方法“居然被不建议使用”。开发者之间，不曾用广播之人，未之闻也。原先的方法无人不晓，今日过时，闻者悚然。欲传檄全服，或曰可遍历玩家列表，实繁。或曰“不妨试试Server.broadcastMessage”。然予翻阅者再，文档论及此方法处亦记为过时。同新手之做法无异。正所谓“听君一席话，如听一席话”。空自旷日持久。
予览其文档，见过时理由，非为安全隐患，罔论性能问题。实以 kyori Adventure API 为是，md_5 BungeeChat API 为非。用 Kyori Component 者辄推荐之，用 md_5 BaseComponent 者即指以为野狐外道，弃若敝履，此则 PaperMC 任用 Adventure ，偏废 BungeeChat 也。
非独广播遭此闵凶。先 AsyncPlayerChatEvent，无过。PaperMC 见此事件掌管聊天，当用 Adventure API，故构之。加之以过时，因之以替代。AsyncChatEvent，予未见其创新之处。
是可忍，孰不可忍？过时者，记废弃之用。然 Bungee Chat 一干方法，既无疏漏，终鲜隐患，况 md_5 未废维护。虑以兼容，删除其必不可行也。强加替换，人难免乎离经之虞。不以便宜，反增烦扰。PaperMC，因 Spigot MC 之力而来，不思添砖加瓦，而冒天下之大不韪，行此废立之事！以用户之众，摈斥他 API，不仁！因人之项目而弃之，不义！不仁不义，予不知其可也！予不知其可也！
惟愿览者弃 PaperMC API 而用 SpigotMC。于 API 不似 Paper 之混乱。今日不改，更待何时？
省流：我不支持使用 Paper，但也没能说服使用 Paper 的开发者。
Paper 强行把传入 String 的方法标记过时，几乎不值得强行辩白。Adventure 由于其出现晚，能从高版本的角度设计 API，在 ChatColor 的架构上优于 Bungee Chat。
日前，一新人开发者问于开发区，诉某方法“居然被不建议使用”。开发者之间，不曾用广播之人，未之闻也。原先的方法无人不晓，今日过时，闻者悚然。欲传檄全服，或曰可遍历玩家列表，实繁。或曰“不妨试试Server.broadcastMessage”。然予翻阅者再，文档论及此方法处亦记为过时。同新手之做法无异。正所谓“听君一席话，如听一席话”。空自旷日持久。
予览其文档，见过时理由，非为安全隐患，罔论性能问题。实以 kyori Adventure API 为是，md_5 BungeeChat API 为非。用 Kyori Component 者辄推荐之，用 md_5 BaseComponent 者即指以为野狐外道，弃若敝履，此则 PaperMC 任用 Adventure ，偏废 BungeeChat 也。
非独广播遭此闵凶。先 AsyncPlayerChatEvent，无过。PaperMC 见此事件掌管聊天，当用 Adventure API，故构之。加之以过时，因之以替代。AsyncChatEvent，予未见其创新之处。
是可忍，孰不可忍？过时者，记废弃之用。然 Bungee Chat 一干方法，既无疏漏，终鲜隐患，况 md_5 未废维护。虑以兼容，删除其必不可行也。强加替换，人难免乎离经之虞。不以便宜，反增烦扰。PaperMC，因 Spigot MC 之力而来，不思添砖加瓦，而冒天下之大不韪，行此废立之事！以用户之众，摈斥他 API，不仁！因人之项目而弃之，不义！不仁不义，予不知其可也！予不知其可也！
惟愿览者弃 PaperMC API 而用 SpigotMC。于 API 不似 Paper 之混乱。今日不改，更待何时？
什么大佬，古文穿插英文，并且还逻辑如此清晰Spigot确实好用，用了2年多了【看楼主的头像，我是不是该喊一句，卢本伟牛逼】
标记为过时，实际上还是可以用
本帖最后由 克鲁鲁殿下 于 2022-3-25 10:21 编辑
我找的是Spigot的api
是我的问题
表示抱歉
（其实我也不咋用paper让大佬见笑了
（好家伙，我来谈论文言文了，没看我考试文言文考多好（悲
好家伙我改了一篇（bushi
我找的是Spigot的api
是我的问题
表示抱歉（其实我也不咋用paper
让大佬见笑了（好家伙，我来谈论文言文了，没看我考试文言文考多好（悲
好家伙我改了一篇（bushi
本帖最后由 tcejorPoiK 于 2022-3-25 11:49 编辑
个人的一些看法，不一定正确
paper API 本身就与 spigot API 有很大的不同，例如异步加载区块之类，开发使用 paper API 就已经做好了不兼容 spigot 的准备。我对于使用何种 API 的看法就两点：1、这个插件是否自用，2、是否以后有可能不再使用 paper 而换到 spigot。
为什么我不建议在 paper 服务端上使用基于 spigot API 的插件，因为很多 paper API 几行代码能解决的问题， spigot API 无法单独完成，甚至需要使用到 NMS 这类连 md_5 都非常不建议使用的方式。
虽然 Adventure API 写起来非常繁琐（包括mini message，写出来完全没旧的颜色代码直观，甚至感觉很混乱），但是其也能实现很多旧消息格式无法完成的功能，例如悬浮消息，点击执行命令等（用户可以直接写在 message.json 里，而不用开发者做任何适配），算是喜忧参半。
不太喜欢 paper 将旧消息格式的方法标注为已过时的做法，本强迫症表示用起来很不舒服。
也许 paper 强制推行 Adventure API 是为淘汰掉 Waterfall（基于 BungeeCord）做准备，他们现在推荐使用 Velocity，包括 Velocity 的开发者也已经入驻 paperMC 了。
个人的一些看法，不一定正确
paper API 本身就与 spigot API 有很大的不同，例如异步加载区块之类，开发使用 paper API 就已经做好了不兼容 spigot 的准备。我对于使用何种 API 的看法就两点：1、这个插件是否自用，2、是否以后有可能不再使用 paper 而换到 spigot。
为什么我不建议在 paper 服务端上使用基于 spigot API 的插件，因为很多 paper API 几行代码能解决的问题， spigot API 无法单独完成，甚至需要使用到 NMS 这类连 md_5 都非常不建议使用的方式。
虽然 Adventure API 写起来非常繁琐（包括mini message，写出来完全没旧的颜色代码直观，甚至感觉很混乱），但是其也能实现很多旧消息格式无法完成的功能，例如悬浮消息，点击执行命令等（用户可以直接写在 message.json 里，而不用开发者做任何适配），算是喜忧参半。
不太喜欢 paper 将旧消息格式的方法标注为已过时的做法
也许 paper 强制推行 Adventure API 是为淘汰掉 Waterfall（基于 BungeeCord）做准备，他们现在推荐使用 Velocity，包括 Velocity 的开发者也已经入驻 paperMC 了。
我高呼666我诶不知道说什么好了就是好玩
我觉得就像c++和python一样，不能说python不合格，只能说确实简便了很多
paper的服务器玩的很多但不太喜欢这个服务端
强烈反对楼主观点。
按您所述，所有的“安全的，稳定的”API就应被始终作为主力使用，而放弃使用更先进，更便捷的API？
我不知您是否有了解过 Adventure API，其设计是更贴近 Minecraft 原版的 Component 设计，且更易于操作的，BungeeChatAPI 虽然稳定，安全，但十分累赘早已饱受诟病。
开发者社群从来不会拒绝新的技术产生，也不拒绝使用更新的技术，一味的守旧只会让自己越来越固步自封。
我不知您哪来这么大的火气，整个帖子上面全部都是对 Paper 的排挤和否定，但是试问您真正使用过 PaperAPI 吗？您知道 PaperAPI 相比 SpigotAPI 提供了多大的便利吗？
我认为您是都不知道的。如此者者，足见您偏见之深。
以上
按您所述，所有的“安全的，稳定的”API就应被始终作为主力使用，而放弃使用更先进，更便捷的API？
我不知您是否有了解过 Adventure API，其设计是更贴近 Minecraft 原版的 Component 设计，且更易于操作的，BungeeChatAPI 虽然稳定，安全，但十分累赘早已饱受诟病。
开发者社群从来不会拒绝新的技术产生，也不拒绝使用更新的技术，一味的守旧只会让自己越来越固步自封。
我不知您哪来这么大的火气，整个帖子上面全部都是对 Paper 的排挤和否定，但是试问您真正使用过 PaperAPI 吗？您知道 PaperAPI 相比 SpigotAPI 提供了多大的便利吗？
我认为您是都不知道的。如此者者，足见您偏见之深。
以上
贺兰兰 发表于 2022-3-25 14:38
强烈反对楼主观点。
按您所述，所有的“安全的，稳定的”API就应被始终作为主力使用，而放弃使用更先进， ...
就整个 Paper API 而言，确实可以说有很多内容方便了开发。但是试问 broadcast 直接传入一个 String 难道不是比任何包装，无论是 Bungee 或 Adventure，都来的方便吗？说它过时，岂非减低了便捷性？累赘正是由于插件的兼容性而产生的。如果要去掉累赘，那势必就得去掉旧版本比如说 ChatColor 那样的颜色符号之类的兼容。如果真的要去掉这些旧 API，何不对类似 Material 这样的毒瘤动手？再者除了颜色之外，我看Bungee API 也未必有什么累赘的地方。把 Title、Bossbar 包装，却另外单列 sendActionBar，看起来这才是一种累赘的设计。假如 Spigot 在新版本加了某个 Paper 先前添加的 API，那才导致 API 很累赘。Spigot 没有这样的担忧。