速查 › FEL 版面語法

FEL 版面語法速查

遊戲的選單、HUD、轉場全部寫在 .fel 版面檔裡。它外面包一層壓縮， 解開後是純文字腳本，每行一個元件。看懂這頁，就能改遊戲裡幾乎所有介面。

先看規模

以比賽中的介面檔 ingame.big 為例，把裡面 47 個 .fel 全部解開後：

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

一個檔案的骨架

每行都是「指令:名稱,一串參數」，縮排代表層級（縮越深包越裡面）。 檔案開頭是版本行，結尾一定是 END:：

VR:78                                 版本行,每個頂層區塊前面都有一行
SC:PITCHERINFO,1,0,0,0,640,480,...    畫面定義,畫布 640×480
 LF:twn14_en.ffn                      載入字型
 LS:ingameov                          載入圖集
 GR:PITCHER,1,0,371,68,254,356,...    群組:投手資訊區
  GR:BACKARTH,1,0,371,68,220,356,...  群組:底圖
   TX:POSITION,1,0,291,276,51,16,...  ← 文字元件,開關在第 1 個參數
END:                                  檔案結束(47 個檔全部如此)

• 頂層（完全不縮排）有五種指令：VR:（版本）、SC:（畫面）、 SF:（引用另一個 .fel）、TS:，再加上每個檔案結尾的 END:。 實測 47 個檔的縮排 0 那一層：VR 504、SC 410、SF 76、END 45、TS 17。 （本站這份檔案裡有 2 個 END: 縮排了 1 格 ——fes_hudleft.fel 與 fes_hudright.fel —— 所以縮排 0 那層只數到 45。EA 原版那 44 個 END: 全部在縮排 0。） 其他全部都掛在某個東西底下。
• VR: 不是只有開頭一行。它出現在每個頂層區塊前面， 47 個檔共 504 行。實測 408/410 個 SC: 的前一行就是 VR:。

參數怎麼看（以 TX 為例）

TX:RATING,1,0,618,391,20,12,1,1,1,1,0,0,hrdbg_en.ffn,3501,0,255,255,255,...
   │      │ │  │   │  │  │                  │        │   │  └ 顏色 RGB(白)
   │      │ │  │   │  │  └ 高 12            │        │   └ 對齊方式
   │      │ │  │   │  └── 寬 20             │        └ 字串編號 3501
   │      │ │  │   └───── Y 座標 391        └ 字型檔
   │      │ │  └───────── X 座標 618
   │      │ └──────────── 保留(此檔一律 0)
   │      └────────────── 顯示開關:1 顯示 / 0 隱藏 ← 最常改的就是它
   └───────────────────── 元件名稱

• 座標系：原點在左上角，X 向右、Y 向下，單位是 640×480 底下的像素。 版面檔一律用這個座標系寫，所以你也永遠填 640×480 的座標。 未驗證 遊戲怎麼把這個座標系換算到你的實際解析度，本站沒有量過 （見介面座標圖的「這張圖不能告訴你什麼」）。
• 字串編號：版面檔不存文字本身，只存編號 —— 真正的文字在文字表 .LOC裡，本站已完整解開。要做中文化不是改這裡； 調位置、關顯示、改顏色才是改這裡。
• 想移走而不是關掉：把 X 改成大於 640（例如 2000），等同移出畫面。
• 欄位數不固定：不同指令欄位數差很多（SE: 只有 1 欄， KA: 有 403 欄）。所以寫程式處理時要先檢查欄位夠不夠，不能直接取第 N 個。

22 個指令完整對照

行數是 ingame.big 全 47 檔的實際統計。「證據」欄說明我們憑什麼這樣解釋：

巢狀規則（這幾條是硬的）

把 22,516 行的每一行跟它的上層對照一遍，有五組是 100% 成立的：

這對你有什麼用：看到 SE: 就往上找 SL:，看到 TE: 就往上找 TL:， 不用猜。反過來說，如果你動了縮排讓這個關係斷掉，那一行大概就失效了。

同一個東西會出現很多次（最容易踩的坑）

你在檔案裡找到要改的那一行，改了、存回去、進遊戲一看 —— 沒變。 十次有八次是這個原因：那個元件在同一個檔案裡有好幾份，你只改到其中一份。

原因是一個 .fel 通常裝了同一塊畫面的許多版本，每個版本各自把元件重畫一次。以左側 HUD 為例：

在 fes_hudleft.fel 裡，好球壞球數那個 TX:BALLS 出現 6 次， 分屬 HUDLEFT、HUDLEFT22、HUDLEFT23 三個畫面。 只改第一個，另外兩個畫面照舊。

群組不記錄「我底下有幾個」

改版面時很容易冒出一個念頭：「我可以直接把整行刪掉嗎？還是父群組會發現少了一個？」

這是可以直接量的。把 4,272 個群組全部按「它自己那行有幾欄」分類，再看每一類的直接子元素數 —— 這裡的「直接子元素」指縮排剛好比它深一層的那些行，不含更深層的孫元素：

3,951 個群組欄位數一模一樣都是 18，可是直接子元素從 0 個到 32 個都有。 欄位數取決於群組的種類，跟它裝了幾個東西完全無關。 另外有 792 個群組底下一個元件都沒有 —— 空群組是合法的。

三條鐵律（踩到會壞檔）

順帶一提：這台機器的檔案裡有兩個錯字 —— 但原版沒有

本站這份 ingame.big 的 22,516 行裡，有兩行的指令是三個字母：

fes_ingameinfobar.fel 第 900 行
     GR:X2Y1,0,0,229,330,64,8,...
      SSH:BARBACK,1,0,77,448,66,16,...      ← 多了一個 S
      SH:POWERBAR,1,0,79,450,62,6,...

fes_hudleft.fel 第 615 行
    GR:COUNT,1,0,10,61,35,13,...
     TTX:BALLS,1,0,53,61,17,25,...        ← 多了一個 T
     TX:STRIKES,1,0,72,61,17,11,...

兩行都緊挨著一個拼寫正確的同類指令，參數結構也完全相同。 TTX:BALLS 甚至就在 TX:STRIKES 上面 —— 那是好球壞球數的顯示。

VS 是直向捲軸（2026-08-29 從「用途未知」升級）

這一頁上線時把 VS 標成「用途未知」，理由是 「只有 9 行，名稱全是 VS1」。 那是樣本太小 —— 上表只算 ingame.big 的 47 個版面檔。 把六個封裝檔的 332 個版面檔全部算進來，VS 有 128 個。

一個 VS 打開來長這樣（fes_savesys.fel，存檔畫面）：

GR:VSCROLL,1,0,560,156,20,194,…
  VS:VS1,1,0,560,156,20,194,…
    BU:SU,…                 ← 上捲按鈕
      SH:BN … sup0          ← 平常
      SH:BP … sup1          ← 按下去
      SH:BH … sup1          ← 滑鼠移上去
    SH:SB  … sldv          ← 軌道
    BU:SD,…                 ← 下捲按鈕
      SH:BN … sdn0
      SH:BP … sdn1
      SH:BH … sdn1
    SH:SS  … sldb          ← 滑塊

真正的證據是貼圖的名字，不是數量。

結構本身也一致到不像巧合：

• 128 / 128（100%）的直屬子元素組合都是 BU:SU + SH:SB + BU:SD + SH:SS（上捲鈕、軌道、下捲鈕、滑塊）
• 127 / 128（99.2%）的父群組直接叫 GR:VSCROLL。 剩下 1 個在 GR:PLAYBYPLAY 底下 —— 那是播報文字的捲動區，同樣說得通

上表 VS 那一列的「9」維持不變 —— 那一欄算的是 ingame.big。本節的 128 是把六個封裝檔全部算進來的。 口徑說明見這裡。

（2026-09-05 訂正：本節原本寫 VS 有 228 個。 那個數字是掃了本站測試機資料夾裡的每一個 .big 算出來的， 而那台機器上除了 frontend.big，還躺著一份逐位元組相同的副本 （兩者 SHA-256 完全一樣），於是同一份東西被數了兩次。 照本站一貫的「六個封裝檔、332 個版面檔」口徑重量是 128 個， 上面的貼圖次數、子元素組合、父群組與 X 座標範圍都已跟著重量。 結論不變：VS 是直向捲軸。）

📌 重點整理

• 一句話 .fel 外面包一層壓縮，解開後是純文字腳本，每行一個元件、縮排代表層級，名稱後面第 1 個參數就是顯示開關，看懂這頁就能改遊戲裡幾乎所有介面。
• 規模 ingame.big 47 個版面檔、22,516 行、410 個畫面、22 種指令、4,272 個群組，壓縮前後 1,560,268 → 195,999（壓到 13%）。座標一律填 640×480 的值（遊戲怎麼把它換算到你的實際解析度，本站沒有量過）；想移走而不是關掉，把 X 改成大於 640 即可。
• 最容易踩的坑 同一個元件在同一個檔裡有好幾份。fes_hudleft.fel 的 TX:BALLS 出現 6 次、分屬三個畫面；fes_ingamesettings.fel 的 SH:F5 出現 191 次。所以定位要用「檔名 ＋ 行號」或「畫面代號 ＋ 上層群組路徑」，不要用名字。
• 五條 100% 成立的巢狀規則 SE 掛 SL 1684/1684、TE 掛 TL 563/563、FR 掛 FC 3605/3605、LF 掛 SC 142/142、SC 一定在頂層 410/410。另一件量得出來的事：群組不記錄自己底下有幾個，3,951 個同樣是 18 欄的群組，直接子元素從 0 個到 32 個都有，還有 792 個空群組。
• 本站訂正過的兩處 指令表原本寫「VR 固定 78」與「TS 是編譯時間」，重量後兩條都不對，VR 實際有 78 / 71 / 69 三種值，TS 那 17 行內容一模一樣都是 TS:CROPLOGOS,，不可能是時間戳。錯字那一節原本叫「原廠檔案裡有兩個錯字」，拿原版一驗也不成立：原版全遊戲 329 個版面檔一個三字母指令都沒有，而錯字所在的 fes_ingameinfobar.fel 在原版的 ingame.big 裡根本不存在（原版只有 44 個版面檔）。
• 第三處訂正順便推翻了自己寫的佐證 VS 從「用途未知」升級成直向捲軸，原因是樣本太小（上表只算 ingame.big 的 9 個，把六個封裝檔的 332 個版面檔全部算進來才是 128 個 —— 這個數字 2026-09-05 訂正過，原本寫 228 是把 frontend.big 與測試機上另一份逐位元組相同的副本各數了一次）。真正的證據是貼圖名字 sup0／sdn0／sldv／sldb，加上 128/128 的子元素組合相同、127/128 的父群組叫 GR:VSCROLL。而本站內部筆記寫過的「VS 的 X 座標貼著畫面左右邊」實測不成立：128 個的 X 落在 19 到 600，貼左緣 0 個、貼右緣 0 個，正確講法是貼在它服務的那個面板側邊。
• 三條鐵律 一、存回 .big 只能接到檔尾，本站測試機那份 ingame.big 全檔 2,665,562 bytes 但目錄只指到 195,999（7.4%），重新打包會把其餘 92.6% 靜悄悄丟掉（實測 2.5 MB 變 198 KB，不會有任何錯誤訊息）；剛安裝好的原版是 167,682 bytes、44 個版面檔、孤兒只有 0.04%，所以這條的理由是你不知道手上這份被疊過什麼。二、要關單一元素改它自己那行，父群組的開關會被遊戲程式執行時覆寫。三、.fel 全部是 CRLF，47 個檔零混入，改完要確認檔案長度跟改前一模一樣，連檔尾有沒有換行都要先看。
• 本站沒驗的 那兩行三字母指令遊戲拿它們怎麼辦沒有驗證，是哪一個工具或哪一次改動造成的也查不出來；SG 的用途、KA 那 403 欄浮點數都還沒解讀；遊戲怎麼把 640×480 這個版面座標系換算到你的實際解析度，本站也沒有量過。另外附一條方法上的教訓：換行符第一次量錯，因為 datafile.big 裡那 460 個 .txt 全是壓縮的，直接在壓縮位元組裡數會得到一堆假的「混合」，量之前先問「我的量法本身可信嗎」。

接下來

• 介面萬用工具 —— 用名字找到並關掉任何元素，不用手動翻檔案
• ingame.big 47 個版面檔對照 —— 想改哪塊畫面，先找對檔案（可搜尋）
• 介面座標圖 —— 座標欄位畫成圖：哪個元素在畫面哪裡
• 實戰教學：關掉跑壘者速度數值 —— 完整走一次流程
• QFS 壓縮 —— .fel 外面包的那一層