速查 › 模型與臉皮 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 張 | 命名 c001–c900(缺 6 號),每張三個檔 |
⚠️ 2026-08-28 訂正:孤兒那一格原本寫「只有 0.1 MB」。
那 73,322 bytes 就是檔頭 16 加上目錄 73,306 —— 目錄本身不是孤兒。
照本站統一的定義算,
models.big 的孤兒是 0 bytes,一個位元組都沒有。
這比原本寫的更強,而且是真的。
上面每個數字都是把 models.big 現場解開數出來的,不是引用他人資料。
裡面裝什麼
| 副檔名 | 數量 | 是什麼 | 證據 |
|---|---|---|---|
| .fsh | 2,332 | 貼圖(臉、皮膚、裝備表面) | 實測 解壓後開頭是 SHPI,格式見大頭照那頁 |
| .ord | 939 | 幾何模型資料 | 未確認 本站未逐欄解讀 |
| .orl | 939 | .ord 的配套資料 |
實測 939 個名稱與 .ord 一一對應,體積小得多 |
| .txt | 1 | 一份純文字清單。原版一個 .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 沒有用過的格式」「原版沒有這個格式」,
兩句都是假的全稱句。0x60 與 0x61 是 EA 自己大量在用的正規格式,
只是沒用在臉皮和大頭照上:frontend\logos.big 裡有 920 張 0x61、
frontend\bkgnds.big 裡有 105 張 0x60;
連「0x60 的 256×512」這個一模一樣的組合,
球場檔 stadium\crosday.big 裡就有一張。
同一件事大頭照那頁寫對了 ——
它寫的是「EA 在這個倉庫裡沒有用過」。差別只在那個限定詞。
臉皮的命名是 c 加三位數字,每一張佔三個項目
(.fsh 貼圖 + .ord/.orl 幾何)。
2,682 ÷ 3 = 894 張臉。
本站測試機的編號從 c001 排到 c900,但中間缺 6 個號碼
(c116、c125、c170、c177、c188、c219),
900 − 6 = 894。未確認 為什麼缺這幾號,本站沒有查出來。
⚠️ 2026-08-25 補:剛安裝好的原版完全不是這樣。
原版只有 504 張、編號 c001–c606、中間缺 102 個
(2、37、58、80、106…)。「c001–c900、缺 6 個」是社群重新打包之後的樣子 ——
模組把號碼填到 900,順手補掉了原版那 102 個空號的大部分,自己又缺了 6 個。
所以「缺號」這件事在兩份檔案裡是完全不同的兩回事。
| 張數 | 貼圖尺寸 | 格式代號 |
|---|---|---|
| 890 | 256 × 512 | 0x60 |
| 4 | 128 × 256 | 0x78 |
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 ~ 900 | 712 | 21.9% | 有專屬臉皮,對應 models.big 的 c001–c900 |
| 901 ~ 915 | 2,510 | 77.3% 分母是全部 3,247 列;只算有名字的 3,222 列是 77.9% |
用通用臉。只有 15 個編號,兩千多人共用 |
| 0 | 25 | 0.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.dat
裡 playerattrib_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=2 且 audioid=0 有 1,620 人、
photo=1 且 audioid≠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 這一欄的實際用途。
編號有三個區間,而且中間那個是雷區
臉皮編號看起來只是 c001 到 c900 一路排下去,
但拿剛安裝好的原版去比就會發現它其實分三段:
| 編號 | 是什麼 | 原版用到幾號 |
|---|---|---|
| c001 – c606 | EA 自己用掉的。兩份剛安裝好的原版(英文版與繁體中文版)都是 465 位球員有專屬臉,全部落在這一段 | 上限 606 |
| c607 – c900 | 剛安裝好的原版沒有球員指過來的號段。在原版上把新臉放這一段不會動到任何人;
但剛安裝好的原版這一段一張臉也沒有,要 models.big 裡真的有那個編號才用得上。
裝過模組的名冊會用到這一段(本站測試機有 234 位球員指過來) |
原版 0 個 |
| 901 – 915 | 通用臉。不對應 models.big 的 c###(見上一節) |
15 個 |
為什麼中間那段是雷區:一個實際的例子
本站手上有一份 2009 年的社群模組,它附了 26 張臉皮, 每個資料夾的名字都寫著球員、編號、和做的人。把那 26 個編號拿去對:
- 26 個全部真的有人在用(名冊裡都找得到指向它的球員),一個沒空放
- 其中 15 個落在 EA 的 c001–c606,有 14 個撞到 EA 已經指派過的球員
- 另外 11 個落在 c607–c900,一個都沒撞
撞號的意思是:那張臉本來是別人的。例如 c131 在原版是
Jason Isringhausen 的臉,模組把它換成了一位台灣球員的臉。
那撞到的人怎麼辦
這是這份模組最值得看的地方 —— 它有處理,不是覆蓋了就算:
| 原版是誰的臉 | 原版 | 模組裡變成 | 怎麼處理的 |
|---|---|---|---|
| Keith Foulke | c190 | c902 | 改用通用臉 (5 位) |
| Antonio Alfonseca | c192 | c911 | |
| Armando Benitez | c114 | c909 | |
| Jason Isringhausen | c131 | c902 | |
| Eric Milton | c520 | c903 | |
| Barry Larkin、Mark Mulder、Tony Womack 等 | c119 等 | — | 不在這份名冊裡 (7 位,2009 年都已退休或不在大聯盟) |
| Rod Carew、Lou Gehrig | c442 / c423 | c442 / c423 | 沒有處理 (見下) |
14 個撞號裡,12 個是處理過的:還在打球的挪到通用臉,2009 年已經退休或不在大聯盟的就不放進名冊。 那是有人一個一個決定的,不是工具自動做的。
但有兩個沒處理 —— 而那正好是最好的示範
c442 與 c423 在那份模組裡各有一張新臉皮,
但名冊裡 Rod Carew 與 Lou Gehrig 還留在那兩個編號上。
意思是:裝了那個臉皮包之後,這兩位名人堂球員會頂著別人的臉。
本站沒有實機確認遊戲裡看起來如何,也不知道這是疏漏還是刻意。 未驗 但它把「用 EA 範圍內的編號要付什麼代價」講得比任何說明都清楚。
所以你要加臉的時候
用 c607 以上的空號。那一段 EA 沒有用,在剛安裝好的原版名冊上 加下去不會動到任何人。但裝過模組的名冊不一樣 —— 本站測試機那份名冊就有 234 位球員指向 c607–c900(231 個不同編號), 所以挑號之前要先查那個編號有沒有人在用(本站的換臉工具會替你查,見本卡最後一段)。
但要先讓 models.big 裡真的有那個編號才算數:剛安裝好的原版
c607–c900 一個項目都沒有(504 張臉全落在 c001–c606),
而封裝檔不能新增項目、只能換掉現有的(見〈做一張新的球員臉皮〉)。
所以在剛安裝好的原版上,可以直接挑的是「封裝檔裡有、名冊裡卻沒人用」的編號,
英文版與中文版兩份量到的都是 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.big 的 7,539 / 7,542,
將近一萬個圖片檔帶著同一句話 —— 只有三個例外。
先講一個很容易數錯的地方
與大頭照不同,這裡一個 .fsh 檔可以裝很多張圖
(實測有裝 36 張、28 張、10 張的)。所以「有幾個檔」跟「有幾張圖」是兩回事:
.fsh 檔案數 2,332 ·
裡面的影像總數 41,343
只數每個檔的第一張圖,會得到完全不同的分佈。下表是走過全部 41,343 張統計的。
| 代號 | 影像數 | 佔比 | 尺寸分佈 |
|---|---|---|---|
| 0x6D | 25,958 | 62.8% | 以 16×32(16,852)與 32×64(6,340)為主,小圖示類 |
| 0x78 | 13,738 | 33.2% | 混合:256×256(3,472)、256×128(2,958)、256×512(2,359) |
| 0x60 | 890 | 2.2% | 全部都是 256×512 ← 這 890 張就是球員臉皮 |
| 0x61 | 591 | 1.4% | 256×256(375)與 128×128(216) |
| 0x7D | 121 | 0.3% | 全部 128×128 |
| 0x7F | 45 | 0.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.big | 2005-01 | 原版 |
| stadium\crosday.big | 2005-02 | 原版 |
| models.big | 2023-05 | 動過 |
| frontend\ingame.big | 2023-02 | 動過 |
| fonts\fonts.big | 2022-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 個 .ord 與
939 個 .orl,成對出現,一個不缺。
把一對解開來看:
| 檔案 | 解壓後 | 開頭四個位元組 |
|---|---|---|
| c001.ord | 44,304 | 7F 45 4C 46 = .ELF |
| c001.orl | 5,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 開頭是 ELF | 939 / 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.big 與
stadium\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 出貨的 | 549 | 66 | —(基準) |
| 社群做的(七批) | 555 | 66 | 555 / 555(100%) |
| 合計 | 1,104 | 66 | 零例外 |
一千一百多個模型,一副骨架,十八年沒有變過。 這就是為什麼任何人做的臉都可以裝進任何一份名冊 —— 大家都是從 EA 的同一個範本改出來的。
⚠️ 但那些臉皮包會蓋掉 EA 自己的球員
同一批包裡的臉皮編號合計 321 個,
而剛安裝好的原版有 504 個臉皮(編號 c001–c606)。兩邊比對:
| 跟原版撞號的 | 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 · jert | 16 位元 | 128 × 128 |
| lega · legb · legc · legd | 16 位元 | 128 × 256 |
| chst · merf · shn1 | 16 位元 | 128 × 128 |
| hat · hlm1 · shoe · slvl · slvr | 16 位元 | 128 × 64 |
| mslv | 16 位元 | 64 × 128 |
| aslv · bglb · bglt · merk | 16 位元 | 64 × 64 |
| wrbn | 16 位元 | 32 × 32 |
| msk2 | 16 位元 | 8 × 8 |
| hhlm · llod · msk1 | 16 位元 4444(有透明度) | 128 × 128 |
| msk3 | 16 位元 4444 | 64 × 32 |
| lace | 16 位元 4444 | 32 × 32 |
28 張裡一張 DXT 都沒有 —— 全部是 16 位元, 其中 5 張用帶透明度的 4444 格式(頭盔遮罩、鞋帶、幾張遮罩圖)。 像素格式的意義見圖片像素編碼。
📌 重點整理
- 一句話 535.9 MB 的
models.big是全遊戲最大的封裝檔,4,211 個項目全部是 QFS 壓縮、目錄涵蓋率 100.0%、孤兒 0 bytes,裡面是球員的臉、身體與球衣。 - 本頁最大的一次訂正:方向剛好反過來。本頁原本把測試機那 890 張
0x60256×512 當成「規格」、4 張0x78128×256 當成「例外」;拿剛安裝好的原版重量,EA 出貨的 504 張臉皮全部是0x78128×256,零例外。同一段還訂正過一次假的全稱句:原本寫「0x60是 EA 沒有用過的格式」,實際上logos.big有 920 張0x61、bkgnds.big有 105 張0x60,正確講法要加限定詞「在這個倉庫裡沒有用過」。孤兒那一格也訂正過:原本寫「只有 0.1 MB」,那 73,322 bytes 其實是檔頭加目錄,真正的孤兒是 0 bytes。 - 原廠球衣的規格硬得驚人 433 個
u###x.fsh,每個都是 28 張貼圖、解壓後都是 732,592 bytes,433/433 分毫不差,「名稱+像素格式+尺寸」的組合只有 1 種;會變的只有子圖排第幾(8 種順序)。所以寫腳本要照名字找,不能照位置找。順帶一個很容易數錯的地方:一個.fsh可以裝很多張圖,2,332 個檔裡總共有 41,343 張。 - 哪一張臉是哪一位球員
attrib.dat的face欄存的就是臉皮編號。3,247 位球員的 699 個不同編號有 698 個對得到(99.9%),唯一對不到的219正好是缺號之一,也就是有球員指向一張不存在的臉。編號分三段:c001–c606是 EA 用掉的、c607–c900在剛安裝好的原版沒有任何球員指過來、也一張臉都沒有(要封裝檔裡真的有才用得上;裝過模組的名冊會用到這一段,本站測試機有 234 位球員指過來)、901–915 是通用臉。 - 只有兩成球員有自己的臉 測試機 712 人(21.9%)有專屬臉、2,510 人(77.3%)共用那 15 張通用臉,剛安裝好的原版還更高,84.1%。光是編號
903一個就有 613 位球員在用。所以要幫某人做專屬臉,除了做出c###那三個檔,還得把他attrib.dat的face改成那個編號。 - 一副骨架撐了十八年 原版
models.big裡 549 個.orl(504 個臉皮c###+ 45 個g###)每個都是 66 根骨頭、骨名集合只有 1 種,連dudeWheresMyHead這個開發者玩笑和LCollerBone這個拼錯都 549/549 跟著出貨。七批社群臉皮包(2005 到 2023)的 555 個模型也是 555/555 跟 EA 逐字相同。這就是不同人做的臉可以互換的根本原因。 - 這份檔案不是原版,而且洩漏了打包的人 裡面有一個
faces.txt,是某人 2013 年 11 月在自己 Windows 電腦上跑目錄列表的輸出,連使用者名稱一起被打包(本站已移除)。判斷手上這份是不是原版,最快的方法是看檔案日期,原版會停在 2005 年。 - 本站沒驗的
.ord的幾何欄位沒有逐欄解讀,接起來知道是一個 MIPS 目標檔,但裡面的機器碼與資料段在做什麼沒有解;為什麼測試機缺那 6 個號碼、那 890 張是誰換成0x60的、photo欄實際用途,都還是未解(2026-09-05 訂正:本頁原本還在這裡列了「把新圖壓縮回去那一半」與「大頭照的編號怎麼對應」,這兩件都已經解開了 —— 見做一張新的球員臉皮與兩套球員編號);2009 年那份模組沒處理的兩個撞號(Rod Carewc442、Lou Gehrigc423)本站沒有實機看過遊戲裡長什麼樣。
接下來
- 大頭照 portrait.big —— 同一套 FSH 格式,結構更單純,建議先看那頁
- 五秒看穿一個檔案 —— 自己動手確認你的檔案有沒有被動過
- BIGF 封裝格式 —— 怎麼安全地寫回去