前往我的博客获得更好的markdown浏览体验以及更为长期的更新支持：

https://fallenbreath.me/2022/03/16/introduction-to-carpet-tis-addition/

作为一个地毯 mod 扩展，Carpet TIS Addition （也称为 TIS Carpet）自然拥有着大量的可用于操控游戏特性的规则（截止至 v1.33 版本，共含有 67 个的规则），它们可以通过指令  来使用。在默认情况下，所有的规则均为关闭状态，以保证服务端的原版性以及对性能的零额外开销

这一系列的规则大部分是用于增强创造模式游戏体验的，包括对游戏特性的控制、修改和开关等。除此之外还有不少为生存模式添加的有意思的机制、bug 修复，以及一些对游戏的优化。

下文将按照这些规则的类别，按照字母顺序，对他们进行详细的介绍。在zhao叙chao述规则简介的同时，我还会写下这些规则的设计意图、常见用途、注意事项，以及背后隐藏着的游戏机制

Carpet TIS Addition 相关链接：

- Github 仓库：https://github.com/TISUnion/Carpet-TIS-Addition

- 中文文档：https://github.com/TISUnion/Carpet-TIS-Addition/blob/master/README_CN.md

- CurseForge 页面：https://www.curseforge.com/minecraft/mc-mods/carpet-tis-addition

- Modrinth 页面：https://modrinth.com/mod/carpet-tis-addition

这一系列规则添加了为创造模式设计的新功能/新机制，能有效地提升创造模式下的游戏体验

方块可放置时无视实体碰撞检测，也就是你可以将方块放在实体内，仅对创造模式玩家有效

在设计各种包含实体的机器，遇到比如盔甲架开盒检测合成站、漏斗矿车藏方块等情况的时候，容易出现需要在实体碰撞箱范围内放置方块的情况，但原版又不允许玩家在实体碰撞箱中放方块，因此就可以借助这条规则进行绕过

允许创造模式的玩家打开被阻挡的容器，如潜影盒

在设计如打包机等机器时，经常需要查看并操控其中的潜影盒，但打包机的潜影盒往往会被一些实体方块所阻挡。借助这条规则，创造模式玩家可以无视其上方的方块，强行打开这种被阻挡的潜影盒。

除了潜影盒外，被阻挡的箱子末影箱等也可以被创造模式强制打开

开启后，发射器和投掷器使用被激活时不再消耗物品。无论投掷物品还是使用物品都如此，但是投掷器传输物品仍会消耗物品

当你需要测试基于发射器/投掷器的机器，但又不想做补货模块的话，可以用这条规则来让发射器/投掷器不消耗物品

不过由于这条规则会对所有发射器/投掷器造成影响，如果可行的话建议使用规则“漏斗不消耗物品”替代

移除 /enchant 指令中所有对目标附魔的约束

包括附魔与物品的匹配性检查、附魔间的冲突检查、附魔重复检查、附魔等级上限检查。

在使用物品放置实体时禁用相关的方块与实体的碰撞检测。受影响的物品：盔甲架、末影水晶、所有种类的船。刷怪蛋物品不在作用范围内

类似规则“方块放置忽略实体”，不过这次针对的是实体的放置

忽略在 /setblock 等指令的方块状态参数中出现的无效键/值参数。原版中这些无效的键/值会导致指令解析出错。这个规则抑制了这一出错，有助于跨版本粘贴 litematica 原理图等

例如，在 mc 1.14 中音符盒添加了铁木琴音色，在音符盒放置于铁块上时其方块状态 instrument 的值将被设置为 iron_xylophone。如果使用投影将这一方块粘贴至 mc 1.13 中，会由于该方块状态无法被解析而导致对应的 /setblock 指令出错，导致位于铁块上的音符盒无法被放置。如果启用本条规则，那么该音符盒将会使用默认的 instrument 方块状态正常地由 /setblock 指令放置

禁用流体流动造成的方块破坏，包括水和岩浆。此时流体会简单地停留在即将破坏方块时的状态

在设计包含流体的机器/建筑时，比如带有水道的机器，很容易有意无意地破坏了水道导致漏水，然后把电路装饰方块冲坏。借助这条规则，把流体破坏关掉后，就可以大胆地修改与流体相关的部件，随便漏水，完全不需要担心流体冲坏东西了

不过还是得小心水固化混凝土、岩浆点着地毯等情况，这些情况是本条规则无法阻止的

当漏斗指向羊毛方块时，漏斗将拥有无限的物品吸取以及传输速度，且无冷却时间

仅当 Carpet Mod 中的规则 hopperCounters 开启时有效

作为一个漏斗计数器，这个漏斗就别在拘束于原版一次一组的吸物品速度，也别 8gt 才工作一次了，来点无限的吸物品速度，来多少物品就吸多少物品。借此，对于需要用到漏斗计数器的时候，一个漏斗 + 一个羊毛即可处理干净所有来到的物品，不需要担心出现机器产率过高，漏斗吸不过来的情况

实际的代码实现中，作为漏斗计数器的漏斗会尝试传输 32767 次，以防止在与其他 mod 冲突时无限死循环吸物品

上方放有羊毛方块的漏斗可不消耗物品地无限输出储存的物品

谁不想要一个可以无限输出物品的漏斗呢？

令位于红石矿上的命令方块瞬间执行命令，而不是添加一个 1gt 的计划刻事件用于执行。仅影响普通命令方块

在原版中，脉冲型命令方块接收到红石信号时并非是瞬间执行所储存的命令的，而是添加一个延迟为 1gt 的计划刻事件，然后在该计划刻事件中执行命令，这会影响我们一些与微时序紧密相关的操作

该规则移除了这一延迟，让位于红石矿上方的命令方块在受激活的瞬间执行命令

除此之外，原版的命令方块有着每 gt 只能执行最多一次指令的限制。这一限制也被该规则移除了，当然只对红石矿上方的命令方块有效

微时序记录器的的总开关。微时序记录器相关介绍较长，本篇文章不进行叙述

允许玩家手持染料右击方块来将其标记为微时序监视器的目标

微时序记录器的染料记号功能的开关。微时序记录器相关介绍较长，本篇文章不进行叙述

设置指定微时序记录器记录目标的方法

labelled: 记录被羊毛块标记的事件

in_range: 记录离任意玩家 32m

all: 记录所有事件。谨慎使用

marker_only: 仅记录被染料记号标记的方块。将其与规则 microTimingDyeMarker  一起使用

指定微时序记录器该记录哪些目标。如果能确保客户端均有 carpet 的话，可以选择 marker_only，让玩家都用染料记号来标记目标

设置指定微时序记录器划分两个游戏刻的方法

world_timer: 划分于世界计时器自增时

player_action: 划分于玩家操作阶段开始前

国内外玩家微时序相关的模型在游戏刻的划分上有着不小差别：

国内玩家将世界计时器自增时刻作为游戏阶刻的划分点，优势是计划刻元件的延迟可以跟游戏刻完全对应上，缺点是跨维度分析时序/分析非主世界其他游戏阶段时序时会比较困难

国外玩家将游戏代码中完整的一次循环作为一个游戏刻的范围，优势是游戏刻能跟服务端的 tick 计数器完美匹配，面对多维度时序分析时也轻而易举，不过缺点需要对玩家操作等阶段触发的计划刻元件的延迟减少作特殊解释处理

该规则则作为一种为微时序记录器切换两种游戏刻模型的方式

当使用物品放置/召唤实体时，将实体准确地放置在玩家指针指向的坐标点。受影响的物品：刷怪蛋、盔甲架、末影水晶

可以配合  entityPlacementIgnoreCollision 一起使用，达到快速放置合成站的盔甲架的效果

当红石中继器位于红石矿上方时，红石中继器的延迟将减半。延迟将会由 2, 4, 6, 8 游戏刻变为 1, 2, 3, 4 游戏刻

需要 1gt 或者奇数 gt 的延迟，或者想要逐 gt 地调整电路延迟看看效果，但又懒得用原版电路实现，怎么办？启用这一条规则，把中继器放在红石矿上，完事！

随机化红石粉发出方块更新的顺序，有助于测试你的装置是否依赖于位置。在规则 fastRedstoneDust 启用时无效

一个简单快捷的方式，用于测试你的红石粉飞线是否具有位置依赖性

由于该规则的实现为随机打乱红石粉发出更新的顺序，与真实情况下出现的依赖位置是“随机”是有区别的。你可以视为该规则随机出更新顺序集合是真实情况更新顺序集合的超集，也就是能在该规则启用下稳定正常工作的机器一定能不会在真实情况中出现问题，但在该规则启用下可能出错的机器不一定会在真实情况中出现问题，或者在真实情况下出现问题的概率极低

为创造模式设计的，对游戏参数/行为的更改，让你更好的控制 Minecraft

设置会在方块事件成功执行后收到数据包的玩家范围。对于活塞而言，这一个数据包用于显示活塞的运动。把这个值调小以减小客户端卡顿

在服务端成功执行一次方块事件时，服务端将会把这一方块事件广播给 64m 范围内的玩家。对于活塞而言，这一广播的方块事件数据包将触发客户端为活塞添加方块事件，随即计算活塞的推拉并借助客户端的 b36 方块实体显示活塞的移动动画。本规则的用途即为修改 64m 这一常量

如果你在调试一些有着大量活塞运行导致客户端帧率很低的机器，你可以将这个值调低，降低活塞动画的范围，提升帧数

如果你想要录制机器的运行，如使用 replay mod，你可以将这个值调高，这样离玩家很远的活塞动画也不会丢失

该功能与 g4mespeed 的 Block Event Distance 设置相同。若本规则的值有修改，g4mespeed 所设值将被覆盖；否则 g4mespeed 的值将会被使用

p.s. 本规则是 Carpet TIS Addition 的第一条规则

让玩家可以对着填充有水的炼药锅放置方块。仅对 Minecraft  10^−5m/gt，即水平速度不超过约 0.063m/s

的时候，每 4gt 才运算一次物品实体的移动逻辑。这虽然能减少在地面上扎堆不动物品实体带来的运算量，但也会带来一些额外的问题：一大堆物品实体从一个平台落下时，会分成 4 批逐批落下，这有时候会对我们的实验造成影响

本规则的作用即为移除这一“着地低速物品实体每 4gt 运算一次移动”的机制，让物品实体在任何情况下都能每 gt 运算一遍移动逻辑

暂停或者禁止光照更新

若被设为抑制(suppressed)，光照更新不会被执行，这可用于模拟光照抑制器

若被设为忽略(ignored)，光照更新不会被计划，这常用于在创造模式中制造光照错误

若被设为关闭(off)，光照更新不会被计划或被执行

【警告】：若被设为抑制或关闭，新的区块将无法被加载。如果此时玩家等原因尝试加载新的区块，服务端将进入无法跳出的死循环

1.14 后，Minecraft 的光照引擎被重写，服务端的光照更新被安排至一个独立的光照线程执行。Mojang 使用了队列来进行主线程与光照线程间的通讯，因此一次光照更新想要执行，得先进入光照队列排队等待，等待光照线程将光照队列取出并执行这一更新

该规则用于控制原版的光照队列，它的四种可能取值对应着下方的行为逻辑表格

方块变化时是否会更新 POI。将其设为 false 以禁用 POI 更新

POI 的更新是方块变化流程的最后一步，用于移除旧方块的 POI 并添加新方块的 POI。这一操作是可以被更新抑制所抑制的。在创造模式中，如果构造 POI 不一致的方块依然得用到更新抑制器显然太麻烦了，于是就有了本条规则

可用于如在 1.15 方便地制作无 POI 的地狱门方块

雪片融化所需的最小亮度等级。在原版里这个值为 12，意味着雪片将在亮度等级 >= 12时于随机刻中融化

将其设为 0 以将所有位于你建筑上的烦人的雪片融化；将其设为与防止降雪的最小亮度等级 (12) 来方便地测试你的建筑是否能借助亮度来防降雪

你可以修改游戏规则 randomTickSpeed 来加速雪的融化，也可以修改地毯规则 chunkTickSpeed 来加速降雪的过程

规则简介已经描述的很清楚了 XD

结构方块在放置含水方块时，不保留已存在的流体。同时有着抑制 MC-130584 发生的副作用

如图所示

MC-130584 是一个在结构方块放置结构的时候，水会蔓延至含水方块里的 bug。它在 1.17 的快照 20w45a 中被修复。这个规则也可以作为 1.17 前对这一 bug 的补丁

覆写结构方块的范围限制。当相对位置的值大于32时客户端里结构的位置可能会错误地显示

原版结构方块怎么只有这么一点大小限制？给我改！

fabric carpet 1.4.25 中引入了功能一致的规则，因此在 MC 1.16 及以后的 Carpet TIS Addition 中该规则被移除

由于原版的结构方块数据包中使用了 byte 来储存结构的大小及偏移，因此在只使用原版协议的前提下可操作的结构方块大小最大为 127。fabric-carpet 给出的解决方法是在原版数据包末端追加使用 int 储存的结构大小及偏移，该规则也同样地移植了这一实现

将光照线程与主线程同步，这样光照线程就不会于落后主线程而失去同步。服务器将会在每个世界开始运算时等待光照线程的任务完成。你可以借此安全地 /tick warp 而不用担心潜在的光照抑制或光照不同步

在很多时候，我们宁可服务端主线程等待光照线程把光照更新执行完，也不愿让光照队列堆积导致光照抑制甚至内存溢出。本规则是一简单又有效的实现：在服务端线程开始运算一个维度时，先等待这一维度的光照线程将队列里的更新都处理完，再继续处理这一维度的服务端线程任务

这一规则还为 CarpetProfiler 添加了一个名为 Lighting synchronization 的游戏阶段，用于记录服务端等待光照线程所造成的额外 mspt。这会在 /tick health 指令中显示

修改每游戏刻中计划刻事件的执行次数上限

一个计划刻队列每 gt 只会执行最多 65536 个计划刻事件，超出这一限制的计划刻事件将被延后至下一个 gt 执行。该规则的作用即为修改这一常量，常用于方便地触发/模拟计划刻 EMP

覆盖 TNT 的默认引信时长。这也会影响被爆炸点燃的 TNT 的引信时长

有时候你想快速地点几个 TNT 测试它们的爆炸，你可以借助这一规则将 TNT 的引信改短，让它们快速爆炸

有时候你只想要一个不会爆炸的 TNT 实体来做实验，这时你也可以借助这一规则将 TNT 的引信加长，从而生成一个几乎不会爆的任你揉搓的 TNT

注意到在 TNT 实体保存至/读取自 nbt 数据时，其 Fuse 标签使用的是 short 数据类型进行储存，因此 TNT 的引信时长最大值为 32767（约 27.3 分钟），这也足够长了

阻止 TNT 被红石信号点燃。你仍可以使用爆炸等方式点燃 TNT

在使用原版指令 / WorldEdit 等工具修改移动含 TNT 的机器时，总有那么些时候会不小心误触导致其中的 TNT 被点燃。用 totallyNoBlockUpdate 规则扬掉所有更新的副作用又太大，这时你就需要本规则，让 TNT 怎么激活也不会被点燃了

禁用所有方块更新以及状态更新的执行

这条规则的功能很简单：禁止所有方块更新及状态更新的执行，常用于使用指令 / WorldEdit 等工具修改移动机器

值得注意的是，除了更新外的其他机制依然可以正常运作，如流体通过计划刻流动，比较器检测到容器容量变化而更新其状态。以及本规则的作用范围是整个服务器，盲目地开启这一规则很有可能会损坏/冻结住那些一直在运行的机器

阻止海龟蛋因实体踩踏而破坏

如规则描述所述，当你想要测试一个机器是否能正确通过海龟蛋处理僵尸猪人，但又暂时不想考虑海龟蛋被不明原因踩坏的时候，你就可以把这条规则开起来，让海龟蛋怎么踩都踩不烂

修改虚空相对世界底部的海拔高度，此处的虚空指实体会受到虚空伤害的区域

有时候你想往虚空飞一飞，飞低点得到机器底部的视角，但又恐 y=-64 虚空伤害直击创造模式玩家，这时你可以用这条规则，把虚空伤害所在的海拔高度阈值调低，这样你就可以尽情地在虚空里遨游了

注意该规则所表示的海拔高度是一个相对值，是相对世界底部 y 值的相对高度值

禁用凋灵在召唤后生命值回满时发出的世界中所有玩家都能听到的音效

凋灵生命值回满爆炸时发出的那一个声音全世界都能听到，真的吵死了，快给我关掉

修改经验球检测并追踪玩家的距离。将其调至 0 以禁用追踪

当你想要在经验球管道附近修改东西，但又不想因为自己在经验球附近而扰乱了经验球的运动，你就可以用这条规则将经验球的追踪给禁用掉。当然你也可以把经验球的追踪距离拉到很高，感受经验球漫天飞舞最终汇聚于身的体验

发射器可使用龙息瓶创造出龙息效果云

新特性，让生存玩家可以在不依赖末影龙的情况下生成龙息效果云。可与规则 renewableDragonEgg 配合使用

弱加载区块的怪物不再会被刷新掉，就像 1.15 之前版本似的。此选项仅对 1.15 至 1.16 间的版本有效

在 1.15 ~ 1.16 中，位于弱加载区块中的生物也会同位于强加载时一样，执行离所有玩家 128m 则立即消失的逻辑。这导致了玩家无法使用存放在弱加载区块中的普通怪物制作伪和平装置

改规则将生物处理立即消失的逻辑改回了 1.14 及以前的逻辑，让弱加载区块中的生物不会因为远离玩家而立即消失

史上最棒的物品仓储方块: 大木桶！两个相邻的底部相连木桶可以组成一个大木桶，大木桶的行为逻辑跟大箱子相近

箱子能拼成大箱子，储量大，但它渲染很卡；木桶渲染不卡，但只有小箱子的容量。没有两全其美的储存容器真是令人纠结，不过有了这条规则后，就可以说：我全都要！

底座相连的木桶将组成一个大木桶，位于坐标轴负方向的木桶作为大木桶的上半部分，位于坐标轴正方向的木桶作为大木桶的下半部分

禁用老式的移动点亮的充能或激活铁轨的刷铁轨机

这种老式的刷铁轨机只对充能铁轨 & 激活铁轨有效，效果如下

修复方式：在充能铁轨 & 激活铁轨更新自身状态前先确保这格铁轨依然存在

让龙蛋变得可再生：当龙蛋处于龙息效果云内时，龙蛋有一定概率吸收龙息并“召唤”出一个新的龙蛋

可与选项 dispenserFireDragonBreath 联动

沐浴在龙息中的龙蛋吸收了足够的能量后，召唤出了一个新的龙蛋

实现的具体逻辑：

在随机刻选中龙蛋方块后，龙蛋有 1 / 64 的几率尝试再生。这一否决率能保证龙蛋虽然可再生，但仍然是一种较为稀有的物资

龙蛋会找到与其所在位置 1 立方米范围相交的龙息效果云。若没找到，终止再生流程；否则随机挑选一个效果云

龙蛋会选择附近的一个随机位置，尝试生成龙蛋方块。选择位置的逻辑跟龙蛋被点击后随机传输的逻辑一致，不过仅有一次尝试机会。如果被选中的位置是空气的话，则龙蛋生成成功，龙息效果云的半径变为原 1 / 5

被高压爬行者杀死的末影龙将会掉落一个龙首

闪电苦力怕的斩首效果怎么能让末影龙逃过一劫？不过真要在生存中实现的话恐怕会有不小难度

当幻翼被潜影贝杀死时有给定概率掉落鞘翅。设置为 0 以禁用

需要潜影贝：玩家无法跳 Minecraft 的科技树，必须前往末地城才能拿到鞘翅涉及幻翼：既然幻翼膜能拿来修鞘翅，那幻翼膜一定是鞘翅的原材料吧

禁用使用末地门的刷沙机以及刷重力方块机。这里的重力方块包括沙子、铁砧、龙蛋等。在开启后刷沙机的沙子将会仅被传送至另一个纬度

末地门刷沙机的原理很简单：Mojang 在执行重力方块实体落地转换为方块的逻辑前，忘了判断这个重力方块是否仍然存在与这个世界里，结果就是只要重力方块在碰到末地门的同时落地，就能既前往另一纬度又可以转换为方块

修复也很简单，把缺失的判断加上就行了

禁用TNT、地毯以及部分铁轨的复制机。基于依附性方块的复制机会无法复制，基于红石原件更新的复制机会无法保留被复制的方块

Dupe bad dig good

这一类的方块复制均发生于活塞将所推动的方块一次转换为 b36 的过程中，根据更新源的不同可以分为两种复制机：

基于依附性方块掉落而发出更新的，如死珊瑚更新源。原理为 b36 方块的放置会发出状态更新，导致还未被置为 b36 的依附性方块发现自己附着于 b36 上，或者依附在空气上，从而掉落，并发出更新

基于方块被移除时发出更新的，如亮起侦测器更新源。原理为一些红石原件（侦测器、中继器等）在亮起时被移除的时候，会发出方块更新，用于告知附近方块你的信号源没了

为了修复这两种复制机，同时保证不破坏其他的逻辑时序而保证原版性，我们可以这样做：

使被活塞所推动的方块间接地转换为 b36：

先不发出任何更新地，将活塞所推动方块的原位置替换为空气方块

再让原版的逻辑将这些空气方块转换为 b36

这保证了生成 b36 的时候不会有残留的方块作妖

在将方块设置为空气之前才把世界里的方块状态储存进活塞推动列表中，这样就算基于方块被移除时发出更新的复制机刷出了 TNT，这 TNT 也是真的点着掉了下来，不再会被存入活塞推动列表里变成 b36

由玩家引发的爆炸破坏并掉落物品时会应用玩家手上的工具，因此你可以点燃TNT以采集需要特定工具或者附魔的方块，只要你在爆炸时拿着正确的工具。比如，你可以拿着精准采集镐子来采集冰，或者拿着剪刀来采集草

此规则同样适用于玩家以外的生物。技术上来讲，此规则将来源生物主手上的物品应用在了爆炸里战利品表的创建中

精准采集 TNT，从梦想变为现实——既然都有 TNT 掠夺了，那么为啥不来一个TNT 精准呢

通过仅检测沿轴移动方向的方块碰撞来优化高速实体的移动

受 carpetmod112 的规则 fastMovingEntityOptimization 启发

同规则 optimizedTNT 一起使用可大幅度提升炮的性能表现

在实体移动的过程中，原版游戏会获取实体速度矢量构成的长方体中所有能阻挡其移动的碰撞箱

如上图所示，TNT 从右下移动至左上，游戏会获取图中白色染色玻璃范围的所有碰撞箱

由于实体实际上是沿轴分步移动的，这个长方体中中并非所有数据都是我们需要的，只有实体沿轴移动路径上的碰撞箱有可能阻挡实体移动（上图红色玻璃），因此我们可以仅获得这条路径上的碰撞箱，而非获取整个长方体中的碰撞箱

在与 TNT 炮相关的机器中，TNT 的速度往往会被加速到极大值，又因为长方体的体积随实体速度大小立方级地增长，TNT 速度提上去之后带来的卡顿会急剧升高。在使用本规则进行优化后，所需要扫描的碰撞箱范围体积变为与实体速度大小线性增长，能非常有效地缓解这部分的卡顿

优化实体与硬碰撞箱实体的碰撞

它使用了一个额外的独立的列表在区块中储存带有硬碰撞箱的实体，包括船和潜影贝。它能在实体移动并搜索路径上的带有硬碰撞箱的实体时减少大量无用的运算，因为世界里船和潜影贝的数量总是少数

在加载区块前开启它以使其工作，在地狱门刷怪塔中有~20%的性能提升。

与添加了新实体的 mod 可能不兼容

实体移动时，需要搜寻其移动路径上所有能阻挡其移动的碰撞箱对象，这包括方块以及带有硬碰撞箱的实体（对非矿车的实体而言，为船和潜影贝），然后计算它们对实体移动的阻挡效果

搜寻带有硬碰撞箱的实体的实现是，遍历一遍范围内所有区段中的所有实体，然后将其中具有硬碰撞箱的实体提取出来。如果范围内的实体数量非常多，这部分遍历将会非常耗时，即便这个范围内几乎没有硬碰撞箱的实体。这种情况常出现于双维度刷怪塔的怪物处理维度端，其中有着大量刷出的怪物，但却几乎没有船跟潜影贝

该优化使用了一个独立的列表来储存含硬碰撞箱的实体，这样在需要于区段中搜索硬碰撞箱实体时就不用遍历整个包含所有实体的列表了，可以有效地减少这部分遍历的耗时

Lithium 模组在 v0.5.5 后也加入了类似的优化，位于 chunk.entity_class_groups 中

用带有更高优先级的 Mixin 注入来实现 carpet 规则 ，因此规则 optimizedTNT 可以覆盖 lithium 的爆炸优化

当然，它需要规则 optimizedTNT 开启才能工作

fabric carpet 的爆炸优化有着实体接触率射线计算结果缓存的功能，这是 lithium 的爆炸优化所不具有的，

在默认情况下，lithium 的爆炸优化是会覆盖掉 fabric carpet 的爆炸优化的，两者无法共存。当你想使用 fabric carpet 的爆炸优化，而非 lithium 的爆炸优化的时候，即可启用本规则

Lithium 模组在 v0.6.2 后修改了其爆炸优化的实现，据其称这些修改能提升 lithium 的爆炸优化与其他修改爆炸的模组的兼容性。本规则与 lithium v0.6.2+ 的组合效果仍有待测试

禁用玩家身上的刷屏检测，包括：聊天信息发送冷却、创造模式扔物品冷却

在原版游戏中，若非 OP 玩家发消息 / 指令发的过快，会被因刷屏而踢出游戏；创造模式中从创造模式物品栏扔物品是有速度上限的，超过上限了只能以一秒一个物品的速度扔出物品

这些限制对于服务器成员遵纪守法的服务器而已显然只能提供烦人的作用，不如用这条规则将它扬了吧

启用 /lifetime 命令用于追踪生物存活时间等信息。可助于调试刷怪塔等

/lifetime 存活时间追踪器指令的开关及其权限控制

启用 /manipulate 命令用于控制世界

/manipulate 指令的开关及其权限控制

启用 /raid 命令用于列出或追踪袭击信息

/raid 指令的开关及其权限控制

启用 /refresh 命令让你的客户端与服务端保持同步

/refresh 指令的开关及其权限控制

为 /player 指令召唤出来的假人名称添加指定前缀

将其设置为 #none 以阻止添加前缀

这可阻止玩家召唤奇怪名字的假人，还能让玩家列表变得更整洁

让所有的假人均统一带有 bot_ 什么的前缀，是非常令人舒适且便于管理的

如果输入的假人的名字已含给定前缀，召唤出来的假人名字则不会重复添加前缀

为 /player 指令召唤出来的假人名称添加指定后缀

将其设置为 #none 以阻止添加后缀

类似 fakePlayerNamePrefix，不过本条规则添加的是后缀

覆写 Carpet Mod HUD 记录器的更新间隔，单位为 gametick

在 fabric carpet 的框架中，位于 tab 栏玩家列表下方的 HUD 记录器的更新间隔是一个定值，20gt 定值。如果我们想要更高频率地刷新 HUD 记录器的信息刷，就可以使用本规则来修改这个间隔

存活时间追踪器对不占怪物容量的生物的策略

true: 不追踪不占用怪物容量的生物，并与生物不影响怪物容量的时刻将其标记为已移除，如当它们捡起物品时。便于设计刷怪塔

false: 追踪所有可追踪的生物，在生物确实被删除时将其标记为已移除。便于设计袭击农场或非刷怪塔的机器

存活时间追踪器所使用的的一个参数

光照队列记录器的采样时长，单位为游戏刻。影响记录器中显示的，除队列大小外的所有数据

光照队列记录器（lightQueue）所使用的的一个参数

在 carpet 怪物容量显示中忽略杂项 (misc) 这一生物类型

因为它既占空间还没用：杂项生物类型不参与刷怪循环，在统计怪物容量时也被游戏忽略

影响 mobcaps 记录器以及 /spawn mobcaps 指令

占空间还没用的数据，当然是选择删掉啦

禁用部分指令以避免op玩家意外地作弊

影响的指令列表：/gamemode, /tp, /teleport, /give, /setblock, /summon

在拥有 OP 权限的情况下有时候会不小心误触到一些作弊的快捷键，包括：

原版的 F3 + N、F3 +F4 切换游戏模式（/gamemode）

小地图模组里的选点传送（/tp、/teleport）

JEI 等物品列表显示模组中的物品给予（/give）

投影模组粘贴原理图的方块放置与实体召唤（/setblock、/summon）

虽说是无意触发的，但总会烦人，不如直接禁掉这些指令，不准这些指令给任何玩家执行。这也正是本条规则的功能

当然如果你真的需要使用这些被禁用指令的话，把本条规则关闭即可

在服务器重启后依然记忆着玩家订阅的记录器及记录器选项

仅在玩家首次登录时应用 carpet 的 defaultLoggers 规则

记录器订阅储存于 config/carpettisaddition/logger_subscriptions.json 中

虽说 fabric carpet 有着一个叫 defaultLoggers 的规则，让玩家上线后可以自动订阅一些记录器，但单一一个规则显然不能满足每名玩家的个性化自定义需求

换个角度想想，只要我们记忆着玩家所订阅的记录器，以及记录器的选项，并在玩家下次登录时自动回复订阅，不仅能避免玩家每次上线时都得重新订阅的繁琐，还能满足每名玩家的个性化订阅需求

启用可视化投掷物记录器。试试 /log projectiles visualize 吧

为投掷物每游戏刻所在位置，以及投掷物的撞击点，召唤一个固定的不与红石交互的雪球，指示投掷物的运动轨迹