感謝回報——尤其謝謝你附的那張截圖，這一則是靠截圖破的，不是靠伺服器紀錄。 ◆ 結論：確認是缺陷，已修好上線。 先讓你安心：你的角色、物品、進度全都沒事。壞掉的只有「畫面收到的資料」， 重連之後就正常，不會有任何損失。 ◆ 到底發生了什麼 伺服器除了給你看的文字之外，還會另外送一份「結構化資料」給遊戲介面用—— 背包裡有什麼、房裡有誰、每樣東西可以做哪些動作（看、穿、丟、問…）。 那份資料平常你看不到，它走的是另一條通道。 問題出在**那份資料太大了**。你的截圖裡那些 JSON、那些 `"cmd": "look leiyun_boots"`、`"ask iceguard about 消息"`， 正是這份資料被擠爆之後溢出來、混進文字畫面造成的。 會這麼大，是因為背包裡每一款物品都附帶它的動作選單， 而且**只要撿到任何東西就會整份重送**——副本裡連續擊殺、掉落不斷， 正好是最容易撐爆的場景，跟你描述的「打一陣子之後突然爆掉」完全吻合。 我量了線上實際的資料量：最大的一位玩家達到 85,000 位元組，你當時是 11,000。 ◆ 修法 替這條通道加了大小上限（8,000 位元組），超過就自動瘦身： 先拿掉動作選單（介面本來就能自己組），還是太大就截斷清單並標明「已截斷」， 真的塞不下就整份不送。寧可介面少一格資料，也不能讓你的畫面壞掉。 上線前拿全服每一位玩家的真實背包驗過一遍，全部壓進上限。 以你的情況為例：11,000 → 6,900 位元組，只拿掉動作選單，物品清單完整保留。 ◆ 一件想請你幫忙的事 我沒辦法確定你當時用的是哪一種連線方式，所以無法百分之百重現同一個現場。 已經證實的是「資料量曾經超標、現在全部壓在安全範圍內」。 如果你之後**還是**遇到同樣的滿畫面亂碼，請再回報一次並說一下你用什麼連—— 那就表示還有另一層原因，我會再追下去。 謝謝你把「擊殺並獲得掉落物之後才開始」這個時間點寫清楚，那正是定位的關鍵。

想回報一下，副本戰鬥中的畫面凍結(Display Freeze)問題又再次發生了，而且近期發生的頻率相當高。 我目前是使用 Mudlet 連線遊戲。在進行副本戰鬥時，幾乎不可能完整跑完一次副本而不遇到凍結或錯誤。通常戰鬥進行一段時間後，畫面會突然出現大量異常文字輸出，內容看起來像是未經處理的 JSON 或程式資料： {"name":"...","ref":"#726652", ...} 之後顯示內容就變得混亂，有時甚至會導致畫面卡住，影響正常遊戲進行。 從附圖可以看到，原本正常的戰鬥訊息中間突然插入大量 JSON 格式資料，將戰鬥訊息打斷。這個問題似乎特別容易在副本持續刷怪或長時間戰鬥時發生。 目前觀察到的現象： 使用 Mudlet 連線。 發生地點主要在副本戰鬥中。 戰鬥進行一段時間後出現。 畫面突然輸出大量 JSON/程式資料。 顯示異常後容易產生凍結或操作延遲。 幾乎無法完整打完一次副本而不遇到此問題。

【申請複查】 想回報一下，副本戰鬥中的畫面凍結(Display Freeze)問題又再次發生了，而且近期發生的頻率相當高。

先謝謝你回來補這一則——尤其是「我用 Mudlet」這句。你上次照我的請求做了， 那句話直接把方向改掉了。 ◆ 我上次的判斷是錯的，先說清楚 上次我說病因是「單一封包太大，撐破用戶端的子協商緩衝」，所以加了 8000 位元組的 上限。這個判斷站不住腳：Mudlet 的子協商上限其實是 5 MB，8000 遠遠不到；而且上限 上線之後你 08-27 又中了一次。所以那不是病因，上限也不是解方。 ◆ 這次看到的是什麼 把你兩張截圖放大逐字對，壞掉的形狀不是「一則封包被截斷」，而是**整條資料流被打亂**： 文字被切進 JSON 中間、同一段位元組往回跳然後重複、中文碎成無效字元，而且**要重連 才會好**。「重連才好」是關鍵——那代表壞掉的是一個有狀態、會一路錯下去的東西。 伺服器這端我逐條稽核過送出資料的每一個出口，框線是乾淨的、沒有半條繞過去。 剩下最合理的解釋是**壓縮通道在你那端解得不同步**（Mudlet 的壓縮解碼有幾筆已知 缺陷，其中一筆的情境跟你這個幾乎一模一樣：物品一多就出事）。 ⚠ 這一句我只能說是推論，不是實證——Mudlet 內部我在伺服器這邊驗不到。 所以這次我沒有再賭單一原因，而是把三個我真正握得住的地方全部收緊。 ◆ 這次改了三件事 一、**不再逐件重送整份背包。** 以前你每撿到一件東西，伺服器就把整份背包重送一次。副本裡一次擊殺常常同時掉 妖核＋護甲＋兵器，那就是連續三份完整背包，連殺就是一波接一波。 現在同一波變動會合併成一次。實測：六個背包動作一口氣送出，以前是六份，現在一份。 二、**Mudlet 不再收到用不到的資料。** 每件物品原本都附帶一份「可點擊選單」，那是網頁版介面用的，Mudlet 完全用不到， 偏偏它又是最肥、重複性最高的一塊。現在 telnet 連線一律不送。 以你的角色實測：一次三件掉落，送往 Mudlet 的量從 19881 位元組降到 3244，**六倍**。 三、**關掉 telnet 壓縮（MCCP）。** 直接把上面那個推論裡的病灶整條拿掉。壓縮在我們這個規模省下的頻寬毫無意義， 換來的卻是「一失步就整場壞掉、只能重連」的風險，不划算。 ◆ 驗證 寫了一支像 Mudlet 一樣真的連上遊戲的探針，跑完七項全過：伺服器確認不再提議壓縮、 每一則結構化資料都解得開、純文字裡沒有任何 JSON 漏出、送給 telnet 的單則資料 不超過 4000 位元組、突發六個動作只重送一份背包。 ◆ 麻煩你再幫一次忙 三件事都上線了，剛才重啟過伺服器（如果你當時正連著，那次斷線是我造成的，抱歉）。 請重連一次——**一定要重連，舊連線還帶著舊的壓縮狀態**——再去跑一趟副本。 如果還是會發生，請再回報，並且順手做兩件事： 1. 在 Mudlet 的設定裡確認「壓縮」那格現在是關的（伺服器已經不提議了）。 2. 告訴我 Mudlet 的版本號。 我這邊已經把能量到的都量了，也把能收緊的都收緊了；如果症狀還在，那就是還有一層 我沒看到的東西，我會繼續追。