速查 › 模型與臉皮 models.big

模型與臉皮 models.big

全遊戲最大的單一封裝檔,535.9 MB,裝著球員的臉、身體與裝備。 這一頁除了講結構,還會講一件更重要的事: 怎麼判斷你手上這份是不是原版。

先說清楚這頁的數字是從哪一份遊戲量的

本頁的項目數、檔案數、覆蓋率,量的是一台裝過台灣模組的遊戲剛安裝好的原版數字小很多 —— 例如臉皮 504 對 894、大頭照 1,487 對 6,638、 語音號碼 1,673 對 4,343。

格式與結構的部分兩邊一樣,那是遊戲程式決定的; 會變的是「有幾個」。完整對照見 原版與這台機器差在哪

先看規模

項目數字備註
檔案大小535.9 MB全遊戲最大的 .big
項目數4,211 個
壓縮比例4,211 / 4,211全部都是 QFS,零例外
目錄涵蓋率100.0% 孤兒 0 bytes
球員臉皮894 張命名 c001c900(缺 6 號),每張三個檔

⚠️ 2026-08-28 訂正:孤兒那一格原本寫「只有 0.1 MB」。 那 73,322 bytes 就是檔頭 16 加上目錄 73,306 —— 目錄本身不是孤兒。 照本站統一的定義算, models.big 的孤兒是 0 bytes,一個位元組都沒有。 這比原本寫的更強,而且是真的。

上面每個數字都是把 models.big 現場解開數出來的,不是引用他人資料。

裡面裝什麼

副檔名數量是什麼證據
.fsh2,332貼圖(臉、皮膚、裝備表面) 實測 解壓後開頭是 SHPI,格式見大頭照那頁
.ord939幾何模型資料 未確認 本站未逐欄解讀
.orl939.ord 的配套資料 實測 939 個名稱與 .ord 一一對應,體積小得多
.txt1一份純文字清單。原版一個 .txt 都沒有(副檔名只有 .fsh 1,573、.ord 549、.orl 549)—— 這個是重打包時塞進來的 實測 見下方「這份檔案的來歷」

.ord.orl 成對出現,跟球場檔是同一套做法。

894 張臉皮,890 張規格完全一樣

我們改過這一段:EA 出貨的規格是那 4 張「例外」

下面這一節量的是本站測試機那份 models.big。 拿剛安裝好的原版重量:

臉皮張數格式與尺寸
剛安裝好的原版504 0x78 128×256,504 張全部一樣,零例外
本站測試機894 0x60 256×512 有 890 張、0x78 128×256 有 4 張

方向剛好反過來。本頁原本把 890 張 0x60 當成「規格」、 4 張 0x78 當成「例外」;但 0x78 128×256 才是 EA 出貨時用的, 原版 504 張全部是它。

這台上那 890 張用的是 EA 沒有用在臉皮上的格式與尺寸。 是誰、在哪一次改動裡換掉的,本站不知道。未解

⚠️ 2026-08-25 訂正:這裡原本寫「EA 沒有用過的格式」「原版沒有這個格式」, 兩句都是假的全稱句0x600x61 是 EA 自己大量在用的正規格式, 只是沒用在臉皮和大頭照上:frontend\logos.big 裡有 920 張 0x61frontend\bkgnds.big 裡有 105 張 0x60; 連「0x60 的 256×512」這個一模一樣的組合, 球場檔 stadium\crosday.big 裡就有一張。 同一件事大頭照那頁寫對了 —— 它寫的是「EA 在這個倉庫裡沒有用過」。差別只在那個限定詞。

臉皮的命名是 c 加三位數字,每一張佔三個項目 (.fsh 貼圖 + .ord.orl 幾何)。 2,682 ÷ 3 = 894 張臉

本站測試機的編號從 c001 排到 c900,但中間缺 6 個號碼c116c125c170c177c188c219), 900 − 6 = 894。未確認 為什麼缺這幾號,本站沒有查出來。

⚠️ 2026-08-25 補:剛安裝好的原版完全不是這樣。 原版只有 504 張、編號 c001c606、中間缺 102 個 (2、37、58、80、106…)。「c001–c900、缺 6 個」是社群重新打包之後的樣子 —— 模組把號碼填到 900,順手補掉了原版那 102 個空號的大部分,自己又缺了 6 個。 所以「缺號」這件事在兩份檔案裡是完全不同的兩回事。

張數貼圖尺寸格式代號
890256 × 5120x60
4128 × 2560x78

99.6% 用同一個規格

894 張臉裡有 890 張是同一個尺寸、同一種格式代號。 這代表做臉皮模組時規格是固定的,不必每張各自研究。

只有 4 張是例外,尺寸剛好是一半(128×256)。

哪一張臉是哪一位球員

這個問題有答案,而且答案就在球員資料檔裡。 attrib.dat 裡的 playerattrib_face 這一欄存的就是臉皮編號:

attrib.dat 裡 Shohei Ohtani 那一列
  playerattrib_face = 665
                       └→ models.big 裡的 c665.fsh / c665.ord / c665.orl

認欄位名字,不要認欄號。本站 2026-09-03 把手邊九份內容不重複的 名冊逐份查過表頭,playerattrib_face 九份都排在第 10 欄,但那是運氣不是規定: 同一批名冊裡 playerattrib_audioid 有 16 與 17 兩種、 playerattrib_skin_tone 有 12 與 38 兩種。打開你自己那份的第一行照名字找才準,見 欄號會因名冊而異

實測對得起來

把 3,247 位球員的 face 值全部拿去比對 models.big 的臉皮編號:

699 個不同編號裡,698 個對得到,命中率 99.9%。

唯一對不到的是 219 —— 而 c219 正好就是 前面提到那 6 個缺號之一。 也就是說:有球員指向一張不存在的臉。

只有兩成球員有自己的臉

face 欄位的值球員數佔比意思
1 ~ 90071221.9% 有專屬臉皮,對應 models.bigc001c900
901 ~ 9152,51077.3%
分母是全部 3,247 列;只算有名字的 3,222 列是 77.9%
用通用臉。只有 15 個編號,兩千多人共用
0250.8%沒有指定。這 25 列不是球員 —— 姓名兩欄空白、hidden 寫 1 的預留列

這張表的「球員數」是名冊的列數:3,247 列裡有名字的是 3,222 列, 其餘 25 列是空白預留列(兩套球員編號那頁同一格也是這樣記的)。 上面的佔比分母是全部 3,247 列。

15 個通用臉的使用人次相當集中:編號 903 一個就有 613 位球員在用, 其次是 902(388 位)與 905(315 位)。

這解釋了一件玩起來會注意到的事

知名球員長得像本人,板凳球員看起來都差不多 —— 不是你的錯覺,是大部分球員真的共用那 15 張臉(本站測試機 2,510/3,247 = 77.3%,剛安裝好的原版還更高:2,456/2,921 = 84.1%)。

反過來說,如果你想幫某位球員做專屬臉皮, 除了做出 c### 那三個檔,還得把他 attrib.datplayerattrib_face 那一格的值改成那個編號,否則遊戲不會用它。

順帶澄清一個容易搞混的欄位

attrib.dat 還有一個欄位叫 playerattrib_photo(本站測試機第 17 欄,剛安裝好的原版第 18 欄 —— 欄號會因名冊而異), 名字看起來像大頭照編號,但它不是

本站測試機實測它只有 0、1、2 三種值(分別是 198、2,908、141 位球員), 是某種旗標。未確認 實際用途本站沒有解出。

⚠️ 2026-08-25 補:原版只有 1 與 2 兩種值,沒有 0 (1 有 1,301 人、2 有 1,620 人)。而且它幾乎是「這位球員有沒有語音編號」的鏡像: photo=2audioid=0 有 1,620 人、 photo=1audioid≠0 有 1,300 人 —— 2,921 位裡只有 1 個例外(Default Default,名冊的第一列空位)。 99.97% 的一致度 —— 這一欄在原版基本上就是「這位球員有沒有語音」的旗標。 而那個 0 是社群名冊才有的。

大頭照那邊的編號對應已經解開了:檔名的四位數就是同一張表裡的 playerattrib_audioid,不是這一欄(拿剛安裝好的原版對,1,300 個非 0 的 audioid 有 1,232 個在 portrait.big 裡找得到圖,命中 94.8%)。 詳見兩套球員編號

⚠️ 2026-09-05 訂正:這裡原本寫「大頭照那邊的編號對應,目前仍未解」。 那是本頁上線時的說法,大頭照那頁後來已經解開並自我訂正, 本頁沒有跟著改。未解的只有 photo 這一欄的實際用途。

編號有三個區間,而且中間那個是雷區

臉皮編號看起來只是 c001c900 一路排下去, 但拿剛安裝好的原版去比就會發現它其實分三段:

編號是什麼原版用到幾號
c001 – c606 EA 自己用掉的。兩份剛安裝好的原版(英文版與繁體中文版)都是 465 位球員有專屬臉,全部落在這一段 上限 606
c607 – c900 剛安裝好的原版沒有球員指過來的號段。在原版上把新臉放這一段不會動到任何人; 但剛安裝好的原版這一段一張臉也沒有,要 models.big 裡真的有那個編號才用得上。 裝過模組的名冊會用到這一段(本站測試機有 234 位球員指過來) 原版 0 個
901 – 915 通用臉。不對應 models.bigc###(見上一節) 15 個

為什麼中間那段是雷區:一個實際的例子

本站手上有一份 2009 年的社群模組,它附了 26 張臉皮, 每個資料夾的名字都寫著球員、編號、和做的人。把那 26 個編號拿去對:

撞號的意思是:那張臉本來是別人的。例如 c131 在原版是 Jason Isringhausen 的臉,模組把它換成了一位台灣球員的臉。

那撞到的人怎麼辦

這是這份模組最值得看的地方 —— 它有處理,不是覆蓋了就算:

原版是誰的臉原版模組裡變成怎麼處理的
Keith Foulkec190c902改用通用臉
(5 位)
Antonio Alfonsecac192c911
Armando Benitezc114c909
Jason Isringhausenc131c902
Eric Miltonc520c903
Barry Larkin、Mark Mulder、Tony Womack 等c119 等 不在這份名冊裡
(7 位,2009 年都已退休或不在大聯盟)
Rod Carew、Lou Gehrigc442 / c423 c442 / c423沒有處理
(見下)

14 個撞號裡,12 個是處理過的:還在打球的挪到通用臉,2009 年已經退休或不在大聯盟的就不放進名冊。 那是有人一個一個決定的,不是工具自動做的。

但有兩個沒處理 —— 而那正好是最好的示範

c442c423 在那份模組裡各有一張新臉皮, 但名冊裡 Rod Carew 與 Lou Gehrig 還留在那兩個編號上

意思是:裝了那個臉皮包之後,這兩位名人堂球員會頂著別人的臉

本站沒有實機確認遊戲裡看起來如何,也不知道這是疏漏還是刻意。 未驗 但它把「用 EA 範圍內的編號要付什麼代價」講得比任何說明都清楚。

所以你要加臉的時候

用 c607 以上的空號。那一段 EA 沒有用,在剛安裝好的原版名冊上 加下去不會動到任何人。但裝過模組的名冊不一樣 —— 本站測試機那份名冊就有 234 位球員指向 c607–c900(231 個不同編號), 所以挑號之前要先查那個編號有沒有人在用(本站的換臉工具會替你查,見本卡最後一段)。

但要先讓 models.big真的有那個編號才算數:剛安裝好的原版 c607–c900 一個項目都沒有(504 張臉全落在 c001c606), 而封裝檔不能新增項目、只能換掉現有的(見〈做一張新的球員臉皮〉)。 所以在剛安裝好的原版上,可以直接挑的是「封裝檔裡有、名冊裡卻沒人用」的編號, 英文版與中文版兩份量到的都是 39 個; 本站測試機那份裝過模組的 models.big 有 894 張臉,c607–c900 就占了 294 張。

要用 c606 以下的號碼也不是不行 —— 2009 年那份模組就用了 15 個 —— 但你得知道你正在拿走誰的臉,而且要決定那個人之後長什麼樣。

本站的換臉工具 從 2026-08-25 起會提醒你這件事:指定一個已經有別人在用的專屬臉編號時, 它會列出那些人,並建議改挑一個「models.big 裡有、名冊裡卻沒人用」的編號。 (通用臉 901–915 本來就是共用的,不會提醒。)

整包共用同一種貼圖格式

不論哪一種尺寸、哪一種格式,每個 .fsh 的影像資料後面 都跟著一段目錄沒登記的文字記錄,跟大頭照完全一樣:

EAGL64 metal bin attachment for runtime texture management

2,332 / 2,332,一個例外都沒有。 加上 portrait.big7,539 / 7,542, 將近一萬個圖片檔帶著同一句話 —— 只有三個例外

先講一個很容易數錯的地方

與大頭照不同,這裡一個 .fsh 檔可以裝很多張圖 (實測有裝 36 張、28 張、10 張的)。所以「有幾個檔」跟「有幾張圖」是兩回事:

.fsh 檔案數 2,332 ·  裡面的影像總數 41,343

只數每個檔的第一張圖,會得到完全不同的分佈。下表是走過全部 41,343 張統計的。

代號影像數佔比尺寸分佈
0x6D25,95862.8% 以 16×32(16,852)與 32×64(6,340)為主,小圖示類
0x7813,73833.2% 混合:256×256(3,472)、256×128(2,958)、256×512(2,359)
0x608902.2% 全部都是 256×512 ← 這 890 張就是球員臉皮
0x615911.4% 256×256(375)與 128×128(216)
0x7D1210.3%全部 128×128
0x7F450.1%全部 128×128

代號 0x60 那 890 張的數字,跟前面「894 張臉皮,890 張規格完全一樣」那一節完全對得起來 —— 它們就是同一批東西,從兩個方向數到同一個數。

這份檔案的來歷

掃描時發現 models.big 裡有一個 faces.txt。 解開來看,它是某人在自己的 Windows 電腦上跑目錄列表指令的輸出, 被原封不動打包了進去:

 Volume in drive C has no label.
 Directory of C:\Users\〔本站已移除〕\Desktop\〔已移除〕\faces

Nov-26-13  08:48 AM      65,680 c001.fsh
Nov-26-13  08:48 AM      44,224 c001.ord
Nov-26-13  08:48 AM       5,040 c001.orl
              …共 2,710 行

兩件事同時成立

一、這份 models.big 不是 EA 原版。 日期是 2013 年 11 月,遊戲是 2005 年出的。它被社群重新打包過。

二、打包的人把自己的使用者名稱一起送了出去。 本站已移除,也不寫出那份檔案的其他辨識資訊 —— 把名字遮掉、卻附上「去哪裡找」,等於沒遮。

要講的重點不是那個人是誰,是這件事會發生。 那份檔案在網路上流傳了十幾年,每一份拷貝都帶著它。

如果你要做模組包,這是給你的提醒

打包前檢查一下:有沒有把目錄列表、批次檔、記事本草稿一起裝進去。 這些檔案常常帶著你的使用者名稱、桌面路徑、甚至專案代號。

檢查方法很簡單:把封裝檔的項目清單列出來,看看有沒有 .txt.bat.log 這種不該出現在遊戲資源裡的東西。

怎麼知道自己手上的是不是原版

不用開檔案,看檔案日期就有八成把握。原版檔案會停在 2005 年:

檔案日期判讀
anims\anims.big2005-01原版
stadium\crosday.big2005-02原版
models.big2023-05動過
frontend\ingame.big2023-02動過
fonts\fonts.big2022-11動過

上表是本站測試機的實際狀況,你的電腦會不一樣。重點是方法不是數字。

為什麼這件事值得先確認

網路上很多「MVP 2005 的檔案格式是這樣」的說法, 是從已經被改過的檔案量出來的,卻寫成 EA 的設計。

本站也一樣受限:測試機的 models.big 是社群版本, 所以這一頁講的是「這個檔案現在長什麼樣」不宣稱那是 EA 當年的做法。要談 EA 的原始設計, 得先拿到沒被動過的原版才行。

想動它之前

535.9 MB,全遊戲風險最高的一個檔

它同時裝著幾何模型與貼圖,改壞了通常是進到球場就當掉, 而且因為檔案大,備份與還原都慢。

存回去一樣是那條鐵律:接到檔尾、只改目錄, 絕不整包重新打包。詳見 BIGF 封裝格式

你可能想做的事現況
換一張球員臉皮 可以替換 規格固定,但要看你手上是哪一份: 本站測試機這一份是 256×512、代號 0x60剛安裝好的原版是 128×256、代號 0x78 (見本頁前面那張原版與測試機的對照表)。 社群有現成臉皮包
自己做一張新臉皮 半解 .fsh0x60 的像素編碼已經解開 —— 每 4×4 像素一個 8 位元組的區塊,見圖片的像素怎麼排;把新圖壓縮回去那一半後來也做了(見做一張新的球員臉皮
改球員體型、裝備幾何 半解 只解開容器:.ord.orl 接起來是一個完整的 MIPS 目標檔,但裡面的幾何欄位本站未逐欄解讀,也沒有做出可以改它的工具, 見下方

完整的可改/不可改分級見 什麼改得動、什麼還不行

那些 .ord.orl 是什麼

models.big 裡除了臉皮貼圖,還有 939 個 .ord939 個 .orl成對出現,一個不缺

把一對解開來看:

檔案解壓後開頭四個位元組
c001.ord44,304 7F 45 4C 46 = .ELF
c001.orl5,040 00 2E 64 61 = .da…

ELF 是一種標準的目標檔格式(編譯器產生、還沒連結的中間產物)。 所以 .ord 不是 EA 自己發明的格式。

最漂亮的一條:檔案自己說它不完整

ELF 的檔頭裡有一格寫著「段落表在第幾個位元組」。c001.ord 那一格寫的是 49,104 —— 但這個檔只有 44,304 個位元組

指到檔案外面去了。而 .orl 剛好 5,040 個位元組, 44,304 + 5,040 = 49,344,49,104 就落在裡面。

兩個檔接起來,才是一個完整的目標檔。 這不是猜的 —— 是那個檔頭自己指過去的

本站把全部 939 對都跑了一遍:

檢查結果
解壓成功939 / 939
.ord 開頭是 ELF939 / 939
檔頭指向的位置落在 .orl 範圍內 939 / 939
零例外

檔頭還說了更多:32 位元、小端序、可重定位的目標檔、目標是 MIPS 處理器。

MIPS 是主機的處理器

PlayStation 2 用的就是 MIPS。這些檔案是主機版留下來的, 跟遊戲裡那個網站虛擬 PlayStation 手把一樣, 都是移植的痕跡。

動畫封包那頁.ord.orl 是同一回事,兩邊各自量到同樣的結構。

但有 14 個沒有被切成兩半

本站把整個 data\ 底下每一個封裝檔都掃過一遍找 ELF:

量到的個數
開頭是 ELF 的項目3,895
需要拼接另一半的3,879
本身就完整的16

⚠️ 這張表量的是本站測試機那一份 data\。 剛安裝好的原版是 3,503 個(207 個封裝檔、29,816 個項目), 見動畫封包那頁。 差的 392 個裡有 390 個就是 models.big 兩邊 .ord 的差 —— 測試機 939 個、原版 549 個;剩下那 2 個在下面說。

⚠️ 2026-09-05 訂正:這三個數字原本寫 3,893/3,879/14。重量之後是 3,895/3,879/16,而「差的 390 個剛好等於 .ord 的差」也不成立, 實際差 392。多出來的兩個見下一段。

那 16 個裡有 14 個在同一個地方:data\misc\miscmod.big。 而且那個封裝檔裡就只有這 14 個東西,別的什麼都沒有

另外 2 個是測試機才有的:stadium\propday.bigstadium\propnite.big 裡各一個 removable.o, 而且它們沒有壓縮,是直接放進去的 ELF。剛安裝好的原版那兩個封裝檔是 88 個項目、 沒有這一項;測試機是 89 個。所以剛安裝好的原版那邊仍然是 14 個

它們用的是標準副檔名 .o(目標檔的慣例寫法), 而 models.big 裡那些被切兩半的用的是 .ord.orl連副檔名都在說「這個是完整的、那個是半個」。

檔名很有畫面:

lawn.o   moon.o   roof.o   tran.o
obj1.o   obj2.o   obj3.o   obj4.o
pla1.o   pla2.o   bli1.o   bli2.o
aple.o   bern.o

推測 草皮、月亮、屋頂 —— 看起來像球場周邊的景物但本站沒有解出裡面的內容,這只是從檔名猜的。

解開了容器,沒解開內容

知道「這是一個 MIPS 目標檔、兩半怎麼接」—— 但裡面那些機器碼與資料段實際在做什麼,本站沒有解讀, 也沒有做出可以改它的工具。未解

本站不會往「改執行碼」的方向走。

所有的臉共用同一副骨架(2026-08-28 量的)

本頁前面講過 .ord.orl 接起來是一個標準目標檔。 那把它打開來看裡面有什麼?

剛安裝好的原版 models.big結果
.orl 的數量549 個
504 個臉皮 c### + 45 個 g###
每個檔裡有幾根骨頭66 根,549/549 零例外
骨頭名稱的集合只有 1 種 —— 全部共用同一副
英文版與中文版兩邊逐項完全相同

這回答了一個實用的問題:為什麼不同人做的臉可以互換。 因為它們掛的是同一副骨架 —— 換臉做新臉皮那兩課能成立, 根本原因就在這裡。

那 66 根骨頭

骨頭的名字全部以 FBXdummyNode. 開頭 —— FBX 是 Autodesk 的模型交換格式,所以 EA 的製作管線是經由它匯出的。 去掉前綴之後:

Hips  LowerSpine  MiddleSpine  UpperSpine  Neck  Head     ← 身體中軸
LArm  LArmTwist  LForearm  LForearmTwist  LHand           ← 手臂(左右各一組)
LIndex LIndexB  LMiddle LMiddleB  LRing LRingB  LThumb LThumbB   ← 手指
LLeg  LShin  LFoot  LToe                                  ← 腿
EyeLids  Jaw  LEye  LBrow  LCornerMouth  LLoCheek  LUpCheek
UpLip  LoLip                                              ← 臉部表情
Bat  Hat  Trajectory  hatPosition  leftEyePosition  rightEyePosition  ← 掛載點
LCollerBone  RCollerBone  LConstraint  RConstraint  FBXdummyNode
dudeWheresMyHead

臉部有 九種表情骨頭(眼皮、下巴、眼睛、眉毛、嘴角、上下臉頰、上下唇), 左右各一份 —— 這是那些 平安夜那天打包的 48 個表情動畫在動的東西。

兩個 EA 忘了拿掉的東西,出貨了 549 次

骨頭名問題出現在幾個檔
dudeWheresMyHead一個開發者玩笑(「老兄,我的頭咧」) 549 / 549
LCollerBone · RCollerBone拼字錯誤 —— 鎖骨是 Collar 不是 Coller 549 / 549

兩個都在英文版與中文版的每一個 .orl,一個例外都沒有。 骨架是同一份範本複製 549 次的,所以範本裡的東西全部跟著走。

這也順帶說明了為什麼「共用同一副骨架」這件事可以量得這麼硬: 連錯字都一模一樣。

每個檔裡還有一個工具鏈版本標記 EAGL_TOOLLIB_VERSION-4, 549 個全部是 4 —— 整批是同一版工具匯出的。

⭐ 社群做的臉皮也是同一副骨架 —— 跨十八年,零例外

上面量的是 EA 出貨的 549 個 .orl。本站另外把手上七批社群臉皮包全部解開 (年份從 2005 到 2023),把裡面每一個 .orl 的骨頭名單抓出來:

.orl 個數每個幾根骨頭骨架與 EA 逐字相同
EA 出貨的54966—(基準)
社群做的(七批)55566 555 / 555(100%)
合計1,10466零例外

一千一百多個模型,一副骨架,十八年沒有變過。 這就是為什麼任何人做的臉都可以裝進任何一份名冊 —— 大家都是從 EA 的同一個範本改出來的

⚠️ 但那些臉皮包會蓋掉 EA 自己的球員

同一批包裡的臉皮編號合計 321 個, 而剛安裝好的原版有 504 個臉皮(編號 c001c606)。兩邊比對:

跟原版撞號204 個(64%) 裝下去會把 EA 原本那位球員的臉換掉
原版沒有的編號117 個(36%) 需要先有一份把範圍撐大的名冊模組

兩件事同時發生:一部分是「加」,一部分是「換」。 這也是為什麼同時裝兩個臉皮包,後裝的會蓋掉先裝的 —— 它們共用同一個編號空間。

本站在2009 年那份名冊 講過同一個現象的一個具體例子。這裡是把它量成整體的樣子。

原廠出貨的球衣長什麼樣(2026-08-28 補)

本頁其他段落量的是這台裝過台灣模組的機器。球衣這一塊後來拿到剛安裝好的原版, 可以給出 EA 原始出貨的基準:

剛安裝好的官方英文版 models.big結果
球衣本體 u###x.fsh 的數量433 個
每個檔裡有幾張貼圖28 張,433/433 零例外
解壓後的大小732,592 bytes,433/433 完全相同
「貼圖名稱+像素格式+尺寸」的組合只有 1 種
子圖的排列順序8 種(其中一種佔 425 個)

每一件原廠球衣的規格完全一樣,連解壓後的位元組數都分毫不差。 變的只有子圖在檔案裡排第幾 —— 這跟隊徽 那邊觀察到的現象一樣:名字是固定的,順序不是。 寫自動化腳本的人要照名字找,不能照位置找。

那 28 張貼圖像素格式尺寸
jerf · jerk · jers · jert16 位元128 × 128
lega · legb · legc · legd16 位元128 × 256
chst · merf · shn116 位元128 × 128
hat · hlm1 · shoe · slvl · slvr16 位元128 × 64
mslv16 位元64 × 128
aslv · bglb · bglt · merk16 位元64 × 64
wrbn16 位元32 × 32
msk216 位元8 × 8
hhlm · llod · msk116 位元 4444(有透明度)128 × 128
msk316 位元 444464 × 32
lace16 位元 444432 × 32

28 張裡一張 DXT 都沒有 —— 全部是 16 位元, 其中 5 張用帶透明度的 4444 格式(頭盔遮罩、鞋帶、幾張遮罩圖)。 像素格式的意義見圖片像素編碼

📌 重點整理

接下來