# HEROLL v0.2.8：Start 时序、首版白名单与未知参数闭合报告

> 仅研究 HEROLL 2.0.1。本文是《一骰登天》MVP v0.2.8 的规则覆盖层，不把 MVP 设计值伪装成 HEROLL 原作值。原生调用顺序作为证据保留；产品执行时序以本报告的“MVP冻结顺序”为准。

## 结论

本轮从 HEROLL 2.0.1 的 CSV 配置、IL2CPP 元数据和运行时解密后的 `libil2cpp.so` 中闭合了四项可直接开发的交付：

1. `Start` 正常结算路径的相对调用顺序；
2. 原作规则、MVP 主动偏离、DEMO 默认值对照；
3. Tile、Corner、Blessing 与 96 条 Shop 商品的首版运行时白名单；
4. 原作仍无法确定的边界参数及唯一 MVP 默认值。

最重要的修正是：v0.2.7 原文中的两段 Start 描述彼此冲突。v0.2.8冻结为下面唯一产品执行顺序：

```text
跨过Start，暂停剩余移动
→ 商店判定与交互
→ 最终Floor/BOSS判定
→ 当前Floor结束奖励
→ 非最终Floor：loopIndex推进并安装商店购买Tile
→ 非最终Floor：AddRandomGoodTiles(loopIndex+2)
→ 非最终Floor：AddRandomEnemyTile(enemyTilesPerLoop,false)
→ 灵泉恢复
→ 写安全点并继续剩余移动
```

HEROLL原作调用链的商店准备、地块注入、商店交互和恢复相对顺序仍保留在证据列；上述产品事务顺序属于《一骰登天》主动覆盖，不能反写为原作顺序。

完整逐步表见 [01-start-settlement-timeline.csv](./01-start-settlement-timeline.csv)。

## 1. Start 结算时序

### 1.1 正常非最终 Floor

开发只读取[01-start-settlement-timeline.csv](./01-start-settlement-timeline.csv)中的MVP顺序。核心约束为：商店先完整交互；再判定最终BOSS；再发Floor奖励；普通分支才推进loop、安装购买Tile并依次刷新Good/Enemy；最后恢复并继续剩余移动。原生地址只用于说明来源差异，不覆盖本次产品时序决策。

`AddNextLoopTiles(loop)` 内部顺序为：

```text
await AddRandomGoodTiles(loop + 2)
await AddRandomEnemyTile(enemyTilesPerLoop, false)
```

`loop+2` 是尝试次数，不是保证成功的新增数量。`enemyTilesPerLoop` 的字段和读取偏移已恢复，但场景中的原始序列化值没有出现在当前导出资产里，所以不能把 3 或 10 宣称为原作值。

### 1.2 最终 Floor 分支

达到 Default 最终 Floor 或 DiceGauge 50/50 的最终转换条件时：

1. 不继续普通 Good / Enemy 注入；
2. 保存 Boss 前棋盘快照；
3. 清空全部外侧房屋，并将 44 个位置转换为 Boss Tile；
4. MVP保留`remainingSteps`并在新Boss棋盘继续移动；
5. 若剩余步数归零后的新最终落点位于Boss Tile，则进入Boss战；
6. 若转换时剩余步数已经为0，则必须再Roll一次并完成新的Boss Tile最终落点。

`SaveBeforeBossTiles` 的直接调用点为 `0x5545124`。最终转换时剩余步数是否在原作所有模式都以同样方式处理，现有证据没有完全闭合，因此“清零”仍标为 MVP 默认，而不是原作确认。

## 2. 首版内容 ID 白名单

### 2.1 Tile 与 Corner

首版真正启用 33 个 `newtile.csv` ID：

| 运行域 | ID |
| --- | --- |
| 核心棋盘 | `100,101,102,103,104,118,119,124,132,133,134,135` |
| DiceGauge 压力扩展 | `105,106,110,111,112,113,114,115,116,117` |
| Corner | `125,127,128,129,131` |
| Good Event | `137,141,143,151,164,169` |

对应关系：

- `124` AUGMENT；
- `125` Wall of Thorns / 天罚；
- `127` Race / 竞天台；
- `128` Flower Garden / 灵圃；
- `129` Housing Support / 营造司；
- `131` Black Market / 黑市散摊；
- `137` Forge；`141` Chest；`143` Dice Battle；`151` Claw Machine；`164` Dicereel；`169` Lucky Scratch。

原作有 8 条 `isEnabled=true` 的 Corner：`125,126,127,128,129,131,167,175`。v0.2.8启用其中 `125,127,128,129,131`；`126` Piggy Bank、`167` Dice Catapult、`175` Warp 不进入首版。这是主动裁剪，不是原作禁用。

`129 Housing Support`落点时掷两枚独立D6，点数和为基础建设次数；实际建成数受下一条顺时针棋盘边的空闲外侧槽数量限制。每格外侧最多1栋，房屋不覆盖底层地块并持续到最终BOSS Floor。原作的房屋到点数换算尚未恢复，MVP冻结为每成功建成1栋获得1灵石。逐字段规则见[06-building-rules.csv](./06-building-rules.csv)。

原作 `169` 的自然生成门槛是 `minStage=1,minLoop=3`。为了在 Stage 0 玩法验证中实际覆盖 Lucky Scratch，首版验证配置将它覆盖为 `minStage=0,minLoop=0`；正式还原配置必须恢复原门槛。`143` 与 `164` 仍保留原作 `minLoop=3`，调试台可以强制触发。

### 2.2 Blessing

原作主模式启用 31 条祝福，基础 `prob_weight` 均为 10。首版候选池冻结为 28 条：

```text
100,102,103,108,109,110,111,112,113,114,115,116,117,118,
121,122,124,125,126,132,147,148,149,150,151,152,153,154
```

首版关闭：

| Blessing ID | 原因 |
| ---: | --- |
| `106` | 复活系统未实现 |
| `156`、`157` | Burn 状态链未实现；两条必须成对启用或关闭 |

`111 DoubleHeal`由实机确认保留。每层在Natural Double时恢复8%最大生命，重复获得按加法叠加；开发时必须绑定“最终骰子结算得到的Double事件”，不能仅凭UI文案轮询骰面。Forced Double默认不触发。

`152 Urban Planning / 都市计划`随建筑模块启用。它是不可叠加的唯一祝福，每次营造司事件在两骰点数和之外增加2次建设尝试，仍受合法外侧槽数量上限约束。

### 2.3 Shop

原作 96 条商品全部加载为只读目录，首版有 77 条进入运行时槽池：

| 类型 | 启用 Offer ID | 数量 |
| --- | --- | ---: |
| TILE | `100,104,106,108,110` | 5 |
| AUGMENT | `112,113,114,116-140`，不含 `115,141,142` | 28 |
| POTION | `143` | 1 |
| STAT | `152-164` | 13 |
| FIXED | `165-194` | 30 |
| LOTTO | 无 | 0 |
| 合计 |  | **77** |

注意：Lucky Scratch `newtile ID 169` 在原作的 12 条 TILE 商品中没有对应 Offer，首版不得自行捏造一个“原作商品 ID”。它只能来自 Good 牌组、调试强制或之后明确新增的 MVP 商品。

普通商品没有“每买一次自动涨价”。价格上涨只存在于：

- 商店付费刷新：`3 + 2 × k`，即 3、5、7、9……；
- 固定升级链：购买当前独立商品行后切换到下一级独立商品行；
- 黑市：`base + trunc(base × surchargePercent / 100)`，其中百分比尚未知。

逐商品的价格、限购、固定槽顺序、启用状态与禁用原因见 [03-shop-product-whitelist.csv](./03-shop-product-whitelist.csv)。Tile、Corner 和 Blessing 的逐 ID 表见 [02-tile-corner-blessing-whitelist.csv](./02-tile-corner-blessing-whitelist.csv)。

## 3. 原作 / MVP 偏离 / DEMO 默认的使用规则

开发读取顺序必须是：

```text
原作确认规则
→ 若 05 表存在 intentional deviation，则用 MVP 规则覆盖
→ 若原作参数仍 UNKNOWN，则只从 04 表读取一个 DEMO 默认值
```

不能反向把 DEMO 默认值写回“原作规则”。几个最容易误写的项目如下：

| 系统 | 原作 | MVP / DEMO |
| --- | --- | --- |
| 玩家基础生命 | 500 | 100，主动偏离 |
| 战斗节奏 | 实时自动冷却，各存活单位独立计时，间隔为`100/最终攻速` | v0.2.8统一采用原作模型，不再严格交替 |
| 复活 | 原作存在祝福与相关路径 | 首版完全关闭 |
| 药水 | 9 种商品 | 单一恢复丹药 |
| Start 顺序 | 准备商店 → 刷新下一层 → 交互商店 → Heal | MVP 应按该顺序修正，不再沿用旧文本冲突 |
| `enemyTilesPerLoop` | 字段确认、值未知 | 3，DEMO 默认 |
| 建筑 | 两骰点数和为建设次数；原作奖励换算未知 | 外侧独立房屋层；每栋1灵石；都市计划+2次 |
| Blessing | 原作 31 条 | 首版 28 条 |
| Shop | 原作目录 96 条 | 首版槽池 77 条 |
| Boss 中途装备 | 观察到，但阈值未知 | 50% 首次跨越，DEMO 默认 |
| 黑市加价 | 公式确认，百分比未知 | 50%，DEMO 默认 |

完整28项对照见[05-original-vs-mvp-vs-demo.csv](./05-original-vs-mvp-vs-demo.csv)。

## 4. 未知参数默认表的边界

[04-unknown-parameter-mvp-defaults.csv](./04-unknown-parameter-mvp-defaults.csv)给出26个唯一执行值，包括：

- `enemyTilesPerLoop=3`；
- 黑市加价 50%；
- Boss压力采用进场50、每行动+25、满100后倒计时4回合；候选不足4格时不降级，延后转换；
- 压力地块结算后变 Empty，不恢复被覆盖地块；
- 战斗掉落展示容量10，第11件起先进先出替换最旧未处理掉落并给出明确反馈；
- 商店 3 个随机槽等权、无放回；
- Blessing 先过滤再等权无放回 3 选 1；
- Boss 中途装备阈值 50%；
- 普通怪死亡奖励 95:4:1；
- 精英怪 1 件装备，再按 5:2 抽丹药或灵石；
- Dice Battle 平局庄家胜；
- Lucky Scratch 揭示完成阈值 65%；
- Forge 最高升到 Myth，不从 Forge 进入 Arcane。
- Housing Support每成功建成1栋获得1灵石；该值只属于DEMO默认。

这些值中有些适合调参，但在本版本必须只有一个默认值，不能让程序员自行猜测。调试台修改时也必须记录 seed、配置版本和修改项。

## 5. 证据与置信度

主要证据：

- [assembly-csharp.json](../../HEROLL_APK_REVERSE_ONLY/01_core_reverse_archive/metadata/assembly-csharp.json)：类型、字段、方法 token；
- [newtile.csv](../../HEROLL_APK_REVERSE_ONLY/01_core_reverse_archive/resource-tables/extracted/csv/newtile.csv)：Tile 启用、类型与门槛；
- [augment.csv](../../HEROLL_APK_REVERSE_ONLY/01_core_reverse_archive/resource-tables/extracted/csv/augment.csv)：31 条启用 Blessing 与权重；
- [ingameshoplist.csv](../../HEROLL_APK_REVERSE_ONLY/01_core_reverse_archive/resource-tables/extracted/csv/ingameshoplist.csv)：96 条商品；
- [gameconfig.csv](../../HEROLL_APK_REVERSE_ONLY/01_core_reverse_archive/resource-tables/extracted/csv/gameconfig.csv)：`LoopRatio=90,5,1`、`shopRerollCost=3,2` 等全局配置；
- [E-STAGE-NATIVE-001.md](../../work/heroll-stage-2-5/evidence/E-STAGE-NATIVE-001.md)：初始化与 `AddNextLoopTiles` 原生调用证据；
- [stage-floor-rules report](../stage-floor-rules/2026-08-31_逆向-HEROLL关卡楼层分布与刷新规则-report.md)：楼层、Good 牌组与 DiceGauge 压力闭环；
- 运行时解密 `libil2cpp.so`：SHA-256 `AC357FBA5BF8A68BA02829593020F29DA220EAC8D5ECA91212C1A6744B0100DA`。

上面最后一行的哈希必须以 QA 脚本重新计算值为准；若与本机文件不一致，应停止地址复用。地址证据只对当前 HEROLL 2.0.1 样本有效。

本轮没有使用互联网资料。原因不是跳过检索，而是这四组问题都属于特定版本的私有配置与原生执行顺序；公开攻略无法比本地 APK 提供更强证据。无法从本地闭合的项目已经进入“未知参数 MVP 默认表”，没有用网络二手描述冒充源码结论。

## 6. 开发验收

1. 自动测试跨 Start 且带剩余步数：商店层必须先完成下一层注入，再打开商店，关闭后 Heal，最后继续移动。
2. 最终Floor跨Start：不得调用普通Good/Enemy注入；保留`remainingSteps`；44格全部为Boss Tile；剩余步数为0时必须再Roll一次后入战。
3. 对 `02` 白名单逐 ID 强制触发；任何未列入 ID 不得自然生成。
4. 读取 `03` 的 96 行：目录必须全量加载，但只有 `mvp_enabled=true` 的 77 行能进入槽池。
5. Blessing 候选池默认应为 28 条；依赖、唯一、叠加上限过滤在抽取前执行。
6. 商店刷新仅刷新 3 个随机槽；固定槽不变；免费刷新不推进付费刷新计数。
7. 所有 `04` 默认值必须可配置并带 `DEMO default` 标签；日志不可记录为 `source confirmed`。
8. 强制触发`129`：验证两骰、`152`额外+2、无放回槽位选择、无空位分支、跨Floor持续与最终BOSS清理。