Carpet TIS Addition 介绍：规则

发表于 更新于 分类于 阅读次数： 本文字数： 22k 阅读时长 ≈ 40 分钟

索引页：Carpet TIS Addition 介绍：索引

Carpet TIS Addition 介绍：规则

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

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

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

Carpet TIS Addition 相关链接：

创造模式用新增机制

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

方块放置忽略实体 (blockPlacementIgnoreEntity)

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

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

blockPlacementIgnoreEntity

创造玩家强制打开容器 (creativeOpenContainerForcibly)

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

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

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

creativeOpenContainerForcibly

发射器不消耗物品 (dispenserNoItemCost)

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

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

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

enchant指令约束移除 (enchantCommandNoRestriction)

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

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

实体放置无视碰撞 (entityPlacementIgnoreCollision)

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

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

方块状态解析忽略失败 (failSoftBlockStateParsing)

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

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

failSoftBlockStateParsing

fill指令模式增强 (fillCommandModeEnhance)

增加 /fill 指令中各种模式的功能：增加 softreplace 模式: 尽可能地保留原方块的方块状态，可用于替换楼梯/半砖的材质等

指令例子：

1
/fill ~ ~ ~ ~10 ~10 ~10 minecraft:stone_brick_stairs softreplace minecraft:oak_stairs

这个指令会将范围内的所有橡木楼梯替换成石砖楼梯，并保留楼梯的方块状态

fillCommandModeEnhance

技术上来讲，该功能并不关心新旧方块的种类是什么，它只管确保那些新旧方块均拥有的方块状态，在 /fill 前后保持不变。 举个例子，在侦测器 / 活塞 / 末地烛三者相互 softreplace 时，它们的“朝向”（facing）方块状态将会保持不变

禁用流体破坏 (fluidDestructionDisabled)

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

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

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

fluidDestructionDisabled

漏斗计数器无限速度 (hopperCountersUnlimitedSpeed)

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

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

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

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

漏斗不消耗物品 (hopperNoItemCost)

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

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

hopperNoItemCost

瞬时命令方块 (instantCommandBlock)

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

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

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

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

微时序 (microTiming)

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

微时序染料记号 (microTimingDyeMarker)

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

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

微时序目标 (microTimingTarget)

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

  • labelled: 记录被羊毛块标记的事件
  • in_range: 记录离任意玩家 32m
  • all: 记录所有事件。谨慎使用
  • marker_only: 仅记录被染料记号标记的方块。将其与规则 microTimingDyeMarker 一起使用

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

微时序游戏刻划分 (microTimingTickDivision)

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

  • world_timer: 划分于世界计时器自增时
  • player_action: 划分于玩家操作阶段开始前

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

  • 国内玩家将世界计时器自增时刻作为游戏刻的划分点，优势是计划刻元件的延迟可以跟游戏刻完全对应上，缺点是跨维度分析时序/分析非主世界其他游戏阶段时序时会比较困难
  • 国外玩家将游戏代码中完整的一次循环作为一个游戏刻的范围，优势是游戏刻能跟服务端的 tick 计数器完美匹配，面对多维度时序分析时也轻而易举，不过缺点需要对玩家操作等阶段触发的计划刻元件的延迟减少作特殊解释处理

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

精准实体放置 (preciseEntityPlacement)

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

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

preciseEntityPlacement

中继器延迟折半 (repeaterHalfDelay)

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

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

红石粉随机更新顺序 (redstoneDustRandomUpdateOrder)

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

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

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

redstoneDustRandomUpdateOrder

同步服务端mspt指标数据 (syncServerMsptMetricsData)

向客户端同步服务端的 mspt 指标数据，借此，玩家可使用 F3 + ALT 在调试界面中看到这一服务端的指标。需要在客户端中安装 Carpet TIS Addition 模组

单人游戏的 F3 调试界面中，右下角的那个显示 mspt 的图表可是个好东西。可惜在原版里，多人游戏中用不了这个功能

这条规则的功能即为让调试界面的 mspt 显示功能在多人游戏中也能用，也即让服务端把它的 mspt 数据同步给客户端，进而在客户端显示相关数据

由于需要进行服务端与客户端之间的网络通讯，本规则依赖规则 tiscmNetworkProtocol

syncServerMsptMetricsData

TISCM网络协议 (tiscmNetworkProtocol)

TISCM 网络协议的开关

作为一个总开关，这条规则可以一键让所有用了 TISCM 网络协议的规则失效，让 MC 的网络层面上回归原版表现

当然，这条规则默认值是 false，因此你需要把它设置为 true 来使得用了 TISCM 网络协议的规则生效

可以使用指令 /carpet list TISCM_protocol 来列出所有使用了 TISCM 网络协议的规则

创造模式用游戏修改

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

方块事件广播范围 (blockEventPacketRange)

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

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

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

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

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

blockEventPacketRange

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

炼药锅方块类物品交互修复 (cauldronBlockItemInteractFix)

让玩家可以对着填充有水的炼药锅放置方块。仅对 Minecraft <= 1.16.x 有效。这个烦人的机制已经在 1.17+ 中被修复了

麻将的奇怪脑回路在为了处理有水炼药锅为潜影盒去色的逻辑时，直接影响了非潜影盒的方块类物品的放置，导致玩家需要按住 shift 才可在炼药锅旁放方块。这当然不能忍，用这条规则给我修！

区块更新数据包阈值 (chunkUpdatePacketThreshold)

如果方块变化的数量大于这个阈值，则游戏将仅发送区块更新数据包而非若干个方块变更数据包。增加该数值或许可以减小网络带宽用量，并在子区段同时存在不少方块实体与方块变化时提升客户端的帧数

将其设为非常高以模拟1.16+的表现，也就是不存在区块更新数据包，仅有多个方块变更数据包。该规则仅于1.16前的版本有效

大型机器运行时客户端的卡顿源之一，为区块重建，而区块重建是因由服务端发送的区块数据包（yarn 名 ChunkDataS2CPacket）引起的

在区块刻阶段前后（是前是后根据游戏版本决定，在此不重要），服务端会将每个区块中这一 gt 内发生的方块变化同步至客户端。 在 1.16 前，当一个区块中发生的方块变化数量超过 64 时，服务端将把整个区块的数据完整地同步给玩家，这会导致客户端重建区块， 重新增删内部的方块实体，导致了较高的客户端卡顿，以及较大的网络负载。不过完整的区块数据包也有一个好处，它可以去除客户端在这个区块中出现的幽灵方块

这一规则的用途即为调整 64 这一常量，毕竟 1gt 发生至少 64 处方块更新在大型机器中实在是太常见了。 将其调高，可以避免服务端发送大量区块数据包，提升客户端帧数，减少网络带宽占用，但得小心幽灵方块

区块刻速度 (chunkTickSpeed)

修改每游戏刻每区块的区块刻运算的频率。默认值为 1。将其设为 0 以禁用区块刻。受影响的游戏阶段：雷电、结冰与积雪、随机刻

在值为 n 时，每游戏刻每区块，气候相关的阶段会发生 n 次，而随机刻会在每区段中发生 n * randomTickSpeed 次

一个区块刻阶段包含着以下多种游戏阶段：雷电&骷髅马的生成、雨雪的降落与水源结冰，以及随机抽取方块执行随机刻。 对于其中的随机刻阶段，我们可以简单地使用 /gamerule randomTickSpeed 来控制其运行速度，或者阻止随机刻的执行， 不过对于雷电冰雪这一类气候相关的运行逻辑，并没有对应的游戏规则

本规则即为一个类似 /gamerule randomTickSpeed 的游戏规则，可以将其设为一个很大的数值来加速气候逻辑的执行，让你的刷冰机快速结满冰， 也可以将其设为 0 来阻止游戏落雷降雪结冰。由于它的作用范围是完整的区块刻阶段，且随机刻阶段包含于区块刻阶段中， 因此要注意到该规则数值的变化是会同时影响随机刻的作用速度的。你可以将随机刻调为 0 以防止随机刻阶段占用了过高的 mspt

chunkTickSpeed

创造玩家地狱放水 (creativeNetherWaterPlacement)

允许创造模式的玩家在地狱通过水桶放出水。技术上来讲，本条规则对所有 ultrawarm 的维度都生效

都已经是创造模式了，玩家当然是想干什么就干什么，想划水就放水

creativeNetherWaterPlacement

创造玩家无物品冷却 (creativeNoItemCooldown)

取消创造模式玩家的任何物品使用冷却，例如使用末影珍珠的 20gt 冷却

都已经是创造模式了，麻将为何还要用物品使用冷却逻辑约束玩家

creativeNoItemCooldown

实体速度丢失 (entityMomentumLoss)

将其设为 false 以关闭从磁盘载入时实体超过10m/gt部分的沿轴速度的丢失

对于实体而言，在从 nbt 读取读取到的速度矢量中，对于每一坐标轴上的速度分量，如果它的绝对值大于 10 （单位：m/gt）的话，那就将该速度分量置为 0

从 nbt 读取数据这一操作常见于实体通过传送门跨维度时，以及加载区块读取储存着的实体数据时

对于珍珠炮而言，是很容易出现发射出去的珍珠存在大于 10m/gt 的沿轴速度分量的。当这一种高速珍珠所在区块被卸载的时候，若重新加载此区块， 该珍珠对应的沿轴速度分量将会置零，导致我们不能直观地看到珍珠的运动轨迹。这时候我们就可以通过本规则，将这一机制进行暂时性的抑制处理

实体同步距离 (entityTrackerDistance)

服务器同步实体信息至客户端的最大水平切比雪夫距离（单位: 区块）。基本上这就是服务端的“实体渲染视距”，不过这个距离依旧会被服务端视距所约束

将其设为一个不小于服务端视距的数值，就能令服务端将玩家视距内的所有实体都同步至客户端；将其设为一个非正值以使用原版逻辑

需要重新加载区块以将新的规则数值应用到实体上

服务器中的每个实体被载入游戏时，服务器都会为其分配一个实体追踪器（EntityTracker），用于同步这一实体的数据给玩家。 根据实体类型的不同，实体追踪器会有着不同的同步距离上限以及不同的同步频率

在 1.15.2 中，实体追踪器的默认同步距离如下所示：

实体种类 同步距离（单位：区块）
玩家 32
末影水晶 16
末影龙、TNT、落沙、物品展示框、栓绳结、画、盔甲架、经验球、滞留药水效果云、唤魔者尖牙 10
鱼钩、箭、光灵箭、三叉戟、各种火球、凋灵头颅、所有投掷物（雪球、羊驼口水、末影珍珠、鸡蛋、喷溅药水、经验瓶）、烟花火箭、物品 4
其他 5

客户端仅能显示同步范围内的实体并接受它们的数据，超出同步范围实体将会从客户端中移出，因此实体同步间隔可看做服务端的实体渲染距离，一个根据实体类型而变的实体渲染距离

要注意实体同步距离的实际值会与服务端的视距取最小值，这保证了实体视距总是不会超过服务端的视距

当我们想要让客户端能尽可能地显示出极远处的实体时，如使用 replay mod 摄像时，可以修改本规则，拉高所有实体的实体视距。 你可以直接将本规则设置为一个足够大的值（如 64），以此让实体视距等同于服务端视距

实体同步间隔 (entityTrackerInterval)

服务器同步实体信息至客户端的时间间隔（单位: gt）。如果设为一个较小的数值，如 1，服务器将每 1gt 都同步实体信息至客户端，这能减小客户端发生实体不同步现象的概率

将其设为一个非正值以使用原版逻辑

需要重新加载区块以将新的规则数值应用到实体上

实体追踪器的相关信息见 entityTrackerDistance 的介绍

在 1.15.2 中，实体追踪器的默认同步周期如下所示：

实体种类 同步周期（单位：游戏刻）
玩家、唤魔者尖牙 2
末影之眼 4
鱼钩 5
各种火球、凋灵头颅、所有投掷物（雪球、羊驼口水、末影珍珠、鸡蛋、喷溅药水、经验瓶）、烟花火箭、TNT 10
箭、光灵箭、三叉戟、物品、落沙、经验球 20
物品展示框、栓绳结、画、滞留药水效果云、末影水晶 Integer.MAX_VALUE，可视作无穷大
其他 3

除非一个实体发生了速度的突变，或者一些重要的数据发生了变化，实体追踪器只会每隔一定时间才向范围内的玩家发送相关的数据，而这一间隔则为实体追踪器的同步时间

投掷物、重力方块、TNT 等实体有着较大的实体同步周期，而末影水晶甚至不与客户端进行信息同步，这导致在设计相关机器的时候， 客户端容易出现实体运动与服务端不同步的情况，这是很烦人的。这时，你可以使用本规则将实体同步间隔设为 1，让服务端每 gt 都同步所有实体的数据，尽可能避免不同步的发生

爆炸不影响实体 (explosionNoEntityInfluence)

爆炸不会影响任何实体。这里的影响包括伤害、加速等效果

虽然 carpet 的规则 explosionNoBlockDamage 可以阻止爆炸对方块的影响，但它并不阻止爆炸对实体的影响， 会导致乱飞的 TNT 依然可以把意料之外的实体炸没。这不好，用这条规则给我关

爆炸数据包广播范围 (explosionPacketRange)

设置在爆炸发生时，爆炸数据包对玩家的广播范围

在爆炸发生时，服务端仅会告知离爆点 64m 内的玩家，这里发生了爆炸，而离爆点 64m 范围外的玩家是见不到爆炸效果的

本规则的作用即为修改 64m 这一常量，你可以将其调大以见到更远的爆炸，也可以将其调小来减轻巨量爆炸时客户端的压力

explosionPacketRange

禁用耕地被踩踏 (farmlandTrampledDisabled)

阻止耕地被生物踩成泥土

在设计一些如小黑瓜机这种，使用了生物 + 耕地的机器时，很容易会遇到生物踩烂了耕地的情况。 这挺烦人的，尤其是在做概念验证的时候，毕竟这时我们更关心其他数据，并不在意耕地是否足够安全

拍扁三角形分布 (flattenTriangularDistribution)

本规则仅在 Minecraft >= 1.19 中存在

把 Minecraft 随机数发生器的三角形分布改为均匀分布。借此，边界情况就更有可能发生了

在 MC 1.19 版本之前，fabric carpet 提供了一个被命名为 extremeBehaviours 的规则，它能使得一些依赖正态分布随机数生成器的游戏机制更频繁地产生极端情况。 这些机制包括：投掷器喷出物品的随机速度、箭矢的基础伤害、生物生成时的 FOLLOW_RANGE 属性随机调整等

正态分布的随机数生成器产生的结果是无边界的，在极端情况下可能会产生偏差很大的随机值。extremeBehaviours 正是为了测试机器在这些极端情况的稳定性而生。 不过随着 MC 1.19 的到来，麻将把各种正态分布换成了有界的三角分布，fabric carpet 也因此将 extremeBehaviours 规则删除了

但是，就算是三角分布，它的边界情况依然也是罕见的，设计机器时也依然存在着测试边界情况的需求。 那么不如整一个 flattenTriangularDistribution，把三角分布替换成值域相同的均匀分布，让边界情况更容易发生

在本规则开启前后，相关随机数生成器的概率密度函数变化如下所示。左侧为原来的三角分布，右侧为修改后的均匀分布

flattenTriangularDistribution

禁用物品实体跳过移动运算 (itemEntitySkipMovementDisabled)

移除物品实体跳过移动运算的机制。改回为 1.13 及以前的物品实体机制，也就是低速着地的物品实体依然会每 gt 都运算移动，而非每 4gt

当你需要精准使用物品实体运动逻辑时有用。会导致利用了相关机制的机器无法工作，如 2no2name 的无线红石

在 1.14+ 中，mojang 为物品实体引入了一个新逻辑：当物品实体满足以下两种情况

  • 物品实体着地
  • 物品实体水平方向的速度小于等于的平方 > $10^{-5}m/gt$，即水平速度不超过约 0.063m/s

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

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

重新引入瞬时方块更新逻辑 (instantBlockUpdaterReintroduced)

本规则仅在 Minecraft >= 1.19 中存在

重新引入 1.19 以前的瞬时方块更新逻辑。本规则让基于栈溢出的更新抑制在 1.19+ 中再次可行

它还可以让微时序记录器的记录结果更加清晰有逻辑，如 1.19 以前的版本一样的清晰

MC 1.19 引入了人工栈数据结构来处理 MC 方块更新，这导致 1.19 之后，方块并不会瞬时发出更新了。这带来了两个影响：

  • 足够长的方块更新链不再能引发 JVM 栈溢出异常，这导致基于方块更新栈溢出的更新抑制不再可行
  • 方块更新之间的代码调用关系从直接调用变成了间接调用，变得更加晦涩。这不仅仅使得代码阅读的难度增加，还会使得微时序记录器的输出变得抽象起来，增加借助微时序记录器分析时序的难度

好在麻将并没有完全移除瞬时更新的逻辑，因此可以整条规则把 1.19 以前的瞬时方块更新带回来

参考 Void514 的观点，在这里，一个操作是“瞬时”的，指：在操作的结果发生时，触发操作的原因位于当前 JVM 的函数调用栈上

光照更新 (lightUpdates)

暂停或者禁止光照更新

  • 若被设为抑制(suppressed)，光照更新不会被执行，这可用于模拟光照抑制器
  • 若被设为忽略(ignored)，光照更新不会被计划，这常用于在创造模式中制造光照错误
  • 若被设为关闭(off)，光照更新不会被计划或被执行

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

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

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

值 是否将光照更新入队 是否执行光照队列中的更新 表现
开启 (on) 是 是 原版表现，光照更新正常执行
抑制 (suppressed) 是 否 光照更新入队，但不出队。模拟光照队列被光照抑制器阻塞的情况。在本规则的值调回为开启或忽略时，队列中积攒的光照更新会依次执行
忽略 (ignored) 否 是 光照更新不入队，但队列中的光照更新正常执行。常用于制作一些幽灵光源或无亮度光源
关闭 (off) 否 否 光照更新不入队，队列中的光照更新也不执行。相比于选项“抑制”，光照更新被关闭地更彻底

矿车搭载乘客最小速度 (minecartTakePassengerMinVelocity)

决定矿车将其附近实体作为乘客搭载上车所需的最低水平方向速度（m/gt）。将其设为 0 以让矿车忽略速度，像船一样总能将附件实体载上车。将其设为 NaN 以让矿车永远不能把实体载上车

一个矿车想要把附近的生物吸上车，需要满足其在水平方向上的速度大于 0.1m/gt（2m/s）这个条件，这意味着静止 / 慢慢移动的矿车无法把生物吸上车

在设计机器时，这个矿车吸生物上车的条件有时候就挺烦人的。为了把生物装进矿车里，我们还得专门搞一段铁轨来给矿车加速。 如果矿车能像船一样，蹭着生物就能吸上车，那就最好了。多说无益，整条规则改之

由于本规则修改的是“矿车搭载乘客的最小速度”，因此你可以把它设置成不同的取值，来满足不同场景下的需求：

  • 把值设成 0：矿车像船一样，蹭着生物就能把生物吸上去
  • 把值设成 NaN：矿车无论怎样都不会把生物吸上去

minecartTakePassengerMinVelocity

橡树长成鸡腿树百分率 (oakBalloonPercent)

橡树树苗长成鸡腿树（fancy_oak）的概率，使用百分率作为值。如，0 代表没有鸡腿树，50 代表有 50% 的概率长成鸡腿树，100 代表总长成鸡腿树

将其设为 -1 以禁用本规则并使用原版逻辑（10% 概率长成鸡腿树）

若想高效地测试树场对鸡腿橡树的兼容性，与其对着原版的 10% 鸡腿树概率慢慢尝试，不如开条规则来修改原版的概率。必出鸡腿树 / 必不出鸡腿树，任你选择

禁用侦测器检测功能 (observerNoDetection)

不准侦测器在受状态更新时添加计划刻事件。可以认为这条规则禁用了观察者的检测功能

在使用 /fill、/clone 指令、结构方块、worldedit 等方式来修改世界时，有时候会莫名其妙地把侦测器给激活了。 与其想办法关掉方块更新，排除各种误触的地方，不如直接禁止侦测器检测方块变化，从源头上解决问题

值得注意的是，不要在机器开着的时候启用这条规则，毕竟这条规则的作用范围是整个服务器

observerNoDetection

POI更新开关 (poiUpdates)

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

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

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

融雪最小亮度 (snowMeltMinLightLevel)

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

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

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

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

结构方块不保留流体 (structureBlockDoNotPreserveFluid)

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

如图所示

structureBlockDoNotPreserveFluid

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

结构方块范围限制 (structureBlockLimit)

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

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

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

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

同步光照线程 (synchronizedLightThread)

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

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

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

计划刻上限 (tileTickLimit)

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

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

TNT引信时长 (tntFuseDuration)

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

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

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

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

TNT忽略红石信号 (tntIgnoreRedstoneSignal)

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

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

tntIgnoreRedstoneSignal

完全没有方块更新 (totallyNoBlockUpdate)

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

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

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

坚韧的凋零玫瑰 (toughWitherRose)

由死而生，凋零玫瑰非常坚韧，能在任意表面上种植。该规则移除了凋零玫瑰所有的放置约束，这意味着你可以将零玫瑰种植在任何地方。

在你想用更新抑制的凋零玫瑰做凋灵骷髅塔时，这条规则可以帮你一把

背景知识：凋灵玫瑰在受到状态更新时会检查其是否处于合法的状态，如果不合法则立即掉落

如规则介绍所述，在设计把凋灵玫瑰种在地狱砖上的凋灵骷髅塔时，很容易因误触而整掉了一整片的凋灵玫瑰，非常烦人

本条规则的作用就是去除凋灵玫瑰的一切放置限制，让凋灵玫瑰可以种在任何方块上。在什么地狱砖，铁轨，岩浆，甚至空气之上，都能种凋灵玫瑰

toughWitherRose

禁用海龟蛋被践踏 (turtleEggTrampledDisabled)

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

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

turtleEggTrampledDisabled

亡灵生物别在阳光下着火 (undeadDontBurnInSunlight)

阻止亡灵生物在阳光下着火。不过他们的头盔依然会在阳光下损失耐久

有时在主世界测试一些与亡灵生物相关的机器时，还得记得给做个遮阳天花板，防止亡灵生物被晒死。 这挺烦人的，不如整个规则给亡灵涂足防晒霜。毕竟绝大部分情况下，给最终实装版本加个天花板防晒是很容易的操作

虚空伤害数值 (voidDamageAmount)

修改虚空伤害的数值

让掉虚空的生物死快些，原版虚空的 4 点伤害有点太低了，直接加到 1000 点

虚空伤害忽略玩家 (voidDamageIgnorePlayer)

阻止玩家受到任何虚空伤害。对玩家完全无害的虚空，好耶！

有些时候，你想飞到虚空深处，来从远处贴近世界底部的机器的整体运行情况，但又担心会被无视游戏模式的虚空伤害搞死。 不如整个规则，移除虚空对玩家的伤害，让玩家想在虚空逛多深逛多久都没问题

虚空相对海拔高度 (voidRelatedAltitude)

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

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

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

禁用凋灵生成音效 (witherSpawnedSoundDisabled)

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

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

经验球追踪距离 (xpTrackingDistance)

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

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

生存模式用新增特性/bug修复

玩家重生丢失客户端设置数据修复 (clientSettingsLostOnRespawnFix)

修复在玩家重生或从末地进入末地门时，新创建的玩家实体未迁移旧玩家实体中储存着的客户端设置的问题。因此依赖客户端设置数据的模组总能正常的工作，如本模组以及 worldedit 模组的服务端翻译

对于玩家重生，以及玩家从末地进入末地门这两个操作，MC 会重建一个玩家实体对象，并把原实体的数据复制到新实体上

可惜，在这个复制数据的过程中，麻将忘了复制客户端配置相关的数据，这包括但不限于玩家客户端的语言设置。 这会导致一些依赖客户端设置数据的 mod 无法按照预期工作，比如 worldedit 和本 mod 的文本在玩家重生后都变成了英文

这是个 bug，虽然不严重，但挺影响游戏体验的，得重进服务器或者手动调一下客户端设置，才能恢复正常

有虫，得修，/carpet setDefault clientSettingsLostOnRespawnFix true，done

技术上来讲，在从旧玩家实体复制数据到新玩家实体的过程中，这条规则会重新将曾经用于旧玩家实体的客户端设置数据包（ClientSettingsC2SPacket）应用到新的玩家实体上。

发射器发射龙息 (dispensersFireDragonBreath)

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

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

dispensersFireDragonBreath

保持弱加载区块的怪物 (keepMobInLazyChunks)

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

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

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

大木桶 (largeBarrel)

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

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

largeBarrel

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

刷铁轨机修复 (railDupingFix)

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

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

railDupingFix

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

可再生龙蛋 (renewableDragonEgg)

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

可与选项 dispenserFireDragonBreath 联动

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

实现的具体逻辑：

  1. 在随机刻选中龙蛋方块后，龙蛋有 1 / 64 的几率尝试再生。这一否决率能保证龙蛋虽然可再生，但仍然是一种较为稀有的物资
  2. 龙蛋会找到与其所在位置 1 立方米范围相交的龙息效果云。若没找到，终止再生流程；否则随机挑选一个效果云
  3. 龙蛋会选择附近的一个随机位置，尝试生成龙蛋方块。选择位置的逻辑跟龙蛋被点击后随机传输的逻辑一致，不过仅有一次尝试机会。如果被选中的位置是空气的话，则龙蛋生成成功，龙息效果云的半径变为原 1 / 5

renewableDragonEgg

可再生龙首 (renewableDragonHead)

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

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

可再生鞘翅 (renewableElytra)

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

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

刷沙机修复 (sandDupingFix)

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

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

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

TNT复制修复 (tntDupingFix)

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

Dupe bad dig good

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

  • 基于依附性方块掉落而发出更新的，如死珊瑚更新源。原理为 b36 方块的放置会发出状态更新，导致还未被置为 b36 的依附性方块发现自己附着于 b36 上，或者依附在空气上，从而掉落，并发出更新
  • 基于方块被移除时发出更新的，如亮起侦测器更新源。原理为一些红石原件（侦测器、中继器等）在亮起时被移除的时候，会发出方块更新，用于告知附近方块你的信号源没了

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

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

    1. 先不发出任何更新地，将活塞所推动方块的原位置替换为空气方块
    2. 再让原版的逻辑将这些空气方块转换为 b36

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

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

tntDupingFix

工具化TNT (tooledTNT)

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

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

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

tooledTNT

游戏优化

优化高速实体移动 (optimizedFastEntityMovement)

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

受 carpetmod112 的规则 fastMovingEntityOptimization 启发

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

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

optimizedFastEntityMovement

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

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

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

优化硬碰撞箱实体碰撞 (optimizedHardHitBoxEntityCollision)

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

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

在加载区块前开启它以使其工作，在地狱门刷怪塔中有~20%的性能提升。与添加了新实体的 mod 可能不兼容

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

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

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

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

TNT优化高优先级 (optimizedTNTHighPriority)

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

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

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

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

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

其他规则

禁用反刷屏监测 (antiSpamDisabled)

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

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

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

存活时间追踪器 (commandLifeTime)

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

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

世界控制命令开关 (commandManipulate)

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

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

袭击追踪器 (commandRaid)

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

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

射线追踪命令开关 (commandRaycast)

启用 /raycast 命令用于分析射线追踪

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

刷新命令开关 (commandRefresh)

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

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

移除实体命令开关 (commandRemoveEntity)

启用 /removeentity 命令用于直接在世界中抹除目标实体

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

睡眠命令开关 (commandSleep)

启用 /sleep 命令用于制造卡顿

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

反混淆崩溃报告堆栈追踪 (deobfuscateCrashReportStackTrace)

反混淆崩溃报告中输出的堆栈追踪

在分析生产环境下游戏崩溃的日志时，一份反混淆好的堆栈追踪所提供的阅读体验可比混淆版的堆栈追踪好多了

假人名称前缀 (fakePlayerNamePrefix)

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

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

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

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

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

fakePlayerNamePrefix

假人名称后缀 (fakePlayerNameSuffix)

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

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

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

假人远程召唤 (fakePlayerRemoteSpawning)

使用 /player 指令远程召唤假人的权限需求。在这里，“远程”指的是被召唤的假人位于 16m 以外，或另一个维度

禁止远程召唤 bot，这可一点都不像一个“小号”能做的事情

默认值为 true，对应着 fabric carpet 的原始表现——你可以在任意地方召唤假人

HUD记录器更新间隔 (HUDLoggerUpdateInterval)

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

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

存活时间追踪器考虑怪物容量 (lifeTimeTrackerConsidersMobcap)

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

  • true: 不追踪不占用怪物容量的生物，并与生物不影响怪物容量的时刻将其标记为已移除，如当它们捡起物品时。便于设计刷怪塔
  • false: 追踪所有可追踪的生物，在生物确实被删除时将其标记为已移除。便于设计袭击农场或非刷怪塔的机器

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

光照队列记录器采样时长 (lightQueueLoggerSamplingDuration)

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

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

移动记录器 (loggerMovement)

移动记录器的开关 / 权限等级需求

移动记录器（movement logger）并不是一个适合在生存服中使用的记录器，毕竟它容易刷屏 + 会暴露其他玩家的位置信息，最好还是加个权限开关来控制下

怪物容量显示忽略杂项 (mobcapsDisplayIgnoreMisc)

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

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

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

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

op玩家不准作弊 (opPlayerNoCheat)

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

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

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

  • 原版的 F3 + N、F3 +F4 切换游戏模式（/gamemode）
  • 小地图模组里的选点传送（/tp、/teleport）
  • JEI 等物品列表显示模组中的物品给予（/give）
  • 投影模组粘贴原理图的方块放置与实体召唤（/setblock、/summon）

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

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

持久性记录器订阅 (persistentLoggerSubscription)

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

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

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

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

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

stop指令两步确认 (stopCommandDoubleConfirmation)

为 /stop 指令添加两步确认机制，以防止误触导致意外地关掉了服务器。你需要在1分钟内输入两次 /stop 指令来关闭服务器。该确认机制仅对玩家有效

一波操作猛如虎，/st + tab 一顿敲，一按回车服务器无。这种输错指令把服务器关掉了的情况是小天才最喜欢干的事，比如在敲 //stack 时少打了个 /

对于这种手抖问题，加一个两步确认就能很好的避免了

stopCommandDoubleConfirmation

可视化投掷物记录器 (visualizeProjectileLoggerEnabled)

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

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

visualizeProjectileLoggerEnabled

阻止更新抑制崩溃 (yeetUpdateSuppressionCrash)

阻止服务端因栈溢出异常造成崩溃。具体功能实现类似 carpet 的 updateSuppressionCrashFix 规则，但包含更多信息

并不是所有版本的 fabric carpet / carpet extra 都提供了更新抑制防崩服的规则。对于那些缺失 updateSuppressionCrashFix 的场景，就是本规则派上用场的时候了

借助微时序记录器同款游戏阶段记录功能，该规则可在更新抑制崩服时提供更加丰富的信息

yeetUpdateSuppressionCrash

若 fabric carpet / carpet extra 存在规则 updateSuppressionCrashFix，本规则会自动禁用，以避免发生冲突

  • 移植自：
    • fabric carpet 1.4.50 的规则 updateSuppressionCrashFix
    • TISCarpet13 build238 的规则 yeetUpdateSuppressionCrash
  • 冲突版本：
    • fabric carpet: [1.4.49, 1.4.76]
    • carpet extra: [1.4.14, 1.4.43]