黄金天宫客户端反推补充 ¶

文档目的 ¶

本文件专门整理客户端中关于“黄金天宫”阶段的硬编码结构、协议字段和双败流转线索。

这部分内容与普通五岛周赛/月赛不同，客户端里已经存在较多专门逻辑，因此值得单独拆开。

一、黄金天宫的正式阶段类型 ¶

客户端枚举直接定义了黄金阶段的三个正式赛制类型：

• Configs.js

已确认：

• GOLDEN_VICTOR = 24
• GOLDEN_LOOSER = 25
• GOLDEN_FINAL = 26

地图类型也单独拆出：

• Configs.js

已确认：

• GOLDEN_VICTOR_MAP = 22
• GOLDEN_LOOSER_MAP = 23
• GOLDEN_FINAL_MAP = 24

结论：

• 黄金天宫在客户端不是“一个大阶段”，而是三个独立 war type + map type 组合。

二、黄金天宫的参赛规模 ¶

客户端规则文案已写明：

• language.json 中 XYC_IMG_RULE7

已确认：

• 黄金天宫只由紫青月宫晋升俱乐部构成。
• 总量为 80 家俱乐部。
• 采用双败赛制。
• 失败 2 场的俱乐部将结束天宫赛程并淘汰至秘蓝岛。

结论：

• 服务端必须为黄金阶段单独维护“失败次数”或等价状态，普通岛屿积分赛模型不够。

三、客户端里的黄金杯位结构 ¶

黄金阶段页面不是按抽象列表渲染，而是显式布置了胜者、败者、总决赛杯位。

来源：

• LegionWarExLeagueStage2.js

客户端会创建这些杯位：

• 胜者赛：
  • m_cupWeekWin0
  • m_cupWeekWin1
  • m_cupWeekWin2
• 败者赛：
  • m_cupWeekFail0
  • m_cupWeekFail1
  • m_cupWeekFail2
• 总决赛：
  • m_cupMonthWin
• 额外还有：
  • m_cupFlag

对应的数据对象 b.create(type, groupIndex) 会保存：

• type
• groupIndex
• date

并通过 riseKey / cupKey = type + "_" + groupIndex 与提示文案绑定。

结论：

• 客户端把黄金天宫视为多周、多轨道 bracket，而不是只显示“当前周一个比赛”。

四、黄金阶段的分组数量 ¶

黄金页面的数据对象 b 内部有两组固定数组：

• LegionWarExLeagueStage2.js

已确认：

• winGroupIds = [4, 2, 1, 1, 1, 0]
• failGroupIds = [4, 2, 2, 1, 1, 0]

groupId 规则：

• 若 type == GOLDEN_LOOSER，取 failGroupIds[groupIndex]
• 若 type == GOLDEN_VICTOR，取 winGroupIds[groupIndex]
• 若 type == GOLDEN_FINAL，固定 1

结合杯位创建代码，可得到目前客户端展示的 bracket 规模：

• 第 1 周胜者赛：4 组
• 第 2 周胜者赛：2 组
• 第 3 周胜者赛：1 组
• 第 2 周败者赛：2 组
• 第 3 周败者赛：2 组
• 第 4 周败者赛：1 组
• 总决赛：1 组

客户端分组标题也按字母组命名：

• LegionWarExLeagueStage2.js
• language.json

已确认：

• 胜者组标题格式：胜者{A-F}组
• 败者组标题格式：败者{A-F}组

结论：

• 黄金天宫的 bracket 形状，客户端已经隐含给出：
  • 80 俱乐部先打成 4 个胜者组
  • 之后逐周压缩到 2 组、1 组
  • 败者线在中间承接，最终和胜者线汇入总决赛

五、黄金阶段的每周晋级提示 ¶

客户端和服务端语言表里已经给出每周提示文案。

来源：

• language.json
• language.json
• LegionWarExLeagueStage2.js

已确认的顶部提示：

• ExLeagueWarStage4_TopTips_Win1
  • 第1周比赛各小组前10可保级胜者赛
• ExLeagueWarStage4_TopTips_Win2
  • 第2周胜者赛各小组前10可保级胜者赛
• ExLeagueWarStage4_TopTips_Lose2
  • 第2周败者赛各小组前10可保级败者赛
• ExLeagueWarStage4_TopTips_Win3
  • 第3周胜者赛前10可晋级总决赛
• ExLeagueWarStage4_TopTips_Lose3
  • 第3周败者赛各小组前5可保级败者赛
• ExLeagueWarStage4_TopTips_Lose4
  • 第4周败者赛前10可晋级总决赛
• ExLeagueWarStage4_TopTips_Final
  • 争夺冠军，成为伟大航路之王

已确认的阶段说明提示：

• LegionWarExLeagueWarStage4Tips_Win1
  • 天宫首场比赛将于本周六打响
• LegionWarExLeagueWarStage4Tips_Win2
  • 第1周比赛各组前10可保级胜者赛
• LegionWarExLeagueWarStage4Tips_Lose2
  • 第1周比赛各组后10将参与败者赛
• LegionWarExLeagueWarStage4Tips_Win3
  • 第2周胜者赛各组前10可保级该周胜者赛
• LegionWarExLeagueWarStage4Tips_Lose3
  • 第2周胜者赛各组后10、第2周败者赛各组前10将参与该周败者赛
• LegionWarExLeagueWarStage4Tips_Lose4
  • 第3周胜者赛后10、第3周败者赛各组前5将参与该周败者赛
• LegionWarExLeagueWarStage4Tips_Final
  • 第3周胜者赛前10、第4周败者赛前10荣获总决赛参赛资格

结论：

• 客户端已经把黄金双败的每周流转提示到足够细。
• 即便服务端当前还没实现，状态机也不应该再从零设计，而应优先对齐这套周级流转。

六、可反推出的黄金双败结构 ¶

根据上述杯位数量和提示文案，可以还原出一个高可信度的客户端目标结构：

80俱乐部
  -> 第1周胜者赛，4组，每组20
     -> 每组前10留在胜者线，共40
     -> 每组后10掉入败者线，共40

  -> 第2周胜者赛，2组，每组20
     -> 每组前10留在胜者线，共20
     -> 每组后10掉入败者线，共20

  -> 第2周败者赛，2组，每组20
     -> 每组前10留在败者线，共20
     -> 每组后10淘汰，共20

  -> 第3周胜者赛，1组，20
     -> 前10进总决赛
     -> 后10掉入败者线

  -> 第3周败者赛，2组
     -> 每组前5保级第4周败者赛，共10
     -> 其余淘汰

  -> 第4周败者赛，1组，10
     -> 前10进总决赛

  -> 总决赛，1组，20
     -> 决出冠军与剩余排名

这是“基于客户端结构的强推断”，不是当前服务端已实现事实。

但它与以下证据一致：

• 80 家俱乐部总量
• 第1周前10 / 后10分流
• 胜者线 4 -> 2 -> 1
• 败者线 2 -> 2 -> 1
• 第3周胜者赛前10进决赛
• 第4周败者赛前10进决赛

七、黄金排行与淘汰字段 ¶

黄金阶段总排行接口直接暴露了淘汰态字段。

来源：

• data-index.js
• LegionWarExLeagueGoldenRankScoreDialog.js

已确认：

• GDSaltRoadWarMsg 中包含：
  • sRGroupRank
  • sRTotalScore
  • sRConfId
  • sRGoldenOut
• 黄金排行页会直接根据 sRGoldenOut 显示是否已出局。

另外总排行描述文案：

• language.json

已确认：

• 败者赛淘汰俱乐部将先获排名，总决赛决出剩余排名

结论：

• 服务端至少需要在排行数据中下发“该俱乐部是否已从黄金赛程出局”的布尔字段。
• 黄金总排名不是只在最后一场后一次性生成，败者赛淘汰时已经开始结算部分名次。

八、黄金对阵列表接口 ¶

客户端通过专门接口拉取黄金 bracket 对阵列表。

来源：

• data-index.js
• data-index.js
• LegionWarModule.js

已确认接口：

• 请求：saltroad_getgoldenbflist
• 响应：saltroad_getgoldenbflistresp

响应结构：

• selfBfId
• bfList[]

其中 bfList[] 元素类型 GDSaltRoadGoldenBfInfo 至少包含：

• bfId
• legionWarType

客户端会把它转换成 LegionGoldenBfOpponentInfo：

• bfId
• selfId
• type
• title
• 以及派生属性 isSelf

结论：

• 服务端黄金接口至少需要返回：
  • 当前俱乐部所属 bfId
  • 当前日期下所有黄金 battlefields 的 bfId + legionWarType
• 客户端再基于 selfBfId 判断自己所在分组。

九、黄金阶段的成员资格与锁名单线索 ¶

黄金阶段页面有专门的“锁成员”逻辑。

来源：

• LegionWarExLeagueStage2.js
• data-index.js
• language.json

已确认：

• 战场信息 GDBattlefieldInfo 包含：
  • canEnterWar
  • legionWarMapType
  • battlefieldId
  • battlefieldNumber
  • signupStartTime / signupEndTime / readyTime / startTime / endTime
• 黄金页面中 _isLockedMembers 的判断依赖：
  • 当前是比赛日
  • 当前杯位有 opList[0]
  • opList[0].selfId.length > 0
  • !canEnterWar

提示文案：

• C_WAR16：赛事限本俱乐部登岛成员参与

结论：

• 服务端需要在黄金阶段维护“登岛成员”或等价锁名单概念。
• canEnterWar 不是唯一判断条件，客户端还结合“当前俱乐部是否在该 bf 中”一起控制 UI。

十、黄金阶段的相位提示动画 ¶

客户端会根据 lastDateLegionWarType -> legionWarType 的变化，播放黄金相位提示。

来源：

• LegionWarExLeagueStage2.js
• LegionWarExLeagueWarData.js

可确认的转移：

• goldenVictor -> goldenVictor
  • 胜者线保级
• goldenVictor -> goldenLooser
  • 从胜者线掉到败者线
• goldenLooser -> goldenLooser
  • 败者线保级
• goldenVictor / goldenLooser -> goldenFinal
  • 进入总决赛

结论：

• 黄金阶段在客户端看来，最少存在以下状态转移：
  • 胜者保级
  • 胜者掉败者
  • 败者保级
  • 进总决赛
• 这与双败赛制的标准状态机是一致的。

十一、对服务端最直接的实现要求 ¶

从客户端黄金逻辑看，服务端后续最少要补这些能力：

1. 返回当前日期的黄金 battlefields 列表。
2. 返回当前俱乐部所属 selfBfId。
3. 区分 goldenVictor / goldenLooser / goldenFinal 三种 war type。
4. 维护黄金淘汰标记 sRGoldenOut。
5. 维护登岛成员锁名单，并正确驱动 canEnterWar。
6. 维护双败流转状态，至少支持：
   • 胜者保级
   • 胜者掉败者
   • 败者保级
   • 进入总决赛
   • 失败两场后淘汰至秘蓝岛

十二、仍未完全闭合的点 ¶

即使客户端里信息已经很多，仍有几个关键点不能只靠客户端 100% 确认：

• 第 2 周败者赛的原始入场名单精确拼接顺序。
• 第 3 周败者赛两组的具体来源分配规则。
• 第 4 周败者赛是否只有 10 俱乐部，还是还有额外重排逻辑。
• 总决赛 20 家后的最终名次分配是否还有额外规则。
• 黄金阶段奖励发放的具体时点和幂等策略。

这些部分仍需要对照服务端配置和未来实现约束补足。