HEROLL/HEROLL_RULES_v0.2.8/规则闭合报告_v0.2.8.md

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冻结为下面唯一产品执行顺序：

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

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

完整逐步表见 01-start-settlement-timeline.csv。

1. Start 结算时序

1.1 正常非最终 Floor

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

AddNextLoopTiles(loop) 内部顺序为：

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。

原作 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 条：

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。Tile、Corner 和 Blessing 的逐 ID 表见 02-tile-corner-blessing-whitelist.csv。

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

开发读取顺序必须是：

原作确认规则
→ 若 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。

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

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：类型、字段、方法 token；
• newtile.csv：Tile 启用、类型与门槛；
• augment.csv：31 条启用 Blessing 与权重；
• ingameshoplist.csv：96 条商品；
• gameconfig.csv：LoopRatio=90,5,1、shopRerollCost=3,2 等全局配置；
• E-STAGE-NATIVE-001.md：初始化与 AddNextLoopTiles 原生调用证据；
• stage-floor-rules report：楼层、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清理。