前往我的博客獲得更好的markdown瀏覽體驗(yàn)以及更為長(zhǎng)期的更新支持：

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

作為一個(gè)地毯 mod 擴(kuò)展，Carpet TIS Addition （也稱(chēng)為 TIS Carpet）自然擁有著大量的可用于操控游戲特性的規(guī)則（截止至 v1.33 版本，共含有 67 個(gè)的規(guī)則），它們可以通過(guò)指令??來(lái)使用。在默認(rèn)情況下，所有的規(guī)則均為關(guān)閉狀態(tài)，以保證服務(wù)端的原版性以及對(duì)性能的零額外開(kāi)銷(xiāo)

這一系列的規(guī)則大部分是用于增強(qiáng)創(chuàng)造模式游戲體驗(yàn)的，包括對(duì)游戲特性的控制、修改和開(kāi)關(guān)等。除此之外還有不少為生存模式添加的有意思的機(jī)制、bug 修復(fù)，以及一些對(duì)游戲的優(yōu)化。

下文將按照這些規(guī)則的類(lèi)別，按照字母順序，對(duì)他們進(jìn)行詳細(xì)的介紹。在zhao敘chao述規(guī)則簡(jiǎn)介的同時(shí)，我還會(huì)寫(xiě)下這些規(guī)則的設(shè)計(jì)意圖、常見(jiàn)用途、注意事項(xiàng)，以及背后隱藏著的游戲機(jī)制

Carpet TIS Addition 相關(guān)鏈接：

- Github 倉(cāng)庫(kù)：https://github.com/TISUnion/Carpet-TIS-Addition

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

- CurseForge 頁(yè)面：https://www.curseforge.com/minecraft/mc-mods/carpet-tis-addition

- Modrinth 頁(yè)面：https://modrinth.com/mod/carpet-tis-addition

創(chuàng)造模式用新增機(jī)制

這一系列規(guī)則添加了為創(chuàng)造模式設(shè)計(jì)的新功能/新機(jī)制，能有效地提升創(chuàng)造模式下的游戲體驗(yàn)

方塊放置忽略實(shí)體 (blockPlacementIgnoreEntity)

方塊可放置時(shí)無(wú)視實(shí)體碰撞檢測(cè)，也就是你可以將方塊放在實(shí)體內(nèi)，僅對(duì)創(chuàng)造模式玩家有效

在設(shè)計(jì)各種包含實(shí)體的機(jī)器，遇到比如盔甲架開(kāi)盒檢測(cè)合成站、漏斗礦車(chē)藏方塊等情況的時(shí)候，容易出現(xiàn)需要在實(shí)體碰撞箱范圍內(nèi)放置方塊的情況，但原版又不允許玩家在實(shí)體碰撞箱中放方塊，因此就可以借助這條規(guī)則進(jìn)行繞過(guò)

創(chuàng)造玩家強(qiáng)制打開(kāi)容器 (creativeOpenContainerForcibly)

允許創(chuàng)造模式的玩家打開(kāi)被阻擋的容器，如潛影盒

在設(shè)計(jì)如打包機(jī)等機(jī)器時(shí)，經(jīng)常需要查看并操控其中的潛影盒，但打包機(jī)的潛影盒往往會(huì)被一些實(shí)體方塊所阻擋。借助這條規(guī)則，創(chuàng)造模式玩家可以無(wú)視其上方的方塊，強(qiáng)行打開(kāi)這種被阻擋的潛影盒。

除了潛影盒外，被阻擋的箱子末影箱等也可以被創(chuàng)造模式強(qiáng)制打開(kāi)

發(fā)射器不消耗物品 (dispenserNoItemCost)

開(kāi)啟后，發(fā)射器和投擲器使用被激活時(shí)不再消耗物品。無(wú)論投擲物品還是使用物品都如此，但是投擲器傳輸物品仍會(huì)消耗物品

當(dāng)你需要測(cè)試基于發(fā)射器/投擲器的機(jī)器，但又不想做補(bǔ)貨模塊的話，可以用這條規(guī)則來(lái)讓發(fā)射器/投擲器不消耗物品

不過(guò)由于這條規(guī)則會(huì)對(duì)所有發(fā)射器/投擲器造成影響，如果可行的話建議使用規(guī)則“漏斗不消耗物品”替代

enchant指令約束移除 (enchantCommandNoRestriction)

移除?/enchant?指令中所有對(duì)目標(biāo)附魔的約束

包括附魔與物品的匹配性檢查、附魔間的沖突檢查、附魔重復(fù)檢查、附魔等級(jí)上限檢查。

實(shí)體放置無(wú)視碰撞 (entityPlacementIgnoreCollision)

在使用物品放置實(shí)體時(shí)禁用相關(guān)的方塊與實(shí)體的碰撞檢測(cè)。受影響的物品：盔甲架、末影水晶、所有種類(lèi)的船。刷怪蛋物品不在作用范圍內(nèi)

類(lèi)似規(guī)則“方塊放置忽略實(shí)體”，不過(guò)這次針對(duì)的是實(shí)體的放置

方塊狀態(tài)解析忽略失敗 (failSoftBlockStateParsing)

忽略在?/setblock?等指令的方塊狀態(tài)參數(shù)中出現(xiàn)的無(wú)效鍵/值參數(shù)。原版中這些無(wú)效的鍵/值會(huì)導(dǎo)致指令解析出錯(cuò)。這個(gè)規(guī)則抑制了這一出錯(cuò)，有助于跨版本粘貼 litematica 原理圖等

例如，在 mc 1.14 中音符盒添加了鐵木琴音色，在音符盒放置于鐵塊上時(shí)其方塊狀態(tài)?instrument?的值將被設(shè)置為?iron_xylophone。如果使用投影將這一方塊粘貼至 mc 1.13 中，會(huì)由于該方塊狀態(tài)無(wú)法被解析而導(dǎo)致對(duì)應(yīng)的?/setblock?指令出錯(cuò)，導(dǎo)致位于鐵塊上的音符盒無(wú)法被放置。如果啟用本條規(guī)則，那么該音符盒將會(huì)使用默認(rèn)的?instrument?方塊狀態(tài)正常地由?/setblock?指令放置

禁用流體破壞 (fluidDestructionDisabled)

禁用流體流動(dòng)造成的方塊破壞，包括水和巖漿。此時(shí)流體會(huì)簡(jiǎn)單地停留在即將破壞方塊時(shí)的狀態(tài)

在設(shè)計(jì)包含流體的機(jī)器/建筑時(shí)，比如帶有水道的機(jī)器，很容易有意無(wú)意地破壞了水道導(dǎo)致漏水，然后把電路裝飾方塊沖壞。借助這條規(guī)則，把流體破壞關(guān)掉后，就可以大膽地修改與流體相關(guān)的部件，隨便漏水，完全不需要擔(dān)心流體沖壞東西了

不過(guò)還是得小心水固化混凝土、巖漿點(diǎn)著地毯等情況，這些情況是本條規(guī)則無(wú)法阻止的

漏斗計(jì)數(shù)器無(wú)限速度 (hopperCountersUnlimitedSpeed)

當(dāng)漏斗指向羊毛方塊時(shí)，漏斗將擁有無(wú)限的物品吸取以及傳輸速度，且無(wú)冷卻時(shí)間

僅當(dāng) Carpet Mod 中的規(guī)則?hopperCounters?開(kāi)啟時(shí)有效

作為一個(gè)漏斗計(jì)數(shù)器，這個(gè)漏斗就別在拘束于原版一次一組的吸物品速度，也別 8gt 才工作一次了，來(lái)點(diǎn)無(wú)限的吸物品速度，來(lái)多少物品就吸多少物品。借此，對(duì)于需要用到漏斗計(jì)數(shù)器的時(shí)候，一個(gè)漏斗 + 一個(gè)羊毛即可處理干凈所有來(lái)到的物品，不需要擔(dān)心出現(xiàn)機(jī)器產(chǎn)率過(guò)高，漏斗吸不過(guò)來(lái)的情況

實(shí)際的代碼實(shí)現(xiàn)中，作為漏斗計(jì)數(shù)器的漏斗會(huì)嘗試傳輸 32767 次，以防止在與其他 mod 沖突時(shí)無(wú)限死循環(huán)吸物品

漏斗不消耗物品 (hopperNoItemCost)

上方放有羊毛方塊的漏斗可不消耗物品地?zé)o限輸出儲(chǔ)存的物品

誰(shuí)不想要一個(gè)可以無(wú)限輸出物品的漏斗呢？

瞬時(shí)命令方塊 (instantCommandBlock)

令位于紅石礦上的命令方塊瞬間執(zhí)行命令，而不是添加一個(gè) 1gt 的計(jì)劃刻事件用于執(zhí)行。僅影響普通命令方塊

在原版中，脈沖型命令方塊接收到紅石信號(hào)時(shí)并非是瞬間執(zhí)行所儲(chǔ)存的命令的，而是添加一個(gè)延遲為 1gt 的計(jì)劃刻事件，然后在該計(jì)劃刻事件中執(zhí)行命令，這會(huì)影響我們一些與微時(shí)序緊密相關(guān)的操作

該規(guī)則移除了這一延遲，讓位于紅石礦上方的命令方塊在受激活的瞬間執(zhí)行命令

除此之外，原版的命令方塊有著每 gt 只能執(zhí)行最多一次指令的限制。這一限制也被該規(guī)則移除了，當(dāng)然只對(duì)紅石礦上方的命令方塊有效

微時(shí)序 (microTiming)

微時(shí)序記錄器的的總開(kāi)關(guān)。微時(shí)序記錄器相關(guān)介紹較長(zhǎng)，本篇文章不進(jìn)行敘述

微時(shí)序染料記號(hào) (microTimingDyeMarker)

允許玩家手持染料右擊方塊來(lái)將其標(biāo)記為微時(shí)序監(jiān)視器的目標(biāo)

微時(shí)序記錄器的染料記號(hào)功能的開(kāi)關(guān)。微時(shí)序記錄器相關(guān)介紹較長(zhǎng)，本篇文章不進(jìn)行敘述

微時(shí)序目標(biāo) (microTimingTarget)

設(shè)置指定微時(shí)序記錄器記錄目標(biāo)的方法

• labelled: 記錄被羊毛塊標(biāo)記的事件

• in_range: 記錄離任意玩家 32m

• all: 記錄所有事件。謹(jǐn)慎使用

• marker_only: 僅記錄被染料記號(hào)標(biāo)記的方塊。將其與規(guī)則?microTimingDyeMarker??一起使用

指定微時(shí)序記錄器該記錄哪些目標(biāo)。如果能確?？蛻?hù)端均有 carpet 的話，可以選擇?marker_only，讓玩家都用染料記號(hào)來(lái)標(biāo)記目標(biāo)

微時(shí)序游戲刻劃分 (microTimingTickDivision)

設(shè)置指定微時(shí)序記錄器劃分兩個(gè)游戲刻的方法

• world_timer: 劃分于世界計(jì)時(shí)器自增時(shí)

• player_action: 劃分于玩家操作階段開(kāi)始前

國(guó)內(nèi)外玩家微時(shí)序相關(guān)的模型在游戲刻的劃分上有著不小差別：

• 國(guó)內(nèi)玩家將世界計(jì)時(shí)器自增時(shí)刻作為游戲階刻的劃分點(diǎn)，優(yōu)勢(shì)是計(jì)劃刻元件的延遲可以跟游戲刻完全對(duì)應(yīng)上，缺點(diǎn)是跨維度分析時(shí)序/分析非主世界其他游戲階段時(shí)序時(shí)會(huì)比較困難

• 國(guó)外玩家將游戲代碼中完整的一次循環(huán)作為一個(gè)游戲刻的范圍，優(yōu)勢(shì)是游戲刻能跟服務(wù)端的 tick 計(jì)數(shù)器完美匹配，面對(duì)多維度時(shí)序分析時(shí)也輕而易舉，不過(guò)缺點(diǎn)需要對(duì)玩家操作等階段觸發(fā)的計(jì)劃刻元件的延遲減少作特殊解釋處理

該規(guī)則則作為一種為微時(shí)序記錄器切換兩種游戲刻模型的方式

精準(zhǔn)實(shí)體放置 (preciseEntityPlacement)

當(dāng)使用物品放置/召喚實(shí)體時(shí)，將實(shí)體準(zhǔn)確地放置在玩家指針指向的坐標(biāo)點(diǎn)。受影響的物品：刷怪蛋、盔甲架、末影水晶

可以配合??entityPlacementIgnoreCollision?一起使用，達(dá)到快速放置合成站的盔甲架的效果

中繼器延遲折半 (repeaterHalfDelay)

當(dāng)紅石中繼器位于紅石礦上方時(shí)，紅石中繼器的延遲將減半。延遲將會(huì)由 2, 4, 6, 8 游戲刻變?yōu)?1, 2, 3, 4 游戲刻

需要 1gt 或者奇數(shù) gt 的延遲，或者想要逐 gt 地調(diào)整電路延遲看看效果，但又懶得用原版電路實(shí)現(xiàn)，怎么辦？啟用這一條規(guī)則，把中繼器放在紅石礦上，完事！

紅石粉隨機(jī)更新順序 (redstoneDustRandomUpdateOrder)

隨機(jī)化紅石粉發(fā)出方塊更新的順序，有助于測(cè)試你的裝置是否依賴(lài)于位置。在規(guī)則?fastRedstoneDust?啟用時(shí)無(wú)效

一個(gè)簡(jiǎn)單快捷的方式，用于測(cè)試你的紅石粉飛線是否具有位置依賴(lài)性

由于該規(guī)則的實(shí)現(xiàn)為隨機(jī)打亂紅石粉發(fā)出更新的順序，與真實(shí)情況下出現(xiàn)的依賴(lài)位置是“隨機(jī)”是有區(qū)別的。你可以視為該規(guī)則隨機(jī)出更新順序集合是真實(shí)情況更新順序集合的超集，也就是能在該規(guī)則啟用下穩(wěn)定正常工作的機(jī)器一定能不會(huì)在真實(shí)情況中出現(xiàn)問(wèn)題，但在該規(guī)則啟用下可能出錯(cuò)的機(jī)器不一定會(huì)在真實(shí)情況中出現(xiàn)問(wèn)題，或者在真實(shí)情況下出現(xiàn)問(wèn)題的概率極低

創(chuàng)造模式用游戲修改

為創(chuàng)造模式設(shè)計(jì)的，對(duì)游戲參數(shù)/行為的更改，讓你更好的控制 Minecraft

方塊事件廣播范圍 (blockEventPacketRange)

設(shè)置會(huì)在方塊事件成功執(zhí)行后收到數(shù)據(jù)包的玩家范圍。對(duì)于活塞而言，這一個(gè)數(shù)據(jù)包用于顯示活塞的運(yùn)動(dòng)。把這個(gè)值調(diào)小以減小客戶(hù)端卡頓

在服務(wù)端成功執(zhí)行一次方塊事件時(shí)，服務(wù)端將會(huì)把這一方塊事件廣播給 64m 范圍內(nèi)的玩家。對(duì)于活塞而言，這一廣播的方塊事件數(shù)據(jù)包將觸發(fā)客戶(hù)端為活塞添加方塊事件，隨即計(jì)算活塞的推拉并借助客戶(hù)端的 b36 方塊實(shí)體顯示活塞的移動(dòng)動(dòng)畫(huà)。本規(guī)則的用途即為修改 64m 這一常量

如果你在調(diào)試一些有著大量活塞運(yùn)行導(dǎo)致客戶(hù)端幀率很低的機(jī)器，你可以將這個(gè)值調(diào)低，降低活塞動(dòng)畫(huà)的范圍，提升幀數(shù)

如果你想要錄制機(jī)器的運(yùn)行，如使用 replay mod，你可以將這個(gè)值調(diào)高，這樣離玩家很遠(yuǎn)的活塞動(dòng)畫(huà)也不會(huì)丟失

該功能與 g4mespeed 的 Block Event Distance 設(shè)置相同。若本規(guī)則的值有修改，g4mespeed 所設(shè)值將被覆蓋；否則 g4mespeed 的值將會(huì)被使用

p.s. 本規(guī)則是 Carpet TIS Addition 的第一條規(guī)則

煉藥鍋方塊類(lèi)物品交互修復(fù) (cauldronBlockItemInteractFix)

讓玩家可以對(duì)著填充有水的煉藥鍋放置方塊。僅對(duì) Minecraft <= 1.16.x 有效。這個(gè)煩人的機(jī)制已經(jīng)在 1.17+ 中被修復(fù)了

麻將的奇怪腦回路在為了處理有水煉藥鍋為潛影盒去色的邏輯時(shí)，直接影響了非潛影盒的方塊類(lèi)物品的放置，導(dǎo)致玩家需要按住 shift 才可在煉藥鍋旁放方塊。這當(dāng)然不能忍，用這條規(guī)則給我修！

區(qū)塊更新數(shù)據(jù)包閾值 (chunkUpdatePacketThreshold)

如果方塊變化的數(shù)量大于這個(gè)閾值，則游戲?qū)H發(fā)送區(qū)塊更新數(shù)據(jù)包而非若干個(gè)方塊變更數(shù)據(jù)包。增加該數(shù)值或許可以減小網(wǎng)絡(luò)帶寬用量，并在子區(qū)段同時(shí)存在不少方塊實(shí)體與方塊變化時(shí)提升客戶(hù)端的幀數(shù)

將其設(shè)為非常高以模擬1.16+的表現(xiàn)，也就是不存在區(qū)塊更新數(shù)據(jù)包，僅有多個(gè)方塊變更數(shù)據(jù)包。該規(guī)則僅于1.16前的版本有效

大型機(jī)器運(yùn)行時(shí)客戶(hù)端的卡頓源之一，為區(qū)塊重建，而區(qū)塊重建是因由服務(wù)端發(fā)送的區(qū)塊數(shù)據(jù)包（yarn 名?ChunkDataS2CPacket）引起的

在區(qū)塊刻階段前后（是前是后根據(jù)游戲版本決定，在此不重要），服務(wù)端會(huì)將每個(gè)區(qū)塊中這一 gt 內(nèi)發(fā)生的方塊變化同步至客戶(hù)端。在 1.16 前，當(dāng)一個(gè)區(qū)塊中發(fā)生的方塊變化數(shù)量超過(guò) 64 時(shí)，服務(wù)端將把整個(gè)區(qū)塊的數(shù)據(jù)完整地同步給玩家，這會(huì)導(dǎo)致客戶(hù)端重建區(qū)塊，重新增刪內(nèi)部的方塊實(shí)體，導(dǎo)致了較高的客戶(hù)端卡頓，以及較大的網(wǎng)絡(luò)負(fù)載。不過(guò)完整的區(qū)塊數(shù)據(jù)包也有一個(gè)好處，它可以去除客戶(hù)端在這個(gè)區(qū)塊中出現(xiàn)的幽靈方塊

這一規(guī)則的用途即為調(diào)整 64 這一常量，畢竟 1gt 發(fā)生至少 64 處方塊更新在大型機(jī)器中實(shí)在是太常見(jiàn)了。將其調(diào)高，可以避免服務(wù)端發(fā)送大量區(qū)塊數(shù)據(jù)包，提升客戶(hù)端幀數(shù)，減少網(wǎng)絡(luò)帶寬占用，但得小心幽靈方塊

區(qū)塊刻速度 (chunkTickSpeed)

修改每游戲刻每區(qū)塊的區(qū)塊刻運(yùn)算的頻率。默認(rèn)值為 1。將其設(shè)為 0?以禁用區(qū)塊刻。受影響的游戲階段：雷電、結(jié)冰與積雪、隨機(jī)刻

在值為?n?時(shí)，每游戲刻每區(qū)塊，氣候相關(guān)的階段會(huì)發(fā)生?n?次，而隨機(jī)刻會(huì)在每區(qū)段中發(fā)生?n?*?randomTickSpeed?次

一個(gè)區(qū)塊刻階段包含著以下多種游戲階段：雷電&骷髏馬的生成、雨雪的降落與水源結(jié)冰，以及隨機(jī)抽取方塊執(zhí)行隨機(jī)刻。對(duì)于其中的隨機(jī)刻階段，我們可以簡(jiǎn)單地使用?/gamerule randomTickSpeed?來(lái)控制其運(yùn)行速度，或者阻止隨機(jī)刻的執(zhí)行，不過(guò)對(duì)于雷電冰雪這一類(lèi)氣候相關(guān)的運(yùn)行邏輯，并沒(méi)有對(duì)應(yīng)的游戲規(guī)則

本規(guī)則即為一個(gè)類(lèi)似?/gamerule randomTickSpeed?的游戲規(guī)則，可以將其設(shè)為一個(gè)很大的數(shù)值來(lái)加速氣候邏輯的執(zhí)行，讓你的刷冰機(jī)快速結(jié)滿(mǎn)冰，也可以將其設(shè)為 0 來(lái)阻止游戲落雷降雪結(jié)冰。由于它的作用范圍是完整的區(qū)塊刻階段，且隨機(jī)刻階段包含于區(qū)塊刻階段中，因此要注意到該規(guī)則數(shù)值的變化是會(huì)同時(shí)影響隨機(jī)刻的作用速度的。你可以將隨機(jī)刻調(diào)為 0 以防止隨機(jī)刻階段占用了過(guò)高的 mspt

實(shí)體速度丟失 (entityMomentumLoss)

將其設(shè)為 false?以關(guān)閉從磁盤(pán)載入時(shí)實(shí)體超過(guò)10m/gt部分的沿軸速度的丟失

對(duì)于實(shí)體而言，在從 nbt 讀取讀取到的速度矢量中，對(duì)于每一坐標(biāo)軸上的速度分量，如果它的絕對(duì)值大于 10 （單位：m/gt）的話，那就將該速度分量置為 0

從 nbt 讀取數(shù)據(jù)這一操作常見(jiàn)于實(shí)體通過(guò)傳送門(mén)跨維度時(shí)，以及加載區(qū)塊讀取儲(chǔ)存著的實(shí)體數(shù)據(jù)時(shí)

對(duì)于珍珠炮而言，是很容易出現(xiàn)發(fā)射出去的珍珠存在大于 10m/gt 的沿軸速度分量的。當(dāng)這一種高速珍珠所在區(qū)塊被卸載的時(shí)候，若重新加載此區(qū)塊，該珍珠對(duì)應(yīng)的沿軸速度分量將會(huì)置零，導(dǎo)致我們不能直觀地看到珍珠的運(yùn)動(dòng)軌跡。這時(shí)候我們就可以通過(guò)本規(guī)則，將這一機(jī)制進(jìn)行暫時(shí)性的抑制處理

實(shí)體同步距離 (entityTrackerDistance)

服務(wù)器同步實(shí)體信息至客戶(hù)端的最大水平切比雪夫距離（單位: 區(qū)塊）?；旧线@就是服務(wù)端的“實(shí)體渲染視距”，不過(guò)這個(gè)距離依舊會(huì)被服務(wù)端視距所約束

將其設(shè)為一個(gè)不小于服務(wù)端視距的數(shù)值，就能令服務(wù)端將玩家視距內(nèi)的所有實(shí)體都同步至客戶(hù)端；將其設(shè)為一個(gè)非正值以使用原版邏輯

需要重新加載區(qū)塊以將新的規(guī)則數(shù)值應(yīng)用到實(shí)體上

服務(wù)器中的每個(gè)實(shí)體被載入游戲時(shí)，服務(wù)器都會(huì)為其分配一個(gè)實(shí)體追蹤器（EntityTracker），用于同步這一實(shí)體的數(shù)據(jù)給玩家。根據(jù)實(shí)體類(lèi)型的不同，實(shí)體追蹤器會(huì)有著不同的同步距離上限以及不同的同步頻率

在 1.15.2 中，實(shí)體追蹤器的默認(rèn)同步距離如下所示：

客戶(hù)端僅能顯示同步范圍內(nèi)的實(shí)體并接受它們的數(shù)據(jù)，超出同步范圍實(shí)體將會(huì)從客戶(hù)端中移出，因此實(shí)體同步間隔可看做服務(wù)端的實(shí)體渲染距離，一個(gè)根據(jù)實(shí)體類(lèi)型而變的實(shí)體渲染距離

要注意實(shí)體同步距離的實(shí)際值會(huì)與服務(wù)端的視距取最小值，這保證了實(shí)體視距總是不會(huì)超過(guò)服務(wù)端的視距

當(dāng)我們想要讓客戶(hù)端能盡可能地顯示出極遠(yuǎn)處的實(shí)體時(shí)，如使用 replay mod 攝像時(shí)，可以修改本規(guī)則，拉高所有實(shí)體的實(shí)體視距。你可以直接將本規(guī)則設(shè)置為一個(gè)足夠大的值（如 64），以此讓實(shí)體視距等同于服務(wù)端視距

實(shí)體同步間隔 (entityTrackerInterval)

服務(wù)器同步實(shí)體信息至客戶(hù)端的時(shí)間間隔（單位: gt）。如果設(shè)為一個(gè)較小的數(shù)值，如 1，服務(wù)器將每 1gt 都同步實(shí)體信息至客戶(hù)端，這能減小客戶(hù)端發(fā)生實(shí)體不同步現(xiàn)象的概率

將其設(shè)為一個(gè)非正值以使用原版邏輯

需要重新加載區(qū)塊以將新的規(guī)則數(shù)值應(yīng)用到實(shí)體上

實(shí)體追蹤器的相關(guān)信息見(jiàn) entityTrackerDistance 的介紹

在 1.15.2 中，實(shí)體追蹤器的默認(rèn)同步周期如下所示：

除非一個(gè)實(shí)體發(fā)生了速度的突變，或者一些重要的數(shù)據(jù)發(fā)生了變化，實(shí)體追蹤器只會(huì)每隔一定時(shí)間才向范圍內(nèi)的玩家發(fā)送相關(guān)的數(shù)據(jù)，而這一間隔則為實(shí)體追蹤器的同步時(shí)間

投擲物、重力方塊、TNT 等實(shí)體有著較大的實(shí)體同步周期，而末影水晶甚至不與客戶(hù)端進(jìn)行信息同步，這導(dǎo)致在設(shè)計(jì)相關(guān)機(jī)器的時(shí)候，客戶(hù)端容易出現(xiàn)實(shí)體運(yùn)動(dòng)與服務(wù)端不同步的情況，這是很煩人的。這時(shí)，你可以使用本規(guī)則將實(shí)體同步間隔設(shè)為 1，讓服務(wù)端每 gt 都同步所有實(shí)體的數(shù)據(jù)，盡可能避免不同步的發(fā)生

爆炸數(shù)據(jù)包廣播范圍 (explosionPacketRange)

設(shè)置在爆炸發(fā)生時(shí)，爆炸數(shù)據(jù)包對(duì)玩家的廣播范圍

在爆炸發(fā)生時(shí)，服務(wù)端僅會(huì)告知離爆點(diǎn) 64m 內(nèi)的玩家，這里發(fā)生了爆炸，而離爆點(diǎn) 64m 范圍外的玩家是見(jiàn)不到爆炸效果的

本規(guī)則的作用即為修改 64m 這一常量，你可以將其調(diào)大以見(jiàn)到更遠(yuǎn)的爆炸，也可以將其調(diào)小來(lái)減輕巨量爆炸時(shí)客戶(hù)端的壓力

禁用物品實(shí)體跳過(guò)移動(dòng)運(yùn)算 (itemEntitySkipMovementDisabled)

移除物品實(shí)體跳過(guò)移動(dòng)運(yùn)算的機(jī)制。改回為 1.13 及以前的物品實(shí)體機(jī)制，也就是低速著地的物品實(shí)體依然會(huì)每 gt 都運(yùn)算移動(dòng)，而非每 4gt

當(dāng)你需要精準(zhǔn)使用物品實(shí)體運(yùn)動(dòng)邏輯時(shí)有用。會(huì)導(dǎo)致利用了相關(guān)機(jī)制的機(jī)器無(wú)法工作，如 2no2name 的無(wú)線紅石

在 1.14+ 中，mojang 為物品實(shí)體引入了一個(gè)新邏輯：當(dāng)物品實(shí)體滿(mǎn)足以下兩種情況

• 物品實(shí)體著地

• 物品實(shí)體水平方向的速度小于等于的平方 >?10^?5m/gt，即水平速度不超過(guò)約 0.063m/s

的時(shí)候，每 4gt 才運(yùn)算一次物品實(shí)體的移動(dòng)邏輯。這雖然能減少在地面上扎堆不動(dòng)物品實(shí)體帶來(lái)的運(yùn)算量，但也會(huì)帶來(lái)一些額外的問(wèn)題：一大堆物品實(shí)體從一個(gè)平臺(tái)落下時(shí)，會(huì)分成 4 批逐批落下，這有時(shí)候會(huì)對(duì)我們的實(shí)驗(yàn)造成影響

本規(guī)則的作用即為移除這一“著地低速物品實(shí)體每 4gt 運(yùn)算一次移動(dòng)”的機(jī)制，讓物品實(shí)體在任何情況下都能每 gt 運(yùn)算一遍移動(dòng)邏輯

光照更新 (lightUpdates)

暫?；蛘呓构庹崭?/p>

• 若被設(shè)為抑制(suppressed)，光照更新不會(huì)被執(zhí)行，這可用于模擬光照抑制器

• 若被設(shè)為忽略(ignored)，光照更新不會(huì)被計(jì)劃，這常用于在創(chuàng)造模式中制造光照錯(cuò)誤

• 若被設(shè)為關(guān)閉(off)，光照更新不會(huì)被計(jì)劃或被執(zhí)行

【警告】：若被設(shè)為抑制或關(guān)閉，新的區(qū)塊將無(wú)法被加載。如果此時(shí)玩家等原因嘗試加載新的區(qū)塊，服務(wù)端將進(jìn)入無(wú)法跳出的死循環(huán)

1.14 后，Minecraft 的光照引擎被重寫(xiě)，服務(wù)端的光照更新被安排至一個(gè)獨(dú)立的光照線程執(zhí)行。Mojang 使用了隊(duì)列來(lái)進(jìn)行主線程與光照線程間的通訊，因此一次光照更新想要執(zhí)行，得先進(jìn)入光照隊(duì)列排隊(duì)等待，等待光照線程將光照隊(duì)列取出并執(zhí)行這一更新

該規(guī)則用于控制原版的光照隊(duì)列，它的四種可能取值對(duì)應(yīng)著下方的行為邏輯表格

POI更新開(kāi)關(guān) (poiUpdates)

方塊變化時(shí)是否會(huì)更新 POI。將其設(shè)為?false?以禁用 POI 更新

POI 的更新是方塊變化流程的最后一步，用于移除舊方塊的 POI 并添加新方塊的 POI。這一操作是可以被更新抑制所抑制的。在創(chuàng)造模式中，如果構(gòu)造 POI 不一致的方塊依然得用到更新抑制器顯然太麻煩了，于是就有了本條規(guī)則

可用于如在 1.15 方便地制作無(wú) POI 的地獄門(mén)方塊

融雪最小亮度 (snowMeltMinLightLevel)

雪片融化所需的最小亮度等級(jí)。在原版里這個(gè)值為 12，意味著雪片將在亮度等級(jí) >= 12時(shí)于隨機(jī)刻中融化

將其設(shè)為 0 以將所有位于你建筑上的煩人的雪片融化；將其設(shè)為與防止降雪的最小亮度等級(jí) (12) 來(lái)方便地測(cè)試你的建筑是否能借助亮度來(lái)防降雪

你可以修改游戲規(guī)則?randomTickSpeed?來(lái)加速雪的融化，也可以修改地毯規(guī)則?chunkTickSpeed?來(lái)加速降雪的過(guò)程

規(guī)則簡(jiǎn)介已經(jīng)描述的很清楚了 XD

結(jié)構(gòu)方塊不保留流體 (structureBlockDoNotPreserveFluid)

結(jié)構(gòu)方塊在放置含水方塊時(shí)，不保留已存在的流體。同時(shí)有著抑制?MC-130584?發(fā)生的副作用

如圖所示

MC-130584?是一個(gè)在結(jié)構(gòu)方塊放置結(jié)構(gòu)的時(shí)候，水會(huì)蔓延至含水方塊里的 bug。它在 1.17 的快照 20w45a 中被修復(fù)。這個(gè)規(guī)則也可以作為 1.17 前對(duì)這一 bug 的補(bǔ)丁

結(jié)構(gòu)方塊范圍限制 (structureBlockLimit)

覆寫(xiě)結(jié)構(gòu)方塊的范圍限制。當(dāng)相對(duì)位置的值大于32時(shí)客戶(hù)端里結(jié)構(gòu)的位置可能會(huì)錯(cuò)誤地顯示

原版結(jié)構(gòu)方塊怎么只有這么一點(diǎn)大小限制？給我改！

fabric carpet 1.4.25 中引入了功能一致的規(guī)則，因此在 MC 1.16 及以后的 Carpet TIS Addition 中該規(guī)則被移除

由于原版的結(jié)構(gòu)方塊數(shù)據(jù)包中使用了 byte 來(lái)儲(chǔ)存結(jié)構(gòu)的大小及偏移，因此在只使用原版協(xié)議的前提下可操作的結(jié)構(gòu)方塊大小最大為 127。fabric-carpet 給出的解決方法是在原版數(shù)據(jù)包末端追加使用 int 儲(chǔ)存的結(jié)構(gòu)大小及偏移，該規(guī)則也同樣地移植了這一實(shí)現(xiàn)

同步光照線程 (synchronizedLightThread)

將光照線程與主線程同步，這樣光照線程就不會(huì)于落后主線程而失去同步。服務(wù)器將會(huì)在每個(gè)世界開(kāi)始運(yùn)算時(shí)等待光照線程的任務(wù)完成。你可以借此安全地?/tick warp?而不用擔(dān)心潛在的光照抑制或光照不同步

在很多時(shí)候，我們寧可服務(wù)端主線程等待光照線程把光照更新執(zhí)行完，也不愿讓光照隊(duì)列堆積導(dǎo)致光照抑制甚至內(nèi)存溢出。本規(guī)則是一簡(jiǎn)單又有效的實(shí)現(xiàn)：在服務(wù)端線程開(kāi)始運(yùn)算一個(gè)維度時(shí)，先等待這一維度的光照線程將隊(duì)列里的更新都處理完，再繼續(xù)處理這一維度的服務(wù)端線程任務(wù)

這一規(guī)則還為 CarpetProfiler 添加了一個(gè)名為?Lighting synchronization?的游戲階段，用于記錄服務(wù)端等待光照線程所造成的額外 mspt。這會(huì)在?/tick health?指令中顯示

計(jì)劃刻上限 (tileTickLimit)

修改每游戲刻中計(jì)劃刻事件的執(zhí)行次數(shù)上限

一個(gè)計(jì)劃刻隊(duì)列每 gt 只會(huì)執(zhí)行最多 65536 個(gè)計(jì)劃刻事件，超出這一限制的計(jì)劃刻事件將被延后至下一個(gè) gt 執(zhí)行。該規(guī)則的作用即為修改這一常量，常用于方便地觸發(fā)/模擬計(jì)劃刻 EMP

TNT引信時(shí)長(zhǎng) (tntFuseDuration)

覆蓋 TNT 的默認(rèn)引信時(shí)長(zhǎng)。這也會(huì)影響被爆炸點(diǎn)燃的 TNT 的引信時(shí)長(zhǎng)

有時(shí)候你想快速地點(diǎn)幾個(gè) TNT 測(cè)試它們的爆炸，你可以借助這一規(guī)則將 TNT 的引信改短，讓它們快速爆炸

有時(shí)候你只想要一個(gè)不會(huì)爆炸的 TNT 實(shí)體來(lái)做實(shí)驗(yàn)，這時(shí)你也可以借助這一規(guī)則將 TNT 的引信加長(zhǎng)，從而生成一個(gè)幾乎不會(huì)爆的任你揉搓的 TNT

注意到在 TNT 實(shí)體保存至/讀取自 nbt 數(shù)據(jù)時(shí)，其 Fuse 標(biāo)簽使用的是 short 數(shù)據(jù)類(lèi)型進(jìn)行儲(chǔ)存，因此 TNT 的引信時(shí)長(zhǎng)最大值為 32767（約 27.3 分鐘），這也足夠長(zhǎng)了

TNT忽略紅石信號(hào) (tntIgnoreRedstoneSignal)

阻止 TNT 被紅石信號(hào)點(diǎn)燃。你仍可以使用爆炸等方式點(diǎn)燃 TNT

在使用原版指令 / WorldEdit 等工具修改移動(dòng)含 TNT 的機(jī)器時(shí)，總有那么些時(shí)候會(huì)不小心誤觸導(dǎo)致其中的 TNT 被點(diǎn)燃。用?totallyNoBlockUpdate?規(guī)則揚(yáng)掉所有更新的副作用又太大，這時(shí)你就需要本規(guī)則，讓 TNT 怎么激活也不會(huì)被點(diǎn)燃了

完全沒(méi)有方塊更新 (totallyNoBlockUpdate)

禁用所有方塊更新以及狀態(tài)更新的執(zhí)行

這條規(guī)則的功能很簡(jiǎn)單：禁止所有方塊更新及狀態(tài)更新的執(zhí)行，常用于使用指令 / WorldEdit 等工具修改移動(dòng)機(jī)器

值得注意的是，除了更新外的其他機(jī)制依然可以正常運(yùn)作，如流體通過(guò)計(jì)劃刻流動(dòng)，比較器檢測(cè)到容器容量變化而更新其狀態(tài)。以及本規(guī)則的作用范圍是整個(gè)服務(wù)器，盲目地開(kāi)啟這一規(guī)則很有可能會(huì)損壞/凍結(jié)住那些一直在運(yùn)行的機(jī)器

禁用海龜?shù)氨慧`踏 (turtleEggTrampledDisabled)

阻止海龜?shù)耙驅(qū)嶓w踩踏而破壞

如規(guī)則描述所述，當(dāng)你想要測(cè)試一個(gè)機(jī)器是否能正確通過(guò)海龜?shù)疤幚斫┦i人，但又暫時(shí)不想考慮海龜?shù)氨徊幻髟虿葔牡臅r(shí)候，你就可以把這條規(guī)則開(kāi)起來(lái)，讓海龜?shù)霸趺床榷疾炔粻€

虛空相對(duì)海拔高度 (voidRelatedAltitude

修改虛空相對(duì)世界底部的海拔高度，此處的虛空指實(shí)體會(huì)受到虛空傷害的區(qū)域

有時(shí)候你想往虛空飛一飛，飛低點(diǎn)得到機(jī)器底部的視角，但又恐 y=-64 虛空傷害直擊創(chuàng)造模式玩家，這時(shí)你可以用這條規(guī)則，把虛空傷害所在的海拔高度閾值調(diào)低，這樣你就可以盡情地在虛空里遨游了

注意該規(guī)則所表示的海拔高度是一個(gè)相對(duì)值，是相對(duì)世界底部 y 值的相對(duì)高度值

禁用凋靈生成音效 (witherSpawnedSoundDisabled)

禁用凋靈在召喚后生命值回滿(mǎn)時(shí)發(fā)出的世界中所有玩家都能聽(tīng)到的音效

凋靈生命值回滿(mǎn)爆炸時(shí)發(fā)出的那一個(gè)聲音全世界都能聽(tīng)到，真的吵死了，快給我關(guān)掉

經(jīng)驗(yàn)球追蹤距離 (xpTrackingDistance)

修改經(jīng)驗(yàn)球檢測(cè)并追蹤玩家的距離。將其調(diào)至 0 以禁用追蹤

當(dāng)你想要在經(jīng)驗(yàn)球管道附近修改東西，但又不想因?yàn)樽约涸诮?jīng)驗(yàn)球附近而擾亂了經(jīng)驗(yàn)球的運(yùn)動(dòng)，你就可以用這條規(guī)則將經(jīng)驗(yàn)球的追蹤給禁用掉。當(dāng)然你也可以把經(jīng)驗(yàn)球的追蹤距離拉到很高，感受經(jīng)驗(yàn)球漫天飛舞最終匯聚于身的體驗(yàn)

生存模式用新增特性/bug修復(fù)

發(fā)射器發(fā)射龍息 (dispensersFireDragonBreath)

發(fā)射器可使用龍息瓶創(chuàng)造出龍息效果云

新特性，讓生存玩家可以在不依賴(lài)末影龍的情況下生成龍息效果云?？膳c規(guī)則?renewableDragonEgg?配合使用

保持弱加載區(qū)塊的怪物 (keepMobInLazyChunks)

弱加載區(qū)塊的怪物不再會(huì)被刷新掉，就像 1.15 之前版本似的。此選項(xiàng)僅對(duì) 1.15 至 1.16 間的版本有效

在 1.15 ~ 1.16 中，位于弱加載區(qū)塊中的生物也會(huì)同位于強(qiáng)加載時(shí)一樣，執(zhí)行離所有玩家 128m 則立即消失的邏輯。這導(dǎo)致了玩家無(wú)法使用存放在弱加載區(qū)塊中的普通怪物制作偽和平裝置

改規(guī)則將生物處理立即消失的邏輯改回了 1.14 及以前的邏輯，讓弱加載區(qū)塊中的生物不會(huì)因?yàn)檫h(yuǎn)離玩家而立即消失

大木桶 (largeBarrel)

史上最棒的物品倉(cāng)儲(chǔ)方塊: 大木桶！兩個(gè)相鄰的底部相連木桶可以組成一個(gè)大木桶，大木桶的行為邏輯跟大箱子相近

箱子能拼成大箱子，儲(chǔ)量大，但它渲染很卡；木桶渲染不卡，但只有小箱子的容量。沒(méi)有兩全其美的儲(chǔ)存容器真是令人糾結(jié)，不過(guò)有了這條規(guī)則后，就可以說(shuō)：我全都要！

底座相連的木桶將組成一個(gè)大木桶，位于坐標(biāo)軸負(fù)方向的木桶作為大木桶的上半部分，位于坐標(biāo)軸正方向的木桶作為大木桶的下半部分

刷鐵軌機(jī)修復(fù) (railDupingFix)

禁用老式的移動(dòng)點(diǎn)亮的充能或激活鐵軌的刷鐵軌機(jī)

這種老式的刷鐵軌機(jī)只對(duì)充能鐵軌 & 激活鐵軌有效，效果如下

修復(fù)方式：在充能鐵軌 & 激活鐵軌更新自身狀態(tài)前先確保這格鐵軌依然存在

可再生龍蛋 (renewableDragonEgg)

讓龍蛋變得可再生：當(dāng)龍蛋處于龍息效果云內(nèi)時(shí)，龍蛋有一定概率吸收龍息并“召喚”出一個(gè)新的龍蛋

可與選項(xiàng)?dispenserFireDragonBreath?聯(lián)動(dòng)

沐浴在龍息中的龍蛋吸收了足夠的能量后，召喚出了一個(gè)新的龍蛋

實(shí)現(xiàn)的具體邏輯：

1. 在隨機(jī)刻選中龍蛋方塊后，龍蛋有 1 / 64 的幾率嘗試再生。這一否決率能保證龍蛋雖然可再生，但仍然是一種較為稀有的物資

2. 龍蛋會(huì)找到與其所在位置 1 立方米范圍相交的龍息效果云。若沒(méi)找到，終止再生流程；否則隨機(jī)挑選一個(gè)效果云

3. 龍蛋會(huì)選擇附近的一個(gè)隨機(jī)位置，嘗試生成龍蛋方塊。選擇位置的邏輯跟龍蛋被點(diǎn)擊后隨機(jī)傳輸?shù)倪壿嬕恢?，不過(guò)僅有一次嘗試機(jī)會(huì)。如果被選中的位置是空氣的話，則龍蛋生成成功，龍息效果云的半徑變?yōu)樵?1 / 5

可再生龍首 (renewableDragonHead)

被高壓爬行者殺死的末影龍將會(huì)掉落一個(gè)龍首

閃電苦力怕的斬首效果怎么能讓末影龍?zhí)舆^(guò)一劫？不過(guò)真要在生存中實(shí)現(xiàn)的話恐怕會(huì)有不小難度

可再生鞘翅 (renewableElytra)

當(dāng)幻翼被潛影貝殺死時(shí)有給定概率掉落鞘翅。設(shè)置為 0 以禁用

需要潛影貝：玩家無(wú)法跳 Minecraft 的科技樹(shù)，必須前往末地城才能拿到鞘翅
涉及幻翼：既然幻翼膜能拿來(lái)修鞘翅，那幻翼膜一定是鞘翅的原材料吧

刷沙機(jī)修復(fù) (sandDupingFix)

禁用使用末地門(mén)的刷沙機(jī)以及刷重力方塊機(jī)。這里的重力方塊包括沙子、鐵砧、龍蛋等。在開(kāi)啟后刷沙機(jī)的沙子將會(huì)僅被傳送至另一個(gè)緯度

末地門(mén)刷沙機(jī)的原理很簡(jiǎn)單：Mojang 在執(zhí)行重力方塊實(shí)體落地轉(zhuǎn)換為方塊的邏輯前，忘了判斷這個(gè)重力方塊是否仍然存在與這個(gè)世界里，結(jié)果就是只要重力方塊在碰到末地門(mén)的同時(shí)落地，就能既前往另一緯度又可以轉(zhuǎn)換為方塊

修復(fù)也很簡(jiǎn)單，把缺失的判斷加上就行了

TNT復(fù)制修復(fù) (tntDupingFix)

禁用TNT、地毯以及部分鐵軌的復(fù)制機(jī)。基于依附性方塊的復(fù)制機(jī)會(huì)無(wú)法復(fù)制，基于紅石原件更新的復(fù)制機(jī)會(huì)無(wú)法保留被復(fù)制的方塊

Dupe bad dig good

這一類(lèi)的方塊復(fù)制均發(fā)生于活塞將所推動(dòng)的方塊一次轉(zhuǎn)換為 b36 的過(guò)程中，根據(jù)更新源的不同可以分為兩種復(fù)制機(jī)：

• 基于依附性方塊掉落而發(fā)出更新的，如死珊瑚更新源。原理為 b36 方塊的放置會(huì)發(fā)出狀態(tài)更新，導(dǎo)致還未被置為 b36 的依附性方塊發(fā)現(xiàn)自己附著于 b36 上，或者依附在空氣上，從而掉落，并發(fā)出更新

• 基于方塊被移除時(shí)發(fā)出更新的，如亮起偵測(cè)器更新源。原理為一些紅石原件（偵測(cè)器、中繼器等）在亮起時(shí)被移除的時(shí)候，會(huì)發(fā)出方塊更新，用于告知附近方塊你的信號(hào)源沒(méi)了

為了修復(fù)這兩種復(fù)制機(jī)，同時(shí)保證不破壞其他的邏輯時(shí)序而保證原版性，我們可以這樣做：

• 使被活塞所推動(dòng)的方塊間接地轉(zhuǎn)換為 b36：

1. 先不發(fā)出任何更新地，將活塞所推動(dòng)方塊的原位置替換為空氣方塊

2. 再讓原版的邏輯將這些空氣方塊轉(zhuǎn)換為 b36

   這保證了生成 b36 的時(shí)候不會(huì)有殘留的方塊作妖

• 在將方塊設(shè)置為空氣之前才把世界里的方塊狀態(tài)儲(chǔ)存進(jìn)活塞推動(dòng)列表中，這樣就算基于方塊被移除時(shí)發(fā)出更新的復(fù)制機(jī)刷出了 TNT，這 TNT 也是真的點(diǎn)著掉了下來(lái)，不再會(huì)被存入活塞推動(dòng)列表里變成 b36

工具化TNT (tooledTNT)

由玩家引發(fā)的爆炸破壞并掉落物品時(shí)會(huì)應(yīng)用玩家手上的工具，因此你可以點(diǎn)燃TNT以采集需要特定工具或者附魔的方塊，只要你在爆炸時(shí)拿著正確的工具。比如，你可以拿著精準(zhǔn)采集鎬子來(lái)采集冰，或者拿著剪刀來(lái)采集草

此規(guī)則同樣適用于玩家以外的生物。技術(shù)上來(lái)講，此規(guī)則將來(lái)源生物主手上的物品應(yīng)用在了爆炸里戰(zhàn)利品表的創(chuàng)建中

精準(zhǔn)采集 TNT，從夢(mèng)想變?yōu)楝F(xiàn)實(shí)——既然都有 TNT 掠奪了，那么為啥不來(lái)一個(gè)TNT 精準(zhǔn)呢

游戲優(yōu)化

優(yōu)化高速實(shí)體移動(dòng) (optimizedFastEntityMovement)

通過(guò)僅檢測(cè)沿軸移動(dòng)方向的方塊碰撞來(lái)優(yōu)化高速實(shí)體的移動(dòng)

受?carpetmod112?的規(guī)則?fastMovingEntityOptimization?啟發(fā)

同規(guī)則?optimizedTNT?一起使用可大幅度提升炮的性能表現(xiàn)

在實(shí)體移動(dòng)的過(guò)程中，原版游戲會(huì)獲取實(shí)體速度矢量構(gòu)成的長(zhǎng)方體中所有能阻擋其移動(dòng)的碰撞箱

如上圖所示，TNT 從右下移動(dòng)至左上，游戲會(huì)獲取圖中白色染色玻璃范圍的所有碰撞箱

由于實(shí)體實(shí)際上是沿軸分步移動(dòng)的，這個(gè)長(zhǎng)方體中中并非所有數(shù)據(jù)都是我們需要的，只有實(shí)體沿軸移動(dòng)路徑上的碰撞箱有可能阻擋實(shí)體移動(dòng)（上圖紅色玻璃），因此我們可以?xún)H獲得這條路徑上的碰撞箱，而非獲取整個(gè)長(zhǎng)方體中的碰撞箱

在與 TNT 炮相關(guān)的機(jī)器中，TNT 的速度往往會(huì)被加速到極大值，又因?yàn)殚L(zhǎng)方體的體積隨實(shí)體速度大小立方級(jí)地增長(zhǎng)，TNT 速度提上去之后帶來(lái)的卡頓會(huì)急劇升高。在使用本規(guī)則進(jìn)行優(yōu)化后，所需要掃描的碰撞箱范圍體積變?yōu)榕c實(shí)體速度大小線性增長(zhǎng)，能非常有效地緩解這部分的卡頓

優(yōu)化硬碰撞箱實(shí)體碰撞 (optimizedHardHitBoxEntityCollision)

優(yōu)化實(shí)體與硬碰撞箱實(shí)體的碰撞

它使用了一個(gè)額外的獨(dú)立的列表在區(qū)塊中儲(chǔ)存帶有硬碰撞箱的實(shí)體，包括船和潛影貝。它能在實(shí)體移動(dòng)并搜索路徑上的帶有硬碰撞箱的實(shí)體時(shí)減少大量無(wú)用的運(yùn)算，因?yàn)槭澜缋锎蜐撚柏惖臄?shù)量總是少數(shù)

在加載區(qū)塊前開(kāi)啟它以使其工作，在地獄門(mén)刷怪塔中有~20%的性能提升。

與添加了新實(shí)體的 mod 可能不兼容

實(shí)體移動(dòng)時(shí)，需要搜尋其移動(dòng)路徑上所有能阻擋其移動(dòng)的碰撞箱對(duì)象，這包括方塊以及帶有硬碰撞箱的實(shí)體（對(duì)非礦車(chē)的實(shí)體而言，為船和潛影貝），然后計(jì)算它們對(duì)實(shí)體移動(dòng)的阻擋效果

搜尋帶有硬碰撞箱的實(shí)體的實(shí)現(xiàn)是，遍歷一遍范圍內(nèi)所有區(qū)段中的所有實(shí)體，然后將其中具有硬碰撞箱的實(shí)體提取出來(lái)。如果范圍內(nèi)的實(shí)體數(shù)量非常多，這部分遍歷將會(huì)非常耗時(shí)，即便這個(gè)范圍內(nèi)幾乎沒(méi)有硬碰撞箱的實(shí)體。這種情況常出現(xiàn)于雙維度刷怪塔的怪物處理維度端，其中有著大量刷出的怪物，但卻幾乎沒(méi)有船跟潛影貝

該優(yōu)化使用了一個(gè)獨(dú)立的列表來(lái)儲(chǔ)存含硬碰撞箱的實(shí)體，這樣在需要于區(qū)段中搜索硬碰撞箱實(shí)體時(shí)就不用遍歷整個(gè)包含所有實(shí)體的列表了，可以有效地減少這部分遍歷的耗時(shí)

Lithium 模組在 v0.5.5 后也加入了類(lèi)似的優(yōu)化，位于?chunk.entity_class_groups?中

TNT優(yōu)化高優(yōu)先級(jí) (optimizedTNTHighPriority)

用帶有更高優(yōu)先級(jí)的 Mixin 注入來(lái)實(shí)現(xiàn) carpet 規(guī)則?，因此規(guī)則?optimizedTNT?可以覆蓋 lithium 的爆炸優(yōu)化

當(dāng)然，它需要規(guī)則?optimizedTNT?開(kāi)啟才能工作

fabric carpet 的爆炸優(yōu)化有著實(shí)體接觸率射線計(jì)算結(jié)果緩存的功能，這是 lithium 的爆炸優(yōu)化所不具有的，

在默認(rèn)情況下，lithium 的爆炸優(yōu)化是會(huì)覆蓋掉 fabric carpet 的爆炸優(yōu)化的，兩者無(wú)法共存。當(dāng)你想使用 fabric carpet 的爆炸優(yōu)化，而非 lithium 的爆炸優(yōu)化的時(shí)候，即可啟用本規(guī)則

Lithium 模組在 v0.6.2 后修改了其爆炸優(yōu)化的實(shí)現(xiàn)，據(jù)其稱(chēng)這些修改能提升 lithium 的爆炸優(yōu)化與其他修改爆炸的模組的兼容性。本規(guī)則與 lithium v0.6.2+ 的組合效果仍有待測(cè)試

其他規(guī)則

禁用反刷屏監(jiān)測(cè) (antiSpamDisabled)

禁用玩家身上的刷屏檢測(cè)，包括：聊天信息發(fā)送冷卻、創(chuàng)造模式扔物品冷卻

在原版游戲中，若非 OP 玩家發(fā)消息 / 指令發(fā)的過(guò)快，會(huì)被因刷屏而踢出游戲；創(chuàng)造模式中從創(chuàng)造模式物品欄扔物品是有速度上限的，超過(guò)上限了只能以一秒一個(gè)物品的速度扔出物品

這些限制對(duì)于服務(wù)器成員遵紀(jì)守法的服務(wù)器而已顯然只能提供煩人的作用，不如用這條規(guī)則將它揚(yáng)了吧

存活時(shí)間追蹤器 (commandLifetime)

啟用?/lifetime?命令用于追蹤生物存活時(shí)間等信息?？芍谡{(diào)試刷怪塔等

/lifetime?存活時(shí)間追蹤器指令的開(kāi)關(guān)及其權(quán)限控制

世界控制命令開(kāi)關(guān) (commandManipulate)

啟用?/manipulate?命令用于控制世界

/manipulate?指令的開(kāi)關(guān)及其權(quán)限控制

襲擊追蹤器 (commandRaid)

啟用?/raid?命令用于列出或追蹤襲擊信息

/raid?指令的開(kāi)關(guān)及其權(quán)限控制

刷新命令開(kāi)關(guān) (commandRefresh)

啟用?/refresh?命令讓你的客戶(hù)端與服務(wù)端保持同步

/refresh?指令的開(kāi)關(guān)及其權(quán)限控制

假人名稱(chēng)前綴 (fakePlayerNamePrefix)

為?/player?指令召喚出來(lái)的假人名稱(chēng)添加指定前綴

將其設(shè)置為?#none?以阻止添加前綴

這可阻止玩家召喚奇怪名字的假人，還能讓玩家列表變得更整潔

讓所有的假人均統(tǒng)一帶有?bot_?什么的前綴，是非常令人舒適且便于管理的

如果輸入的假人的名字已含給定前綴，召喚出來(lái)的假人名字則不會(huì)重復(fù)添加前綴

假人名稱(chēng)后綴 (fakePlayerNameSuffix)

為?/player?指令召喚出來(lái)的假人名稱(chēng)添加指定后綴

將其設(shè)置為?#none?以阻止添加后綴

類(lèi)似?fakePlayerNamePrefix，不過(guò)本條規(guī)則添加的是后綴

HUD記錄器更新間隔 (HUDLoggerUpdateInterval)

覆寫(xiě) Carpet Mod HUD 記錄器的更新間隔，單位為 gametick

在 fabric carpet 的框架中，位于 tab 欄玩家列表下方的 HUD 記錄器的更新間隔是一個(gè)定值，20gt 定值。如果我們想要更高頻率地刷新 HUD 記錄器的信息刷，就可以使用本規(guī)則來(lái)修改這個(gè)間隔

存活時(shí)間追蹤器考慮怪物容量 (lifetimeTrackerConsidersMobcap)

存活時(shí)間追蹤器對(duì)不占怪物容量的生物的策略

• true: 不追蹤不占用怪物容量的生物，并與生物不影響怪物容量的時(shí)刻將其標(biāo)記為已移除，如當(dāng)它們撿起物品時(shí)。便于設(shè)計(jì)刷怪塔

• false: 追蹤所有可追蹤的生物，在生物確實(shí)被刪除時(shí)將其標(biāo)記為已移除。便于設(shè)計(jì)襲擊農(nóng)場(chǎng)或非刷怪塔的機(jī)器

存活時(shí)間追蹤器所使用的的一個(gè)參數(shù)

光照隊(duì)列記錄器采樣時(shí)長(zhǎng) (lightQueueLoggerSamplingDuration)

光照隊(duì)列記錄器的采樣時(shí)長(zhǎng)，單位為游戲刻。影響記錄器中顯示的，除隊(duì)列大小外的所有數(shù)據(jù)

光照隊(duì)列記錄器（lightQueue）所使用的的一個(gè)參數(shù)

怪物容量顯示忽略雜項(xiàng) (mobcapsDisplayIgnoreMisc)

在 carpet 怪物容量顯示中忽略雜項(xiàng) (misc) 這一生物類(lèi)型

因?yàn)樗日伎臻g還沒(méi)用：雜項(xiàng)生物類(lèi)型不參與刷怪循環(huán)，在統(tǒng)計(jì)怪物容量時(shí)也被游戲忽略

影響 mobcaps 記錄器以及?/spawn mobcaps?指令

占空間還沒(méi)用的數(shù)據(jù)，當(dāng)然是選擇刪掉啦

op玩家不準(zhǔn)作弊 (opPlayerNoCheat)

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

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

在擁有 OP 權(quán)限的情況下有時(shí)候會(huì)不小心誤觸到一些作弊的快捷鍵，包括：

• 原版的 F3 + N、F3 +F4 切換游戲模式（/gamemode）

• 小地圖模組里的選點(diǎn)傳送（/tp、/teleport）

• JEI 等物品列表顯示模組中的物品給予（/give）

• 投影模組粘貼原理圖的方塊放置與實(shí)體召喚（/setblock、/summon）

雖說(shuō)是無(wú)意觸發(fā)的，但總會(huì)煩人，不如直接禁掉這些指令，不準(zhǔn)這些指令給任何玩家執(zhí)行。這也正是本條規(guī)則的功能

當(dāng)然如果你真的需要使用這些被禁用指令的話，把本條規(guī)則關(guān)閉即可

持久性記錄器訂閱 (persistentLoggerSubscription)

在服務(wù)器重啟后依然記憶著玩家訂閱的記錄器及記錄器選項(xiàng)

僅在玩家首次登錄時(shí)應(yīng)用 carpet 的?defaultLoggers?規(guī)則

記錄器訂閱儲(chǔ)存于?config/carpettisaddition/logger_subscriptions.json?中

雖說(shuō) fabric carpet 有著一個(gè)叫?defaultLoggers?的規(guī)則，讓玩家上線后可以自動(dòng)訂閱一些記錄器，但單一一個(gè)規(guī)則顯然不能滿(mǎn)足每名玩家的個(gè)性化自定義需求

換個(gè)角度想想，只要我們記憶著玩家所訂閱的記錄器，以及記錄器的選項(xiàng)，并在玩家下次登錄時(shí)自動(dòng)回復(fù)訂閱，不僅能避免玩家每次上線時(shí)都得重新訂閱的繁瑣，還能滿(mǎn)足每名玩家的個(gè)性化訂閱需求

可視化投擲物記錄器 (visualizeProjectileLoggerEnabled)

啟用可視化投擲物記錄器。試試?/log projectiles visualize?吧

為投擲物每游戲刻所在位置，以及投擲物的撞擊點(diǎn)，召喚一個(gè)固定的不與紅石交互的雪球，指示投擲物的運(yùn)動(dòng)軌跡