寫模組到現(xiàn)在第三十九篇終于該碰真正的核心機(jī)制了。前面幾篇基本都在和Block、Item、模型這些靜態(tài)的東西打交道而這一篇要講的TileEntity本質(zhì)上就是讓方塊“活”過來的關(guān)鍵——它可以讓一個(gè)方塊擁有自己的數(shù)據(jù)、自己的狀態(tài)、自己的運(yùn)行邏輯。我用“反應(yīng)器”這個(gè)名字來作為載體是因?yàn)檫@類“機(jī)器型方塊”幾乎包含了一個(gè)TileEntity能遇到的所有問題內(nèi)部要存物品輸入槽、輸出槽、燃料槽要有處理進(jìn)度要和服務(wù)端邏輯配合還要把進(jìn)度同步到客戶端讓玩家在界面上看到進(jìn)度條在動(dòng)。能把反應(yīng)器做出來就等于掌握了模組開發(fā)里最常用的一類方塊實(shí)體。這篇文章會(huì)從需求拆解開始把注冊(cè)、NBT存儲(chǔ)、服務(wù)端tick邏輯、數(shù)據(jù)同步、渲染方案全部過一遍最后一節(jié)是我實(shí)際踩過的一些坑照著做就能繞開。1. 先用需求倒推反應(yīng)器的核心難點(diǎn)其實(shí)只有三點(diǎn)1.1 為什么必須引入TileEntityBlockState搞不定的三件事先回答一個(gè)很多人剛接觸時(shí)都會(huì)問的問題做個(gè)反應(yīng)器直接用一個(gè)Block類不行嗎答案是不行至少做不出真正意義上的“反應(yīng)器”。原因有三條。第一是狀態(tài)存儲(chǔ)。BlockState在1.12.2里的本質(zhì)是方塊自身屬性的組合它存在世界里的時(shí)候只是一組Property和對(duì)應(yīng)的值沒法塞進(jìn)去一個(gè)ItemStack數(shù)組?？煞磻?yīng)器內(nèi)部要存燃料、原料、產(chǎn)物這是典型的多檔位物品存儲(chǔ)只有TileEntity能在世界數(shù)據(jù)里單獨(dú)掛一塊NBT給它存這些內(nèi)容。第二是運(yùn)行邏輯。BlockState沒有tick方法當(dāng)然1.12.2里可以給方塊設(shè)置setTickRandomly但那只能做非常稀疏的隨機(jī)刻用來跑“每200tick燒一次燃料”這種流程別說手感不對(duì)實(shí)際表現(xiàn)也會(huì)非常奇怪。真正穩(wěn)定的做法是讓TileEntity實(shí)現(xiàn)ITickable每個(gè)游戲刻都被服務(wù)端調(diào)用一次update。第三是數(shù)據(jù)同步?？蛻舳说哪Ｐ鸵鶕?jù)工作狀態(tài)變化GUI界面要顯示當(dāng)前進(jìn)度這些都需要一個(gè)能被服務(wù)器主動(dòng)推送數(shù)據(jù)、客戶端能讀取解析的實(shí)體BlockState只靠IBlockState里的Property做不了這么細(xì)致的數(shù)據(jù)流通。打個(gè)比方Block是“外表”TileEntity是“內(nèi)臟”。外表可以換顏色、換朝向但里面的血液、呼吸、心跳這些數(shù)據(jù)信息必須要內(nèi)臟來管理。1.2 反應(yīng)器的功能定義輸入槽、輸出槽、燃料與進(jìn)度在動(dòng)手寫代碼之前先把這臺(tái)“反應(yīng)器”到底做什么定義清楚。我把它設(shè)計(jì)成一個(gè)基礎(chǔ)冶煉機(jī)器有兩個(gè)輸入槽一個(gè)是燃料槽比如煤炭一個(gè)是原料槽比如鐵錠一個(gè)輸出槽。反應(yīng)器會(huì)消耗燃料將原料轉(zhuǎn)化為產(chǎn)物同時(shí)積累一個(gè)進(jìn)度值。考慮到系列文章的內(nèi)容密度我決定這期不寫GUI只把TileEntity的核心邏輯、數(shù)據(jù)存儲(chǔ)、同步和模型狀態(tài)做完整。沒有GUI并不影響學(xué)習(xí)TileEntity因?yàn)門ileEntity本身的數(shù)據(jù)鏈和交互鏈?zhǔn)仟?dú)立于GUI的。GUI在下一期再單獨(dú)展開那一篇會(huì)引入Container和Slot的完整體系。這里要用到的技術(shù)點(diǎn)包括Block的hasTileEntity與createNewTileEntity方法、TileEntity的readFromNBT與writeToNBT、ITickable接口、IInventory接口讓Reactable可以被管道、漏斗等外部系統(tǒng)理解、服務(wù)端到客戶端的同步通道。如果這些詞你現(xiàn)在看著還發(fā)懵問題不大接下來每一個(gè)我都會(huì)給出完整的代碼和解釋。2. 從Block到TileEntity的注冊(cè)鏈路少了哪一步都不行2.1 注冊(cè)TileEntityGameRegistry與createNewTileEntity的配合TileEntity不是一個(gè)獨(dú)立的注冊(cè)對(duì)象它必須依附在Block上。你在游戲里放置一個(gè)方塊游戲才會(huì)根據(jù)這個(gè)方塊對(duì)應(yīng)的TileEntity類在內(nèi)存中new一個(gè)實(shí)體出來再綁定到那個(gè)BlockPos坐標(biāo)上。在1.12.2 Forge里第一步是用GameRegistry.registerTileEntity注冊(cè)類與ID的映射關(guān)系。注意這里的ID是字符串要和TileEntity類綁在一起并且只在服務(wù)端注冊(cè)一次即可。通常會(huì)寫在Mod主類或者一個(gè)專門放注冊(cè)邏輯的類里我習(xí)慣放在一個(gè)RegistryHandler類中。public class RegistryHandler { public static void registerTileEntities() { GameRegistry.registerTileEntity(TileEntityReactor.class, reactor_te); } }一個(gè)很容易被忽略的細(xì)節(jié)注冊(cè)用的key不要用中文也不要太長。它會(huì)被寫進(jìn)存檔如果你以后改了key舊存檔里的區(qū)塊加載時(shí)就會(huì)找不到對(duì)應(yīng)的TileEntity類直接崩檔或者丟數(shù)據(jù)。所以命名一定要穩(wěn)定類似reactor_te這種短字符串最穩(wěn)妥。第二步最關(guān)鍵在Block類里重寫兩個(gè)方法Override public boolean hasTileEntity(IBlockState state) { return true; } Override public TileEntity createNewTileEntity(World world, int metadata) { return new TileEntityReactor(); }這兩個(gè)方法缺一不可。hasTileEntity決定這個(gè)方塊在放置時(shí)要不要附帶創(chuàng)建實(shí)體createNewTileEntity就是創(chuàng)建的具體邏輯。很多新手只寫了hasTileEntity就迫不及待進(jìn)游戲測(cè)試結(jié)果放置的方塊完全沒有數(shù)據(jù)存儲(chǔ)能力查了半天發(fā)現(xiàn)是createNewTileEntity沒實(shí)現(xiàn)。2.2 方塊注冊(cè)、模型綁定與掉落處理的連帶改動(dòng)Block本身還是要正常注冊(cè)的和前面的基礎(chǔ)方塊一樣setRegistryName、setUnlocalizedName、加到創(chuàng)造模式物品欄、注冊(cè)ModelLoader資源。這些內(nèi)容在系列前面已經(jīng)寫過這里就不重復(fù)貼代碼了只強(qiáng)調(diào)幾個(gè)和TileEntity相關(guān)的連帶改動(dòng)。第一如果你用了物品欄里的方塊物品要確保在客戶端注冊(cè)對(duì)應(yīng)的Item模型否則放置后模型可能變紫黑色。這屬于老生常談但在加了TileEntity之后容易忘。第二方塊被破壞時(shí)TileEntity里的物品不會(huì)自動(dòng)掉出來。你必須在breakBlock方法里自己處理掉落邏輯否則玩家用鎬子挖掉反應(yīng)器里面的燃料和產(chǎn)物會(huì)直接蒸發(fā)。Override public void breakBlock(World world, BlockPos pos, IBlockState state) { TileEntity tileEntity world.getTileEntity(pos); if (tileEntity instanceof TileEntityReactor) { TileEntityReactor reactor (TileEntityReactor) tileEntity; for (int i 0; i reactor.getSizeInventory(); i) { ItemStack stack reactor.getStackInSlot(i); if (!stack.isEmpty()) { spawnAsEntity(world, pos, stack); } } } super.breakBlock(world, pos, state); }這里用的是Forge提供的spawnAsEntity方法它負(fù)責(zé)在指定位置生成一個(gè)物品實(shí)體。注意循環(huán)里要先判斷stack是否為空1.11以后ItemStack不允許出現(xiàn)Item為null的實(shí)例一律用ItemStack.EMPTY來表示空槽位判斷方法就是isEmpty()。還有一個(gè)偏門但很重要的方法叫eventReceived它和Block與TileEntity之間的客戶端事件通信有關(guān)。比如你想在客戶端播放音效、粒子效果時(shí)可以通過world.addBlockEvent觸發(fā)最終會(huì)調(diào)用到這個(gè)方法并轉(zhuǎn)發(fā)給TileEntity的receiveClientEvent。1.12.2里很多機(jī)器型方塊會(huì)重寫它來實(shí)現(xiàn)“敲一下發(fā)個(gè)信號(hào)”的交互反應(yīng)器這版先不涉及但你要知道有這個(gè)東西存在。3. 核心實(shí)現(xiàn)讓TileEntity自己動(dòng)起來的完整代碼3.1 TileEntityReactor的字段設(shè)計(jì)與生命周期現(xiàn)在進(jìn)入正題。TileEntityReactor需要繼承TileEntity然后實(shí)現(xiàn)ITickable和IInventory。ITickable提供update方法IInventory提供物品操作相關(guān)接口。字段設(shè)計(jì)上我習(xí)慣把所有需要持久化的數(shù)據(jù)放到一起方便寫NBTpublic class TileEntityReactor extends TileEntity implements ITickable, IInventory { private ItemStack[] inventory new ItemStack[2]; private int progress 0; private static final int MAX_PROGRESS 200; private ItemStack fuelStack; private ItemStack materialStack; public TileEntityReactor() { for (int i 0; i inventory.length; i) { inventory[i] ItemStack.EMPTY; } } }我這里故意用了一個(gè)獨(dú)立的ItemStack[]數(shù)組而不是直接用兩個(gè)單獨(dú)的字段。為什么因?yàn)镮Inventory接口要求按槽位索引訪問一個(gè)數(shù)組能讓你寫循環(huán)遍歷、判斷空槽位、實(shí)現(xiàn)自動(dòng)注入邏輯時(shí)都方便很多后續(xù)做漏斗交互、管道連接時(shí)優(yōu)勢(shì)更明顯。數(shù)組長度為20號(hào)槽放燃料1號(hào)槽放原料。實(shí)際上你完全可以擴(kuò)展成3個(gè)、4個(gè)甚至用List管理動(dòng)態(tài)槽位。進(jìn)度值progress是處理進(jìn)度的核心數(shù)值每次update會(huì)增加達(dá)到MAX_PROGRESS時(shí)觸發(fā)一次產(chǎn)出。MAX_PROGRESS200意味著大概10秒完成一次處理1.12.2的tick是每秒20次。這是一個(gè)很“手感化”的參數(shù)需要根據(jù)你的機(jī)器定位調(diào)整。如果希望反應(yīng)器是一個(gè)前期工具200剛好如果希望它是中后期才能效率化使用的設(shè)備可以抬高到400甚至更高。TileEntity的生命周期里有三個(gè)時(shí)刻最值得注意放置時(shí)構(gòu)造、每個(gè)tick被update調(diào)用、被保存或加載時(shí)執(zhí)行readFromNBT/writeToNBT。構(gòu)造時(shí)把數(shù)組所有槽位初始化成ItemStack.EMPTY可以避免很多空指針問題這個(gè)習(xí)慣從第一天寫TileEntity就要養(yǎng)成。3.2 核心update與配方判斷服務(wù)端主循環(huán)的寫法update方法是整個(gè)TileEntity的心臟也是最容易寫出性能問題的地方。第一行永遠(yuǎn)是判斷客戶端因?yàn)門ileEntity的tick邏輯必須在服務(wù)端執(zhí)行客戶端只需要被動(dòng)接收同步數(shù)據(jù)。如果客戶端也跑了這套邏輯就會(huì)出現(xiàn)兩邊數(shù)據(jù)不一致進(jìn)度條抽風(fēng)甚至服務(wù)端把客戶端數(shù)據(jù)覆蓋掉的嚴(yán)重bug。Override public void update() { if (world.isRemote) { return; } boolean needSync false; if (canProcess()) { if (fuelStack.isEmpty() || fuelStack.getCount() 0) { // 沒燃料試著從燃料槽拿一組進(jìn)來 if (!inventory[0].isEmpty()) { fuelStack inventory[0].splitStack(1); needSync true; } } if (!fuelStack.isEmpty() !materialStack.isEmpty()) { progress; if (progress MAX_PROGRESS) { processResult(); progress 0; needSync true; } } else { progress 0; } } else { progress 0; } if (needSync || progress 0) { markDirty(); } if (needSync) { world.notifyBlockUpdate(pos, world.getBlockState(pos), world.getBlockState(pos), 3); } }canProcess方法負(fù)責(zé)判斷當(dāng)前是否滿足處理?xiàng)l件private boolean canProcess() { return !inventory[0].isEmpty() !inventory[1].isEmpty(); }這里簡化了“什么能當(dāng)燃料、什么能當(dāng)原料”的判定。實(shí)際項(xiàng)目里我會(huì)建議單獨(dú)寫一個(gè)方法比如isFuel(ItemStack)來判斷物品是否屬于燃料列表而原料則對(duì)應(yīng)一套配方表。配方表可以用MapItemStack, ItemStack或者更工程化的Recipe對(duì)象來實(shí)現(xiàn)。本篇為了聚焦TileEntity本身先用“非空即可處理”的邏輯占位后續(xù)加配方系統(tǒng)時(shí)只需替換canProcess和processResult內(nèi)部實(shí)現(xiàn)其他部分完全不用動(dòng)。processResult負(fù)責(zé)一個(gè)周期結(jié)束后真正“產(chǎn)出”什么東西private void processResult() { ItemStack result new ItemStack(Items.DIAMOND); // 示意實(shí)際應(yīng)該按配方產(chǎn)出 inventory[0].shrink(1); inventory[1].shrink(1); inventory[2] result.copy(); fuelStack inventory[0]; materialStack inventory[1]; }這里有一個(gè)編程細(xì)節(jié)inventory[0].shrink(1)會(huì)就地減少堆疊數(shù)量但1.12.2里ItemStack是不可變對(duì)象shrink會(huì)返回一個(gè)新的棧所以更穩(wěn)妥的寫法是把shrink的結(jié)果重新賦值給原槽位。很多老教程里的stackSize--在新版MCP映射下已經(jīng)不可用了。我實(shí)際寫的時(shí)候更喜歡這樣inventory[0] inventory[0].splitStack(inventory[0].getCount() - 1); if (inventory[0].getCount() 0) { inventory[0] ItemStack.EMPTY; }看起來啰嗦但它能保證任何情況下槽位都不會(huì)出現(xiàn)“只剩一個(gè)空ItemStack對(duì)象但還沒變成EMPTY”的隱患。3.3 IInventory接口讓漏斗和其他Mod認(rèn)識(shí)你的機(jī)器為什么一定要實(shí)現(xiàn)IInventory因?yàn)檫@等于給你的TileEntity定了一套標(biāo)準(zhǔn)通信協(xié)議。原版的漏斗、投擲器、其他模組的自動(dòng)化管道都通過IInventory來讀取和寫入物品。你只要實(shí)現(xiàn)這個(gè)接口反應(yīng)器天然就能被原版漏斗自動(dòng)供料這個(gè)效果會(huì)讓人非常有成就感。IInventory在1.12.2里有一堆方法除了必須返回?cái)?shù)組長度、判斷空、獲取槽位物品之外還有decrStackSize、setInventorySlotContents、markDirty、isUsableByPlayer等。寫的時(shí)候我沒必要全貼但有兩個(gè)方法值得單獨(dú)說。第一個(gè)是isItemValidForSlot(int index, ItemStack stack)它決定哪些槽位可以接收哪些物品。我建議在0號(hào)槽只接收燃料1號(hào)槽接收原料。這樣漏斗嘗試自動(dòng)輸入時(shí)不會(huì)把鐵錠塞到燃料管里。Override public boolean isItemValidForSlot(int index, ItemStack stack) { if (index 0) { return isFuel(stack); } else if (index 1) { return isMaterial(stack); } return false; }第二個(gè)是markDirty()。每次物品數(shù)量變化、進(jìn)度變化、狀態(tài)變化時(shí)都要調(diào)用它作用是把TileEntity標(biāo)記為“臟”提示存檔系統(tǒng)在合適的時(shí)間保存數(shù)據(jù)。漏寫markDirty的典型癥狀是服務(wù)端邏輯正常但區(qū)塊保存后重啟游戲物品或進(jìn)度回到舊狀態(tài)。IInventory接口里還有setField和getField這兩個(gè)在配合GUI的Container做進(jìn)度條同步時(shí)特別有用。1.12.2的Container里IPC通過getField讀取數(shù)值、setField寫入數(shù)值從而實(shí)現(xiàn)客戶端和服務(wù)端的整數(shù)同步。我這一期的代碼里沒寫GUI但這兩個(gè)方法還是要實(shí)現(xiàn)留好擴(kuò)展位下一期做GUI時(shí)直接就能用。4. 數(shù)據(jù)同步原理解決進(jìn)度條不動(dòng)、界面上數(shù)值不對(duì)4.1 三條同步通道的職責(zé)劃分加載、更新、渲染TileEntity的數(shù)據(jù)同步是新手最容易翻車的地方因?yàn)檫@里涉及三條完全不同的通道每一條都對(duì)應(yīng)不同的游戲階段。第一條是區(qū)塊加載同步。當(dāng)玩家走進(jìn)一個(gè)已加載的區(qū)塊時(shí)客戶端需要知道這個(gè)區(qū)塊里所有TileEntity的完整狀態(tài)。每條通道都由一個(gè)核心方法負(fù)責(zé)getUpdateTag讀寫出用于同步的完整的NBT數(shù)據(jù)然后通過SPacketUpdateTileEntity發(fā)送。這條通道會(huì)調(diào)用getUpdatePacket和onDataPacket方法。第三條是區(qū)塊渲染同步。當(dāng)客戶端開始渲染一個(gè)區(qū)塊時(shí)它不會(huì)直接拉取服務(wù)端的所有數(shù)據(jù)而是依賴服務(wù)端在方塊狀態(tài)變化、TileEntity狀態(tài)變化時(shí)主動(dòng)推送。實(shí)際開發(fā)中最常用到的就是第二條方塊更新同步。在服務(wù)端改變進(jìn)度、改變工作狀態(tài)后調(diào)用world.notifyBlockUpdate就可以觸發(fā)一次客戶端更新。這個(gè)方法的第三個(gè)參數(shù)是flags推薦用3表示同時(shí)通知鄰居更新和自身更新。4.2 讓進(jìn)度條動(dòng)起來的標(biāo)準(zhǔn)做法三次強(qiáng)調(diào)nottifyBlockUpdate進(jìn)度條動(dòng)不起來或者整個(gè)工作方的模型不隨狀態(tài)切換改變通常都是同一個(gè)原因服務(wù)端改了數(shù)據(jù)但沒通知客戶端。我處理這類問題有個(gè)標(biāo)準(zhǔn)三步走。第一步服務(wù)端邏輯里修改關(guān)鍵字段后立即markDirty保證之后區(qū)塊保存不丟數(shù)據(jù)。第二步調(diào)用world.notifyBlockUpdate(pos, state, state, 3)主動(dòng)通知客戶端這個(gè)坐標(biāo)的方塊狀態(tài)需要刷新。第三步在TileEntity里實(shí)現(xiàn)getUpdatePacket方法返回一個(gè)SPacketUpdateTileEntity同時(shí)在onDataPacket里把收到的NBT讀取回來。三件事配合才是一條完整的數(shù)據(jù)同步鏈路。Override public NBTTagCompound getUpdateTag() { return writeToNBT(new NBTTagCompound()); } Nullable Override public SPacketUpdateTileEntity getUpdatePacket() { return new SPacketUpdateTileEntity(pos, 1, getUpdateTag()); } Override public void onDataPacket(NetworkManager net, SPacketUpdateTileEntity pkt) { readFromNBT(pkt.getNbtCompound()); world.markBlockRangeForRenderUpdate(pos, pos); }很多新手只實(shí)現(xiàn)了getUpdateTag忘了getUpdatePacket。結(jié)果就是打開存檔時(shí)能讀到正確數(shù)據(jù)但游戲運(yùn)行中客戶端拿不到變化進(jìn)度條自然不動(dòng)。記住getUpdateTag負(fù)責(zé)“首次加載時(shí)同步全量數(shù)據(jù)”getUpdatePacket負(fù)責(zé)“運(yùn)行中主動(dòng)推送更新”兩者都要有。onDataPacket里的最后一行也不可省略。readFromNBT只是把數(shù)據(jù)寫回TileEntity字段但客戶端渲染層并不知道數(shù)據(jù)變了。markBlockRangeForRenderUpdate會(huì)主動(dòng)標(biāo)臟渲染區(qū)域讓客戶端重新構(gòu)建這一段的渲染狀態(tài)。沒有這行模型切換有時(shí)就會(huì)卡在舊狀態(tài)上玩家的體感就是“反應(yīng)器一直在工作但外觀一直顯示待機(jī)”。5. 渲染方案進(jìn)度條與工作動(dòng)畫怎么做才不卡5.1 方案一用getActualState做多態(tài)模型推薦1.12.2里做機(jī)器工作狀態(tài)的渲染最常用也最推薦的做法是讓TileEntity的狀態(tài)驅(qū)動(dòng)IBlockState的Property。具體思路是在Block類里定義一個(gè)PropertyBool類型的working屬性重寫getActualState方法時(shí)查詢?cè)撟鴺?biāo)的TileEntity運(yùn)行狀態(tài)把working設(shè)置為true或false。public static final PropertyBool WORKING PropertyBool.create(working); Override public IBlockState getActualState(IBlockState state, IBlockAccess world, BlockPos pos) { TileEntity te world.getTileEntity(pos); boolean working false; if (te instanceof TileEntityReactor) { working ((TileEntityReactor) te).isWorking(); } return state.withProperty(WORKING, working); }isWorking方法可以從TileEntity內(nèi)部狀態(tài)來定義比如燃料槽和原料槽都不為空或者progress 0。我建議用progress 0這個(gè)判定因?yàn)樗鎸?shí)地反映了“正在處理進(jìn)度中”的語義。然后你需要給這個(gè)方塊準(zhǔn)備兩個(gè)JSON模型文件分別對(duì)應(yīng)workingtrue和workingfalse。通過blockstate JSON里的multipart規(guī)則把方塊在working不同取值下用不同模型渲染。這是很多“機(jī)器在運(yùn)行”外觀效果的標(biāo)準(zhǔn)做法。這套方案的優(yōu)點(diǎn)是性能極好幾乎沒有任何運(yùn)行時(shí)開銷客戶端拿到的只是兩個(gè)不同靜態(tài)模型。缺點(diǎn)是做不了連續(xù)動(dòng)畫比如進(jìn)度條長度平滑增長就無能為力。如果你的反應(yīng)器外觀想展示一個(gè)“進(jìn)度條逐步填滿”的視覺效果那就得上方案二。5.2 方案二TileEntitySpecialRenderer做自定義渲染TESR的思路是完全繞過普通方塊模型由自己寫OpenGL調(diào)用邏輯來渲染TileEntity的形狀和動(dòng)態(tài)效果。1.12.2里有TileEntitySpecialRenderer 這個(gè)抽象類你重寫render方法綁定自己加載的模型然后根據(jù)TileEntity的progress字段來計(jì)算旋轉(zhuǎn)角度、位移、亮度、粒子效果等。TESR能做真正的平滑動(dòng)畫這是它比getActualState強(qiáng)的地方。但代價(jià)也很明顯每幀每個(gè)TileEntity都要調(diào)用你的render方法如果你不做優(yōu)化成千上萬個(gè)機(jī)器同時(shí)在工作會(huì)直接把幀率拉垮。如果你決定用TESR我的建議是優(yōu)先嘗試FastTESR。FastTESR會(huì)跳過一些常規(guī)的渲染狀態(tài)準(zhǔn)備性能更好代價(jià)是你不能使用大部分原版渲染輔助方法而且要自己管理OpenGL狀態(tài)。新手不推薦一上來就寫FastTESR先學(xué)會(huì)普通TESR理解了渲染流程后再優(yōu)化不遲。還有一個(gè)必坑點(diǎn)TESR必須獨(dú)立注冊(cè)不能依賴方塊注冊(cè)流程。1.12.2里用ClientRegistry.bindTileEntitySpecialRenderer(TileEntityReactor.class, new RenderReactor()); 放在客戶端初始化階段執(zhí)行即可。6. 排查記錄我在這套代碼上踩過的坑6.1 六個(gè)常見問題速查表這幾個(gè)問題基本上每個(gè)做TileEntity的新手都會(huì)遇上我把它們整理出來遇到相同現(xiàn)象直接對(duì)著查。問題現(xiàn)象常見原因解決方案放入燃料和原料后機(jī)器完全不動(dòng)update方法里沒寫world.isRemote判斷在update第一行return掉客戶端分支重啟游戲后進(jìn)度和物品丟失槽位數(shù)組沒寫入NBT或沒調(diào)用markDirty檢查readFromNBT/writeToNBT確保每個(gè)槽位都序列化客戶端進(jìn)度條數(shù)值永遠(yuǎn)是0沒實(shí)現(xiàn)getUpdatePacket補(bǔ)上getUpdatePacket和onDataPacket玩家挖掉方塊內(nèi)部物品消失沒重寫breakBlock處理掉落遍歷IInventory調(diào)用spawnAsEntity模型不切換工作態(tài)看不出來getActualState的working屬性沒監(jiān)聽TileEntity狀態(tài)在getActualState里查詢shape并確保update里調(diào)用了notifyBlockUpdate漏斗能輸出但不能輸入isItemValidForSlot判斷過嚴(yán)檢查槽位索引和物品判斷邏輯是否合理6.2 幾個(gè)讓代碼更穩(wěn)的長期習(xí)慣做TileEntity開發(fā)時(shí)間久了我總結(jié)出幾條保命經(jīng)驗(yàn)。第一所有持久化字段集中管理不要散落在類的各個(gè)角落。我見過很多項(xiàng)目把進(jìn)度值、燃料時(shí)間、配方ID都寫成獨(dú)立字段寫NBT時(shí)漏一個(gè)補(bǔ)一個(gè)最后維護(hù)成本高到爆炸。統(tǒng)一放到一個(gè)區(qū)域每次改字段都順手檢查NBT的讀寫是否同步更新。第二永遠(yuǎn)不要在update里直接new ItemStack。游戲每秒鐘會(huì)調(diào)用20次update如果你的處理邏輯里每tick都構(gòu)造新對(duì)象GC壓力會(huì)很明顯。最好在配方判定階段緩存結(jié)果或者用同一組ItemStack復(fù)用。原版的熔爐實(shí)現(xiàn)里有很多細(xì)節(jié)可以學(xué)習(xí)它用一個(gè)私有數(shù)組緩存當(dāng)前燒煉結(jié)果這是很成熟的設(shè)計(jì)思路。第三明確區(qū)分“服務(wù)端數(shù)據(jù)”和“客戶端數(shù)據(jù)”。progress這個(gè)字段在客戶端的存在意義只是為了顯示和渲染不應(yīng)該參與真正的邏輯判斷。如果你在canProcess里用了客戶端同步過來的progress做判定那服務(wù)端也會(huì)跟著出問題。唯一的原則就是業(yè)務(wù)邏輯要模擬在服務(wù)端的常用經(jīng)驗(yàn)就是給update方法加上一個(gè)“是否客戶端”的判斷以后所有的邏輯判斷都用服務(wù)端獨(dú)立計(jì)算的字段客戶端只讀現(xiàn)成結(jié)果。第四方塊更新通知不能濫用。如果你每個(gè)tick都調(diào)world.notifyBlockUpdate那任何在附近觀察的玩家都會(huì)收到大量網(wǎng)絡(luò)包人多的時(shí)候服務(wù)器會(huì)卡。我建議只在幾個(gè)關(guān)鍵節(jié)點(diǎn)觸發(fā)同步開始處理時(shí)、處理完成時(shí)、燃料或原料耗盡時(shí)。中途的progress增長不需要實(shí)時(shí)同步等到狀態(tài)變化時(shí)一次性同步即可。很多機(jī)器模組之所以卡就是因?yàn)樗鼈儼淹筋l率設(shè)成了每個(gè)tick一次。7. 擴(kuò)展方向從一臺(tái)反應(yīng)器到一個(gè)完整的機(jī)器體系當(dāng)你把反應(yīng)器的TileEntity邏輯跑通以后后續(xù)的擴(kuò)展就只是量變到質(zhì)變的問題了。最自然的幾個(gè)方向我在文章里也提過第一加入GUI和Container讓玩家能手動(dòng)放置和取出物品第二加入真正的配方系統(tǒng)用Map或者JSON配置文件來定義“什么燃料燒什么材料”再和合成表對(duì)應(yīng)起來第三加入紅石控制比如用IBlockState里的powered屬性讓反應(yīng)器在收到紅石信號(hào)時(shí)才工作第四加入多方塊結(jié)構(gòu)讓反應(yīng)器需要一個(gè)外殼或配套方塊才能運(yùn)行這就接近一些大型模組的機(jī)器體系了。我個(gè)人的建議是先把無GUI版的完整同步鏈路徹底吃透再一步步加上這些殼子。TileEntity的核心難點(diǎn)永遠(yuǎn)不在表面花活而在數(shù)據(jù)、邏輯、同步這三者的協(xié)調(diào)。反應(yīng)器這期把這三件事都覆蓋到了下一期加GUI時(shí)你會(huì)發(fā)現(xiàn)前面積累的這些經(jīng)驗(yàn)全部用得上。