mc秒杀模组测试规则v1（Java版）

注意：本规则为自愿遵守，并非是一种对所有人的强制要求

可以在一次测试中自行选择遵守或不遵守本规则，但要求在同一次测试中，测试双方必须同时遵守本规则，或者同时不遵守本规则。

---------------------------------------------------------------------------------------------------------------------------

在开始讨论规则之前，先对几个概念作出定义：

针对：是在所有规则中被禁止的行为。它意味着对某一个具体的测试方唯一的特征性部分进行特别的处理（若是测试方"针对"mc，或"针对"测试方自己，则除外），或者说，一方的源代码中涉及了另一方唯一的特征性部分，如"chaoswither.happymode = false;" "if (item.getClass().getName().startsWith("net.mcreator.supersword.")) {...}"，"if (mc.entityRenderer instanceof MxEntityRenderer) {...}"等都直接涉及其他具体的mod，是明显的针对，不应出现。

纯渲染：仅有单纯的直接渲染，而无实际事物支持导致渲染出现可能的破绽。一般用于指渲染的、不能点重生的死亡gui，/say @e无法探测的渲染的实体，死亡时血条不抖动的渲染的hud(hud指GuiIngame/IngameGui渲染出的事物，下同)等。

注意：渲染的不一定都是纯渲染的，只需要与其对应的真实事物的表现完全一致而毫无破绽，就可以被认为是"真实"的，而非纯渲染的。特别地，在游戏画面彻底静止或崩坏（包括暂时的和永久的）且没有未响应的情况下，一律归入纯渲染的范畴（包括防御）。

死亡gui：广义地，是形如原版死亡gui一样的gui。允许这些gui在背景颜色、字体颜色、显示的文本上与原版不同。可以添加额外特效，但不能挡完死亡gui的某一特征。更确切地，死亡gui是：满足"有填满mc窗口的渐变色或纯色的矩形作为背景"、"在正确位置出现"你死了"等被放大为正确大小的标题"、"在正确位置出现正常大小的死亡信息"、"在正确位置出现带有'重生'等正常大小文本的正常大小的按钮"、"在正确位置出现带有'标题画面'等正常大小文本的正常大小的按钮"、（此处"正确""正常"等词以mc原版正常死亡时的死亡gui为准）这些所有条件的、在mc窗口中出现的一种现象。若当前规则无特别规定，不强制要求死亡gui满足其他的条件。

mc窗口：需要涉及此概念的测试必须在Windows 10系统上进行，并且测试中不得使用切换全屏（f11）。指启动mc后创建的最初始窗口。不得出现任何窗口闪烁现象，否则不被认为是mc窗口。

实体：广义地，指原版继承自Entity类的对象，以及一切形似某一生物的事物。

生物：为行文方便，此处泛指非玩家实体和不是由人操控的玩家实体。

/say @e不显示（或仍然显示）该生物存在：/say @e执行后，在玩家聊天栏中输出的世界中的所有实体里，或者在日志中输出的世界中的所有实体里，有（或无）该生物存在的迹象。要求/say @e必须输出成功。不允许测试方在/say @e的结果已定后，拦截/say @e的输出。不允许测试方用自己的/say @e覆盖原版的/say @e。

---------------------------------------------------------------------------------------------------------------------------

注意事项：

1. 测试双方（对，只能有两方）在同一次测试中，必须同意同一套对应的规则，否则测试结果没有意义，不可以根据测试现象得出任何结论。

2. 实践是检验真理的唯一标准，没有测试之前不可擅自下结论。

3. 最好不要对理论性原理只说不做，若没有测试结果支持，则理论是待定的而非成立的。

4. 若无特别声明，对于本文涉及的"血量"之类的概念，都以"在正确位置显示的心式血条"之类的mc原生的显示机制为准。

5. 规则间并不具有可逆关联性。比如，在同一次测试中，不满足其玩家死亡标准并不能说防住了，必须满足其玩家防住标准才能得出防住了的测试结果。如果既不满足其玩家死亡标准，也不满足其玩家防住标准，则测试结果没有意义，不可以根据测试现象得出任何结论。生物死亡标准和生物防住标准同理。碰到这种情况，可以换一种测试类型，或进行改进以满足当前规则的所有条件。

6. 同一规则中具有同时满足性。对于同一条规则（如"玩家死亡标准"），若无特别说明，则必须满足其中规定的所有条件，才算通过规则。

7. 不要歪曲本规则含义，不要断章取义。建议理解好关键词，不能确定规则本意的时候，可以问我规则的本意。

8. 不得出现剪辑、p图、修改视频等伪造测试的行为，否则测试结果没有意义，不可以根据测试现象得出任何结论。

9. 在规则没有特别声明时，若防御使得攻击的全部成分在防御的那方都没有执行，则测试结果没有意义，不可以根据测试现象得出任何结论。若在攻击前防御的部分（或全部）没有执行，则测试结果没有意义，不可以根据测试现象得出任何结论。（本条不强制遵守全部，若不遵守的部分则需在自己的测试规则中声明）

10. 所有测试必须在未经修改的64位Windows 10（或更高版本）系统上的未经修改的、没有设置会影响测试的参数的HMCL/PCL2启动器上进行，Java环境要求：1.7.10~1.16.5使用未经修改的jdk8/jre8，1.18.2及以上使用未经修改的jdk17/jre17。一般地，在所有测试中，不得在启动器中利用指定启动参数去夺取最高优先级。不得手动修改LaunchWrapper/ModLauncher中的任何文件，不得手动修改minecraft jar中的MANIFEST.MF文件。（本条不强制遵守全部，若不遵守的部分则需在自己的测试规则中声明）

11. 在测试中，只允许测试者启动防御、启动攻击、生成生物，不允许进行其他任何操作，不得使用除测试双方外的其他mod或程序（mc自身除外），且测试者必须保证其他mod或程序不干涉测试。

12. 对于外部程序测试方，不得在mc启动前启动。

13. 凡是作用超出mc窗口的（要求测试时窗口不得一直处于全屏状态），测试结果一律没有意义，不可以根据测试现象得出任何结论。

14. 对于外部程序测试方，或者对于带有依赖某种特定操作系统的部分的测试方，要求测试必须在其对应的操作系统上进行。

---------------------------------------------------------------------------------------------------------------------------

接下来就是一些常见的测试类型与对应的规则。

一、常规测试：相对常用的测试类型。

玩家死亡标准：1. 玩家血量显示为0（即每一颗心都为纯黑色，下同），且血条随时间产生如mc原版一样的死亡式抖动；

2. 显示死亡gui（允许因为防御的作用而只被显示部分的）（不允许闪烁），且死亡gui不能是纯渲染的；

3. 键盘输入和鼠标滚轮在mc中失效，鼠标点击只允许响应在死亡gui的按钮上（如果按钮能被点击），鼠标移动不能再让玩家视角转动；

4. 光标弹出mc窗口，变得可见（允许光标处于闪烁状态）；

5. 在第三人称中，玩家自身的实体消失（不得用渲染贴图文件达成）。

玩家防住标准：1. 玩家血量显示为满血（即每一颗心都为红色，下同），血条不产生死亡式抖动；

2. 没有死亡gui显示出来（只显示出部分死亡gui也算显示出来）（不允许闪烁）；

3. 光标仍然在mc窗口中，不可见（允许光标处于闪烁状态）；

4. 在第三人称中，玩家自身的实体仍然可见（不得用渲染贴图文件达成）。

生物死亡标准：玩家周围，该生物消失，且/say @e不显示该生物存在。要求世界渲染不能静止。

生物防住标准：玩家仍能看见该生物，或/say @e仍然显示该生物存在。要求世界渲染不能静止。

二、严判测试：标准较严格的测试，测试结果更接近真实。

玩家死亡标准：1. 玩家血量显示为0，且血条随时间产生如mc原版一样的抖动。若存在mod自己的hud，要求在血量渲染时，输出的客户端玩家实体.getHealth()小于等于0.0f，服务端世界刻后，输出的被攻击的服务端玩家实体.getHealth()小于等于0.0f；

2. 显示死亡gui（允许因为防御的作用而只被显示部分的）（不允许闪烁），且死亡gui不能是纯渲染的。若死亡gui存在渲染行为，要求在死亡gui绘制时，输出的mc.currentScreen(mc.screen)为死亡gui（mc为Minecraft类的对象，下同），

3. 要求死亡gui类必须继承mc原版死亡界面GuiGameOver(1.13以上版本为DeathScreen)，重生按钮可被点击且能正常重生；

4. 键盘输入和鼠标滚轮在mc中失效，鼠标点击只允许响应在死亡gui的按钮上，鼠标移动不能再让玩家视角转动；

5. 光标弹出mc窗口，变得可见（不允许光标处于闪烁状态）且能自由移动；

6. 在自己的第三人称以及其他玩家视角中，被攻击的玩家的实体消失（不得用渲染贴图文件达成）。

7.玩家视角发生像mc原版玩家正常死亡时一样的倾斜（允许视角颤抖）。

玩家防住标准：1. 玩家血量显示为满血，血条不产生死亡式抖动。若存在mod自己的hud，要求在血量渲染时，输出的客户端玩家实体.getHealth()大于等于20.0f，服务端世界刻后，输出的被攻击的服务端玩家实体.getHealth()大于等于20.0f；

2. 没有死亡gui显示出来（只显示出部分死亡gui也算显示出来）（不允许闪烁），若显示有死亡gui但其存在渲染行为，则如果在死亡gui绘制时，输出的mc.currentScreen(mc.screen)不为死亡gui，就记为没有死亡gui显示出来；

3. 光标仍然在mc窗口中，不可见（不允许光标处于闪烁状态）；

4. 键盘输入、鼠标滚轮、鼠标点击、鼠标移动仍然在mc中正常起效；

5. 在自己的第三人称以及其他玩家视角中，被攻击的玩家的实体仍然可见（不得用渲染贴图文件达成），且/say @e仍然显示被攻击玩家存在。

生物死亡标准：1. 玩家周围，该生物彻底消失，不再重生，且/say @e不显示该生物存在（不允许使用tp达成），测试方不得对/say @e的执行过程有任何干涉；

2. 对于可以测试碰撞箱的生物，要求玩家不再被该生物原应有的碰撞箱所排斥，玩家可以在生物原应有的碰撞箱的位置以正常方式放置方块；

3. 要求世界渲染不能静止；

4. 由于生物出现而带来的一切异象必须全部消失。

生物防住标准：1. 玩家仍能看见该生物，且/say @e仍然可能显示该生物存在，测试方不得对/say @e的执行过程有任何干涉； 

2. 对于可以测试碰撞箱的生物，要求玩家会被该生物应有的碰撞箱所排斥，玩家不能够在生物应有的碰撞箱的位置以正常方式放置方块；

3. 生物必须包含且在攻击后仍包含"继承自Entity类的对象"这一部分；

4. 要求世界渲染不能静止。

三、渲染测试：标准较为宽松，用于匹配纯渲染的要求。

玩家死亡标准：显示死亡gui（不允许因为防御的作用而只被显示部分的）（不允许闪烁）。

玩家防住标准：没有死亡gui显示出来（只显示出部分死亡gui算没有显示出来）（不允许闪烁）。

生物死亡标准：玩家无法看见该生物，碰撞箱不计。

生物防住标准：玩家可以看见该生物，碰撞箱不计。

4. 字节码测试：标准接近病毒打架的测试（？

所有标准与严判测试相同。但是允许不遵循注意事项9。

---------------------------------------------------------------------------------------------------------------------------

以上给出了几个测试定义示例，当双方有其他测试目的时，可以据此协商自己的测试规则，规则的表述要力求严谨，且至少有玩家死亡标准和玩家防住标准（或者有生物死亡标准和生物防住标准），并且不能违反上述的注意事项（除非注意事项不强制遵守）。

本规则以后还会完善，欢迎大家在评论区集思广益

最后祝测试愉快！