本帖最后由 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 之混乱。今日不改，更待何时？

什么大佬，古文穿插英文，并且还逻辑如此清晰
Spigot确实好用，用了2年多了【看楼主的头像，我是不是该喊一句，卢本伟牛逼】

标记为过时，实际上还是可以用

本帖最后由 克鲁鲁殿下 于 2022-3-25 10:21 编辑

我找的是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 了。

我高呼666我诶不知道说什么好了就是好玩

我觉得就像c++和python一样，不能说python不合格，只能说确实简便了很多

paper的服务器玩的很多但不太喜欢这个服务端

强烈反对楼主观点。

按您所述，所有的“安全的，稳定的”API就应被始终作为主力使用，而放弃使用更先进，更便捷的API？

我不知您是否有了解过 Adventure API，其设计是更贴近 Minecraft 原版的 Component 设计，且更易于操作的，BungeeChatAPI 虽然稳定，安全，但十分累赘早已饱受诟病。

开发者社群从来不会拒绝新的技术产生，也不拒绝使用更新的技术，一味的守旧只会让自己越来越固步自封。

我不知您哪来这么大的火气，整个帖子上面全部都是对 Paper 的排挤和否定，但是试问您真正使用过 PaperAPI 吗？您知道 PaperAPI 相比 SpigotAPI 提供了多大的便利吗？

我认为您是都不知道的。如此者者，足见您偏见之深。

以上

就整个 Paper API 而言，确实可以说有很多内容方便了开发。但是试问 broadcast 直接传入一个 String 难道不是比任何包装，无论是 Bungee 或 Adventure，都来的方便吗？说它过时，岂非减低了便捷性？累赘正是由于插件的兼容性而产生的。如果要去掉累赘，那势必就得去掉旧版本比如说 ChatColor 那样的颜色符号之类的兼容。如果真的要去掉这些旧 API，何不对类似 Material 这样的毒瘤动手？再者除了颜色之外，我看Bungee API 也未必有什么累赘的地方。把 Title、Bossbar 包装，却另外单列 sendActionBar，看起来这才是一种累赘的设计。假如 Spigot 在新版本加了某个 Paper 先前添加的 API，那才导致 API 很累赘。Spigot 没有这样的担忧。

卧槽！！！！太牛了吧

不敢苟同。

1. 传入 String 对你只是发送一个纯文本消息的需求来说很“方便”，但是试问您有考虑过其他情况吗，比如，我想传入一个翻译键进去呢？从这方面而言，传入String这种行为难道不“过时”吗？

2. Adventure API 同时也规避使用了您所说的 ChatColor，以及他背后所代表的格式化代码；事实上，早在 Minecraft 1.13 以后客户端便不再支持格式化代码，而要求必须使用 JSON，如果仍使用前者则会被强制切断连接。

3. 您应当关注 SpigotMC Stash，那么您就应该知道 Spigot 在前些日子加入了几乎和 Paper 一模一样的 PlayerProfile API，但这并不代表您所说的什么累赘。

1.你在否定一种需求。比如拿我近期所写的飞花令为例子，由于肯定不可能拿外语玩飞花令，所以只支持繁体和简体中文。这种情况下我不需要翻译，因为可以直接繁体写一遍字符串然后直接简繁转换。拼接一下字符串就可以发送了。
2.很显然Bungee的ChatColor在高版本也可以使用。由于出现早，所以有那些低版本的遗留，如这个类混同了颜色和加粗、斜体等格式，这是存在累赘的地方。出现晚的Adventure可以高屋建瓴，把这些东西进行拆分。私以为出于兼容性考虑这是不可能改变的了，或许新的 Adventure 确实做的好。
3.Paper得留着原来的类啊，就像是这个类。Game Profile 的新 API 我倒确实是没关注过也没用过。

1. 您认为 API 设计应当是越全面，越照顾更多数人的需求好，还是照顾类似于您这种片面的需求更好呢？另外，您似乎并没有理解“翻译键”是个什么东西，对于某些需要客户端本地化文本的东西来讲，我们更应该使用翻译键提供文本，而不是自己来做 i18N。
2. 从未觉得增加 API 会导致什么累赘，你大可不用，但是对于人们来说，总会用上的。对于更加先进的 API 来说，有谁不会去尝试使用呢？

恐怕本地化键才是用的较少的情况。直接发个 String 过去才是更有可能的。第二点可能我们无法达成共识。

使用 Component 远比一个 String 所能包含的内容更丰富也更灵活
而对于 Spigot API 开发的插件 Paper也没有删除其 API
也就是说使用Spigot API便无需在意
当你使用Paper API 的时候就决定了你是面对Paper API开发的，使用更先进的API也是理所应当

至于用不到的API是累赘的说法：

标记为过时的还可以用，但是看着的确很难受！

这个新API是好事，但考虑对spigot的兼容性问题，还是暂时用BungeecordChat API (虽然高版本也没人用spigot了)

我不是开发插件的，我很喜欢用/tellraw，其实很多能用指令做到的事我都喜欢用指令，插件只需要给我一个触发指令的方式，当然如果插件本身就是用指令来实现某些功能，势必会降低版本的普适性，毕竟每个版本的指令可能不一样，不过这跟我一个不开发插件又有什么关系呢

我选择自己造轮子，这样就永远不会有我不熟悉的函数啦
哦，或者直接改idea外观就可以(bushi

乐，spigot属于第二代PluginLoader（Bukkit第一代），API应该差不多够用了w
（我行我素地继续用Forge/Fabric写服务端补丁doge

直到现在也没人讲解 Component 杂用