[Bug] BaseLib与RitsuLib同时开启时，会重复执行IMaxHandSizeModifier

[BadPig03]

模块范围

Public API（公开 API）

严重程度

Major / regression（主要问题 / 回归）

发生了什么？

我在BaseLib里设计了一个敌方的状态效果，效果是所有玩家的手牌上限减少4。
在单BaseLib的环境下测试功能正常，但如果额外开启RitsuLib，会发现所有玩家的手牌上限的减少量是8。
经过测试发现，ModifyMaxHandSize函数被调用了两次，currentMaxHandSize参数两次的值分别为10和6。

public int ModifyMaxHandSize(Player player, int currentMaxHandSize)
{
    return currentMaxHandSize - 4;
}

复现步骤

1. 找任意AbstractModel并implement来自BaseLib的IMaxHandSizeModifier接口
2. 定义一个ModifyMaxHandSize函数，如下

public int ModifyMaxHandSize(Player player, int currentMaxHandSize)
{
    return currentMaxHandSize - 4;
}

3. 同时启用BaseLib和RitsuLib进行测试，发现实际减少的手牌上限数量是定义的两倍

期望行为

所有玩家的手牌上限减少4。

日志 / 堆栈

RitsuLib 版本

0.2.31

运行环境

Windows 10，sts2 0.105.1，BaseLib 3.1.3

[ritsukage-local-analyzer]

Warning

此分析由 AI 自动生成，仅供开发者参考，最终判断请以人工确认为准。如有疑问建议结合本地环境进一步复现确认。

摘要

同时启用 BaseLib 与 RitsuLib 时，IMaxHandSizeModifier.ModifyMaxHandSize 会被执行两次，导致手牌上限的调节量翻倍。根因是两库在相同 IL 位置安装了互不感知的 transpiler，形成链式嵌套调用 GetMaxHandSize(player, Calculate(player))。建议在 RitsuLib 的 MaxHandSizePatchInstaller.EnsurePatched() 中增加 BaseLib 检测，当 BaseLib 手牌补丁已激活时跳过自身的 transpiler 安装，仅依赖已有的 postfix 桥接机制。

重点结论

• 简单介绍: BaseLib 和 RitsuLib 各自通过 Harmony transpiler 替换游戏原生的最大手牌数常量 10，两者同时激活时，同一处 IL 被两个 transpiler 顺序处理，导致 modifier 执行两遍、手牌上限减少量翻倍（如 -4 变成 -8）。
• 可能原因: RitsuLib 的 MaxHandSizePatchInstaller.EnsurePatched() 无条件安装 transpiler，未检测 BaseLib 是否已对相同方法打了同类补丁。BaseLib 的 transpiler 输出中保留了新的 ldc.i4 10，RitsuLib 的 transpiler 会再次匹配该常量并替换，最终形成 GetMaxHandSize(player, Calculate(player)) 的嵌套调用链。
• 可能解决方案: 在 MaxHandSizePatchInstaller.EnsurePatched() 开头调用 BaseLibMaxHandSizeBridge.IsBaseLibHandSizePatchActive()，若返回 true 则标记 _patched = true 并提前返回。RitsuLib 的 modifier 仍会通过 BaseLibGetMaxHandSizePostfix 桥接生效，不会丢失功能。
• 需要补充: 确认 transpiler 的执行顺序（哪个库的 transpiler 先运行）以验证修复在所有加载顺序下均有效；建议在单 BaseLib、单 RitsuLib、双库共存三种场景下回归测试。

展开详细分析、证据与验证

问题描述

期望行为

所有玩家的手牌上限减少 4（最终上限 = 10 − 4 = 6）。

实际行为

手牌上限减少 8（最终上限 = 2）。ModifyMaxHandSize 被调用两次，第一次 currentMaxHandSize = 10，第二次 currentMaxHandSize = 6（即第一次的结果）。

复现步骤

1. 任意 AbstractModel 实现 BaseLib.Hooks.IMaxHandSizeModifier
2. ModifyMaxHandSize 中返回 currentMaxHandSize - 4
3. 同时启用 BaseLib 3.1.13 和 RitsuLib 0.2.31，观察手牌上限实际减少了 8

环境与版本

• OS: Windows 10
• STS2 版本: 0.105.1
• BaseLib: 3.1.13
• RitsuLib: 0.2.31

详细分析依据

问题涉及三组关键代码路径：

1) BaseLib 的 transpiler（sts-2-baselib/Patches/Hooks/MaxHandSizePatches.cs）

在 CheckIfDrawIsPossibleAndShowThoughtBubbleIfNot、SetupPlayerTurn 等方法的 transpiler 中，将 ldc.i4 10 替换为：

ldarg.0           // player
ldc.i4 10         // 保留原常量（导致后续冲突的关键！）
call MaxHandSizePatch.GetMaxHandSize(player, baseValue)

GetMaxHandSize 遍历所有 BaseLib.Hooks.IMaxHandSizeModifier 实现并依次调用 ModifyMaxHandSize 和 ModifyMaxHandSizeLate。

2) RitsuLib 的 transpiler（Combat/HandSize/MaxHandSizePatchInstaller.cs）

在完全相同的方法上，将 ldc.i4 10 替换为：

ldarg.0
call MaxHandSizeCalculator.Calculate(player)

Calculate 内部调用 BaseLibMaxHandSizeBridge.TryGetMaxHandSizeFromBaseLib() 获取 BaseLib 计算值，再叠加 RitsuLib 自己的 modifier（通过 ApplyHookListenerModifiers）。

3) 冲突链的形成

两个 transpiler 作用于同一原始 IL。当 BaseLib 先执行时，其输出中保留了 ldc.i4 10；RitsuLib 的 IsMaxHandSizeToken() 会再次匹配该常量并替换，最终 IL 变为：

ldarg.0              // player (BaseLib 注入)
ldarg.0              // player (RitsuLib 注入)
call Calculate       // 返回 BaseLib 计算后的值 (10−4=6)
call GetMaxHandSize  // 以 6 为基值再算一次 (6−4=2)

结果 = 2，即减少量翻倍。

当 RitsuLib 先执行时，ldc.i4 10 被替换为 call Calculate，后续 BaseLib transpiler 找不到 ldc.i4 10，不做改动——此场景下单次应用，功能正常。因此问题是否触发取决于 transpiler 先后顺序，而该顺序受 BepInEx 加载顺序影响（"BaseLib" 字母序在前，通常先加载）。

4) RitsuLib 已有的桥接机制（Combat/HandSize/BaseLibMaxHandSizeBridge.cs）

RitsuLib 已通过 BaseLibGetMaxHandSizePostfix 在 BaseLib 的 GetMaxHandSize 上安装了 postfix，能够在 BaseLib 计算完成后叠加 RitsuLib 的 modifier。该 postfix 通过 _suppressPostfixDepth 避免了在 TryGetMaxHandSizeFromBaseLib 调用路径中的递归。也就是说，即使 RitsuLib 不安装自己的 transpiler，其 modifier 仍能通过 postfix 正常生效。

5) 现有检测机制未被利用

BaseLibMaxHandSizeBridge.IsBaseLibHandSizePatchActive() 已能检测 BaseLib 手牌补丁是否激活，但 MaxHandSizePatchInstaller.EnsurePatched() 未曾调用该方法。修复只需在 EnsurePatched() 中增加该检测。

详细验证建议

• 仅启用 RitsuLib 0.2.31，验证手牌 modifier 正常生效
• 仅启用 BaseLib 3.1.13，验证手牌 modifier 正常生效
• 同时启用两者，确认 modifier 被执行两次
• 应用修复后，三场景均回归测试通过
• 验证 ApplyHookListenerModifiers 内的 Distinct(ModifierReferenceComparer) 引用去重逻辑正常工作（与本次问题无关，属防御性检查）

风险与未决

• transpiler 顺序依赖 BepInEx 加载顺序，不同用户环境可能存在差异；问题可能表现为间歇性或环境相关
• 若将来有第三方库对同一方法安装 transpiler，类似的冲突模式可能重现
• 修复方案仅跳过 RitsuLib 的 transpiler，需确保 BaseLibGetMaxHandSizePostfix 在所有调用路径上均能触发（当前覆盖了 BaseLib 的 GetMaxHandSize(Player) 单参重载，但 GetMaxHandSize(Player, int) 双参重载未直接覆盖——好在所有 transpiler 替换点均调用单参版本，且单参内部委托给双参，postfix 涵蓋完整）

---

English translation

Summary

When both BaseLib and RitsuLib are enabled, IMaxHandSizeModifier.ModifyMaxHandSize executes twice, doubling the intended hand-size adjustment. Root cause: both libraries install mutually-unaware transpilers on the same IL locations, forming a chained nested call GetMaxHandSize(player, Calculate(player)). The fix is to add a BaseLib detection check in RitsuLib's MaxHandSizePatchInstaller.EnsurePatched() so that RitsuLib skips its own transpiler installation when BaseLib's hand-size patches are already active, relying instead on the existing postfix bridge.

Key Takeaways

• Brief description: BaseLib and RitsuLib each use Harmony transpilers to replace the native max-hand-size constant 10. When both are active, the same IL site is processed by both transpilers sequentially, causing the modifier to execute twice and doubling the hand-size reduction (e.g., −4 becomes −8).
• Probable cause: RitsuLib's MaxHandSizePatchInstaller.EnsurePatched() unconditionally installs transpilers without checking whether BaseLib has already patched the same methods. BaseLib's transpiler output preserves a new ldc.i4 10 instruction, which RitsuLib's transpiler re-matches and replaces, resulting in the nested call chain GetMaxHandSize(player, Calculate(player)).
• Suggested fix: At the start of MaxHandSizePatchInstaller.EnsurePatched(), call BaseLibMaxHandSizeBridge.IsBaseLibHandSizePatchActive(). If it returns true, set _patched = true and return early. RitsuLib's modifiers will still apply via the BaseLibGetMaxHandSizePostfix bridge, so no functionality is lost.
• Additional information needed: Verify transpiler execution order (which library's transpiler runs first) to confirm the fix works under all load orders. Regression testing across three scenarios is recommended: BaseLib-only, RitsuLib-only, and both enabled.

Expand detailed analysis, evidence, and verification

Problem description

Expected behavior

All players' max hand size is reduced by 4 (final limit = 10 − 4 = 6).

Actual behavior

Max hand size is reduced by 8 (final limit = 2). ModifyMaxHandSize is called twice: first with currentMaxHandSize = 10, second with currentMaxHandSize = 6 (the result of the first call).

Steps to reproduce

1. Have any AbstractModel implement BaseLib.Hooks.IMaxHandSizeModifier
2. In ModifyMaxHandSize, return currentMaxHandSize - 4
3. Enable both BaseLib 3.1.13 and RitsuLib 0.2.31; observe that the actual hand-size reduction is double the defined amount

Environment & version

• OS: Windows 10
• STS2 version: 0.105.1
• BaseLib: 3.1.13
• RitsuLib: 0.2.31

Detailed analysis

The issue involves three key code paths:

1) BaseLib's transpiler (sts-2-baselib/Patches/Hooks/MaxHandSizePatches.cs)

In the transpilers for CheckIfDrawIsPossibleAndShowThoughtBubbleIfNot, SetupPlayerTurn, and others, ldc.i4 10 is replaced with:

ldarg.0           // player
ldc.i4 10         // original constant preserved — this is the key conflict point
call MaxHandSizePatch.GetMaxHandSize(player, baseValue)

GetMaxHandSize iterates all BaseLib.Hooks.IMaxHandSizeModifier implementations and calls ModifyMaxHandSize and ModifyMaxHandSizeLate in sequence.

2) RitsuLib's transpiler (Combat/HandSize/MaxHandSizePatchInstaller.cs)

On the exact same methods, ldc.i4 10 is replaced with:

ldarg.0
call MaxHandSizeCalculator.Calculate(player)

Calculate internally calls BaseLibMaxHandSizeBridge.TryGetMaxHandSizeFromBaseLib() to obtain BaseLib's computed value, then layers RitsuLib's own modifiers on top via ApplyHookListenerModifiers.

3) How the conflict chain forms

Both transpilers target the same original IL. When BaseLib runs first, its output preserves ldc.i4 10; RitsuLib's IsMaxHandSizeToken() re-matches that constant and replaces it, resulting in final IL:

ldarg.0              // player (injected by BaseLib)
ldarg.0              // player (injected by RitsuLib)
call Calculate       // returns BaseLib-computed value (10−4=6)
call GetMaxHandSize  // recomputes with 6 as base (6−4=2)

Result = 2, i.e., reduction doubled.

When RitsuLib runs first, ldc.i4 10 is replaced with call Calculate, and the subsequent BaseLib transpiler finds no ldc.i4 10 to match — correct single-application behavior. Thus whether the bug triggers depends on transpiler ordering, which is influenced by BepInEx load order ("BaseLib" alphabetically precedes "RitsuLib", so it typically loads first).

4) RitsuLib's existing bridge mechanism (Combat/HandSize/BaseLibMaxHandSizeBridge.cs)

RitsuLib already installs a postfix (BaseLibGetMaxHandSizePostfix) on BaseLib's GetMaxHandSize via the bridge. This postfix applies RitsuLib modifiers after BaseLib completes its computation. It uses _suppressPostfixDepth to avoid recursion when called from TryGetMaxHandSizeFromBaseLib. This means RitsuLib's modifiers work correctly through the postfix even without RitsuLib's own transpiler patches.

5) Existing detection is unused

BaseLibMaxHandSizeBridge.IsBaseLibHandSizePatchActive() can already detect whether BaseLib's hand-size patches are active, but MaxHandSizePatchInstaller.EnsurePatched() never calls it. The fix is simply to add that check.

Detailed verification

• Enable only RitsuLib 0.2.31 and verify hand-size modifier works correctly
• Enable only BaseLib 3.1.13 and verify hand-size modifier works correctly
• Enable both and confirm the modifier executes twice
• After applying the fix, all three scenarios pass regression testing
• Verify that Distinct(ModifierReferenceComparer) in ApplyHookListenerModifiers works correctly (defensive check, unrelated to this issue)

Risks and unknowns

• Transpiler ordering depends on BepInEx load order, which may vary across user environments; the issue may appear intermittent or environment-dependent
• If third-party libraries install transpilers on the same methods in the future, similar conflict patterns could re-emerge
• The proposed fix skips RitsuLib's transpiler only; must ensure BaseLibGetMaxHandSizePostfix fires on all call paths (it currently covers BaseLib's single-parameter GetMaxHandSize(Player), but not the two-parameter GetMaxHandSize(Player, int) directly — however, all transpiler replacement sites call the single-param version, and the single-param version delegates to the two-param one internally, so the postfix covers the full call chain)

---

工具侧记录

• BAKAOLC/STS2-RitsuLib#40 · 退出码 0 · 进程 594.09s
• deepseek-v4-pro · API 592385ms · 19 轮 · ↓41338 ↑14997 · 缓存读431232 写0 · $0.7972
• MCP available: management tools exposed to Claude.

[BAKAOLC]

/r set wip crit

[BAKAOLC]

dev-build 版本应该已经有了实际的修复
如果你愿意，可以使用对应的 build 版本进行测试
/r set review

[BadPig03]

在dev-build版本里已经进行了测试，实际表现与预期完全一致，未发现任何问题。