按照页面的参数调整，offset=0，map width=46。这是一种窗口条幅动画的形式，按照Tile的编号，现在应该只除了一张图。文件中应该还有其他的图。


Worked for 2m 27s
你判断对了，原因已经定位并修正：

HEXBMAP.R3 不是单段，而是 9 个子条目（同一 LS11 字典下的多压缩段）。
之前页面只解了第一段，所以你看到 offset=0,width=46 只是一张条幅图。

我已更新生成逻辑与页面，支持按条目组织与全量展示：

build_hexbmap_hexbchp_probe.py
index.html
HEXBMAP_HEXBCHP_ANALYSIS.md
当前解析结果：

条目数：9
前 5 条：dlen=230（推荐 46x5）
后 4 条：dlen=528（推荐 48x11）
页面新增：
entry 选择器（可切换单条目渲染）
全条目列表（每条一行自动渲染，230 用 46 宽、528 用 48 宽）
这就能看到你说的“文件里还有其他图”。
如果你要，我下一步可以把这 9 条按用途再分组（窗口底纹/边框/动画帧/遮罩）并给出命名。


1 file changed
Undo
tools/build_hexbmap_hexbchp_probe.py
HEXBMAP.R3 不是单段，而是 9 个子条目（同一 LS11 字典下的多压缩段）。
这个线索是不是也可应用到HEXZCHP的ls11解码上，因为该文件的解析少了很多Tile资源。


Worked for 28s
是的，这个线索很可能可以直接应用到 HEXZCHP.R3，而且我刚做了同口径扫描，结果是阳性。

实测结果（HEXZCHP.R3）：

文件是 LS11，主头条目是你现在用的那段：clen=7741, dlen=10240（= 80 * 128，即 80 tiles）。
在 0x110 后按 12 字节条目继续扫，发现还能稳定解出另外两段：
#1: clen=14114, dlen=22272（= 174 * 128）
#2: clen=16996, dlen=22400（= 175 * 128）
结论：

HEXZCHP.R3 很可能和 HEXBMAP 一样，不是“只有一段”，而是多子条目结构。
你现在“少很多 Tile”的现象，和“只取了条目 #0（80 tiles）”高度一致。
如果你同意，我下一步就把 HEXZCHP 解析脚本改成“多条目模式”（entry 选择 + 合并池渲染 + 与 HEXZMAP 索引覆盖率统计）。


同理，MMAP.R3中是否也有这种情况？