SeymourBETA更新 2.234
2026/8/18
v2.234.0.0BETAMINOR
Seymour2026年8月18日
Seymour2026年8月18日在 Aurora 中的持久化 HD 怪物模型：340 個 `.chr`→glTF 烘焙 (Phyre HD 網格 + PS2 骨架 + `.mgrp` 動作) 已貼圖/已動畫，Y-up，已提交 + 持久化 repo-relative 路徑
- 烘焙重新生成 (從提交
phyre_chr_gate恢復的a731de5f管線)：340/341 個怪物具有真實網格，328 個已貼圖，237 個具有 PS2 動畫 (18–25 個r0g0_..片段)，340 個 Y-up (--flip-y=flip_rootnode rotation [1,0,0,0] = 180° X). Onlym999(test dummy slot, no mesh) skipped. - 持久化 (應要求使最終使用者能看到怪物+貼圖)： 約 892MB 的資產從
work/(已 git 忽略) 移出至RuntimeTools/FFXModelAssets/chr/<id>/(已提交)。無新前綴：Aurora 的 EditViewer 由python -m http.serverAT THE REPO ROOT (python does no prefix-mapping) -> the anchor path is REPO-RELATIVE. 提供 - 編輯器中的錨定路徑：
AuroraChamber_DataModel現在發出/RuntimeTools/FFXModelAssets/chr/m{id:D3}/m{id:D3}_animated.gltf(之前是/work/phyre_chr_anim/models/...)。需要重建編輯器；重新載入 EditViewer 以將敵人視為模型 (不再顯示為球體)。 - 目錄：
RuntimeTools/FFXModelAssets/catalog.json(340 個條目，已動畫/已貼圖標誌)。 - 工具： 可重新產生的執行器
work/phyre_chr_anim/BakeBatch.ps1+ 恢復的工具work/phyre_chr_gate_build/留在work/中 (已 git 忽略)；ASSETS (結果) 已提交。 - 誠實說明 (HD-lane limits)： 貼圖是主要的
.dds.phyre；約 12 個怪物按設計未貼圖 (清單中無tex/)；對於那些沒有自身動作的怪物使用 T-pose (237/340 已動畫)；離線綁定中可能存在殘餘扭轉 (已應用 A1/frame0/matrixParents — 請在畫面上判斷)。AuroraFieldExplorer_ChrModelResolver保留在/work/上 (單獨的 npc/pc/sum/obj/wep 類別，超出範圍)。 - 碰撞合併： 將 PATCH 碰撞
v2.233.1.0(其他工作線，有衝突的 csproj) 合併至 MINOR2.234.0.0；條目位於 CHANGELOG/changelogUS/VERSIONING。 - 關卡： 編輯器建置 0 錯誤 (455 個 pre-existing 警告)；
StringsIntegrityTests3/3 (未受影響)。視覺 RT2 驗證待處理 (重建 + 手動 re-render)。
v2.233.1.0
v2.234.0.1BETAPATCHSeymour2026年8月18日
Seymour2026年8月18日編碼修正 + project-load 崩潰：`FfxEncoding.us.cs` 從基準 (UTF-8 + BOM，正確字元) 重新生成，並對 `UsEncoder` 進行去重（重複的 `char` 鍵導致 `Dictionary<char,byte>` 在 `ArgumentException` 初始化時（即在專案載入期間的 `FfxEncoding`）拋出 `KernelMonsterMagicLiveSync`）；279 個 `.cs` cp1252-ified 已由橫幅腳本轉換為 UTF-8 + BOM（可防止在 SDK-10 的 UTF-8 預設值下出現字串亂碼）
- 崩潰根本原因：
UsEncoder中的FfxEncoding.us.cs有重複的char鍵（pre-existing 潛在錯誤；約 192 個條目）。ADictionary拒絕重複鍵 →FfxEncoding的靜態建構子在首次使用時拋出異常（現在由開啟專案時的KernelMonsterMagicLiveSync.SyncProject觸發）。修正方式：從基準 (us.cs) 重新生成d91986a1，並對 first-wins 進行UsEncoder去重。基準中原本就有 56 個重複鍵——潛在的，現在才暴露出來。 - 亂碼： 橫幅腳本移除了 BOM 以及含有高位元組的 cp1252-ified UTF-8 檔案。279 個
.cs已轉換為 UTF-8 + BOM（無損），因此 SDK-10（將 BOM-less 解讀為 UTF-8）能正確解碼字串。 - 閘門： 建置 0 個錯誤；編輯器開啟並載入專案時無崩潰。
v2.234.0.0
v2.234.1.0BETAPATCH
Yuna2026年8月18日
Yuna2026年8月18日Aurora RealGame: content-similarity 回退方案 於 `EncounterIndexBridge`; 針對無 RealGame 0e/ bin 的戰鬥解鎖 開啟 byte-identical
- 根本原因: 開啟 RealGame「根本打不開」因
bika02_00，因為EncounterIndexBridge.TryResolve需要 byte-identical SHA-256 匹配到0e/<id>.bin。在858場原始戰鬥中，僅有614場 hash-match 了無剪輯 0e/ 提取 (817個 bin)；244場保持 SEM MATCH →BuildBattleUrl回傳null→ 檢視器視窗從未被建立。 - 修正 (經3個來源證實): 新的 256位元組 block-similarity 回退方案 (FNV-1a, rsync-style) 於
EncounterIndexBridge.Build— 針對每個沒有精確 SHA 的戰鬥，選取與0e/區塊重疊最高的，若比例 ≥MinSimilarityScore(0.50) 則記錄於BattleIdToNearestEncounter，解鎖了 244場未匹配中的191場。TryResolve/IsSimilarityResolved暴露回退方案；Aurora3DLauncher.BuildBattleUrl在狀態中如實報告「近似匹配 (相似度)」。 - 證據: (1) Python
work/probe_bika_v5.py:bika02_00 → 00d0.bin分數 0.98 (91/93 區塊)，全域 191/244 解鎖; (2) Pythonwork/probe_bika_v6.py:bika02_00==00d0.bin在 99.75% 完全相同位元組 且相同怪物 ID — 同一個 SAME 遭遇，只是提取後小了32位元組; (3) C#RuntimeTools/Aurora3DLinkLab(建置+執行 exit 0):bika02_00 -> 0e/00D0.bin via=SIMILARIDADE, 其他探測完好 (azit03_00精確,sfia00_00如實地 SEM MATCH)。 - 閘門: 建置0錯誤 (編輯器 + 實驗室)。未提交 (multi-lane dirty 工作樹 + in-game RT2 待處理)，依工作線 rule.。
0e/覆寫仍保留其.aurora3d.bak備份。
v2.234.0.1