[Bug] 被魔法骑士抑制后，升级带来的次要资源消耗减少不会还原

[iouter]

模块范围

Public API（公开 API）

严重程度

Minor（轻微）

发生了什么？

被魔法骑士抑制后，升级带来的次要资源消耗减少不会还原

我代码是这么写的：
protected void UpgradeNinjutsuValueBy(int addend)
{
DynamicVars.Ninjutsu().UpgradeValueBy(addend);
this.SecondaryResourceUses()
.SpendIfAvailable(RenShu, LexKela.Id, DynamicVars.Ninjutsu().IntValue);
}

然后在OnUpgrade中调用了这个函数。

复现步骤

升级蕾忍的一字切，再让抑制效果将其降级。

期望行为

应当还原成初始的形态

日志 / 堆栈

RitsuLib 版本

0.4.46

运行环境

No response

[ritsukage-local-analyzer]

Warning

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

摘要

升级带来的次要资源消耗减少在“抑制/降级”后仍残留，用户可见结果是卡牌没有回到初始资源消耗形态。影响范围主要是使用 SecondaryResourceUses().SpendIfAvailable(...) 等 RitsuLib sidecar API 维护升级费用的卡牌，当前严重度按 minor/API bug 处理合理。建议优先在降级生命周期中重置或重建次要资源费用/出牌条款，并补一个“升级 → 抑制降级 → 恢复升级”的回归用例。

重点结论

项	结论
简单介绍	升级时通过 RitsuLib 改小次要资源消耗后，被抑制效果降级时，卡牌的次要资源消耗没有恢复到基础形态。
可能原因	较高置信：SecondaryResourceUses/SecondaryCosts 是 RitsuLib 附加状态，官方 DowngradeInternal 只重置原生卡牌字段与 DynamicVars，没有同步重置这些附加费用层。
可能解决方案	在 CardModel.DowngradeInternal 后为 RitsuLib 次要资源状态做 canonical reset/copy；同时为 SpendIfAvailable 这类升级改写 permanent layer 的场景加入回归测试。

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

问题描述

期望行为

• 升级后的“一字切”被抑制效果降级后，应恢复到未升级时的次要资源消耗/显示形态。
• 抑制结束再次恢复升级时，再按升级后的数值生效。

实际行为

• 报告者观察到：升级带来的次要资源消耗减少在被抑制降级后没有还原，基础形态仍保留升级后的消耗设置。

复现步骤

1. 升级蕾忍的“一字切”。
2. 让“抑制”效果将其降级。
3. 查看该牌的次要资源消耗是否回到初始值。

环境与版本

• RitsuLib：0.4.46
• 模块范围：Public API（公开 API）
• 运行环境：报告中未提供。

日志、附件与原文摘录

• 原文代码要点：

  DynamicVars.Ninjutsu().UpgradeValueBy(addend);
.SpendIfAvailable(RenShu, LexKela.Id, DynamicVars.Ninjutsu().IntValue);

  • 要点：升级时先改动态变量，再把当前动态变量值写入 RitsuLib 次要资源出牌条款；如果降级没有重建该条款，就容易残留升级值。
• 日志区为空；此问题更像状态生命周期/API 行为不一致，不是崩溃。

详细分析依据

• SpendIfAvailable(string useId, string resourceId, int amount) 会调用 SpendIfAvailable(..., new SecondaryResourceCost(...))，默认 duration 是 SecondaryResourceCostDuration.Permanent：src/Combat/SecondaryResources/SecondaryResourcePlayUses.cs:192-207。
• SecondaryResourcePlayUseSet.Set(...) 对同一 use id/duration 删除旧层再加入新层；也就是说升级代码会把 permanent 层改成升级后的数值：src/Combat/SecondaryResources/SecondaryResourcePlayUses.cs:286-298。
• RitsuLib 已有按 duration 清理的逻辑，但公开路径主要覆盖 UntilPlayed/ThisTurn：src/Combat/SecondaryResources/SecondaryResourcePlayUses.cs:320-333、src/Combat/SecondaryResources/SecondaryResourceCosts.cs:333-348。未看到针对“卡牌被降级”的同类 reset。
• 官方降级流程会把 CurrentUpgradeLevel 置 0，并用 canonical 卡牌重建 _dynamicVars、能量费用、星星费用与关键字，然后触发后续降级处理：official-source/src/Core/Models/CardModel.cs:2135-2147。这些步骤不会自动处理 RitsuLib 的 AttachedState<CardModel, SecondaryResourcePlayUseSet>/SecondaryResourceCostSet。
• 官方 DampenPower 的行为与报告中的“抑制”现象吻合：应用时记录已升级卡的原升级层数并 CardCmd.Downgrade(item)，移除时再循环 CardCmd.Upgrade(card) 恢复升级：official-source/src/Core/Models/Powers/DampenPower.cs:29-36、official-source/src/Core/Models/Powers/DampenPower.cs:58-68。
• 因此最可能的状态序列是：升级时 permanent 次要资源 use 被写成升级值 → 抑制调用官方降级只重置原生字段 → RitsuLib 附加 use 仍保留升级值 → 卡牌显示/支付没有回到基础形态。
• 修复方向应避免只修某个卡牌：建议在 RitsuLib 层 patch 降级生命周期，将 SecondaryCosts 与 SecondaryResourceUses 重置为 canonical 卡牌对应状态，或提供明确的 downgrade hook/API 供卡牌作者在降级时重建。需要注意保留附魔、临时费用层、战斗中 modifier/capability 对费用的合法影响，避免过度清空。

反馈规范性提醒

维度	状态
复现步骤	已提供，但较简略；缺少完整最小卡牌定义、基础/升级数值。
期望/实际	已提供；期望“还原成初始形态”，实际为升级消耗减少残留。
环境与版本	含糊；RitsuLib 版本已提供，运行环境为 _No response_。
日志/附件	缺失；日志代码块为空，不过当前问题不一定需要崩溃日志。
标题与背景	已提供；标题与正文范围一致，指向 Public API 次要资源生命周期。

详细验证建议

• 构造一张测试卡：基础 SpendIfAvailable 消耗为 A，OnUpgrade 后消耗为 B（B < A 或 B != A）。
• 正常升级后确认 UI 与 SecondaryResourcePaymentResolver.Plan(...) 均显示/解析为 B。
• 调用与抑制一致的降级路径（CardCmd.Downgrade/DowngradeInternal），确认 UI 与 plan 回到 A。
• 再按 DampenPower.AfterRemoved 的路径恢复升级，确认 UI 与 plan 再次为 B，且没有重复叠层或残留临时层。
• 补测 SecondaryCosts() 与 SecondaryResourceUses() 两条 API 路径，避免只修可选支付而漏掉硬费用。

风险与未决

• 如果直接清空所有 RitsuLib 附加费用，可能误删运行时临时费用、附魔或其它 modifier/capability 添加的合法层。
• 需要明确 canonical reset 的时机：应在官方降级完成后、附魔/affliction 重新应用前后保持一致，否则可能造成显示与实际支付不一致。
• 若维护者本地无法复现，建议请报告者补充“一字切”的最小卡牌类、基础值/升级值，以及触发抑制的具体敌人与回合状态。

---

English translation

Summary

A secondary-resource cost reduction introduced by an upgrade appears to remain after the card is suppressed/downgraded, so the card does not return to its base resource-cost shape. The likely impact is limited to cards that maintain upgrade-dependent costs through RitsuLib sidecar APIs such as SecondaryResourceUses().SpendIfAvailable(...), and the current minor/API-bug classification looks reasonable. The recommended next step is to reset or rebuild secondary-resource costs/uses during the downgrade lifecycle and add a regression case for “upgrade → suppress downgrade → restore upgrade”.

Key Takeaways

Item	Takeaway
Brief introduction	After an upgrade reduces a card’s secondary-resource spend through RitsuLib, a suppress/downgrade effect does not restore that spend to the base form.
Likely cause	High confidence: SecondaryResourceUses/SecondaryCosts are RitsuLib-attached state, while the official DowngradeInternal path resets native card fields and DynamicVars but does not reset those attached cost layers.
Possible fix	After CardModel.DowngradeInternal, perform a canonical reset/copy for RitsuLib secondary-resource state; also add a regression test for upgrade code that rewrites a permanent SpendIfAvailable layer.

Expand detailed analysis, evidence, and verification

Problem Description

Expected behavior

• After the upgraded “Ichimonji Slash” is downgraded by a suppress effect, its secondary-resource cost/display should return to the unupgraded form.
• When the suppress effect ends and the upgrade is restored, the upgraded value should become active again.

Actual behavior

• The reporter observes that the secondary-resource cost reduction from the upgrade is not reverted after the card is suppressed/downgraded; the base form still carries the upgraded cost setting.

Reproduction steps

1. Upgrade Raining Ninja’s “Ichimonji Slash”.
2. Let a “suppress” effect downgrade it.
3. Check whether the card’s secondary-resource spend returns to the initial value.

Environment and Version

• RitsuLib: 0.4.46
• Module scope: Public API
• Runtime environment: not provided in the report.

Logs, Attachments, and Source Excerpts

• Key excerpt from the reporter’s code:

  DynamicVars.Ninjutsu().UpgradeValueBy(addend);
.SpendIfAvailable(RenShu, LexKela.Id, DynamicVars.Ninjutsu().IntValue);

  • Point: the upgrade first changes a dynamic variable, then writes the current dynamic-variable value into a RitsuLib secondary-resource play use; if downgrade does not rebuild that use, the upgraded value can remain attached.
• The log section is empty. This looks more like a state-lifecycle/API consistency issue than a crash.

Detailed Analysis Basis

• SpendIfAvailable(string useId, string resourceId, int amount) delegates to SpendIfAvailable(..., new SecondaryResourceCost(...)), whose default duration is SecondaryResourceCostDuration.Permanent: src/Combat/SecondaryResources/SecondaryResourcePlayUses.cs:192-207.
• SecondaryResourcePlayUseSet.Set(...) removes the old layer for the same use id/duration and adds a new one, so upgrade code rewrites the permanent layer to the upgraded value: src/Combat/SecondaryResources/SecondaryResourcePlayUses.cs:286-298.
• RitsuLib has duration-based cleanup, but the visible paths cover UntilPlayed/ThisTurn: src/Combat/SecondaryResources/SecondaryResourcePlayUses.cs:320-333, src/Combat/SecondaryResources/SecondaryResourceCosts.cs:333-348. No equivalent reset for “card downgraded” was found in the inspected code.
• The official downgrade flow sets CurrentUpgradeLevel to 0 and rebuilds _dynamicVars, energy cost, star cost, and keywords from the canonical card before running later downgrade handling: official-source/src/Core/Models/CardModel.cs:2135-2147. Those steps do not automatically touch RitsuLib’s AttachedState<CardModel, SecondaryResourcePlayUseSet> / SecondaryResourceCostSet.
• The official DampenPower behavior matches the reported suppress scenario: when applied, it records upgraded cards and calls CardCmd.Downgrade(item); when removed, it loops through the recorded upgrade levels and calls CardCmd.Upgrade(card) to restore them: official-source/src/Core/Models/Powers/DampenPower.cs:29-36, official-source/src/Core/Models/Powers/DampenPower.cs:58-68.
• The most likely state sequence is therefore: upgrade writes the permanent secondary-resource use to the upgraded value → suppress invokes the official downgrade path, which resets native fields only → the RitsuLib-attached use still has the upgraded value → display/payment does not return to the base shape.
• The fix should not be card-specific. Prefer a RitsuLib-level patch of the downgrade lifecycle that resets SecondaryCosts and SecondaryResourceUses to the canonical card’s corresponding state, or expose/provide a downgrade hook/API for card authors to rebuild them. Care is needed to preserve legitimate enchantment, temporary-cost, combat modifier, and capability effects rather than blindly clearing everything.

Feedback Hygiene Reminder

Dimension	Status
Reproduction steps	Provided but terse; the full minimal card definition and base/upgraded values are missing.
Expected/actual	Provided; expected is “return to initial form”, actual is the upgraded cost reduction lingering.
Environment and version	Ambiguous; RitsuLib version is provided, runtime environment is _No response_.
Logs/attachments	Missing; the log block is empty, though crash logs may not be necessary for this state bug.
Title and background	Provided; the title and body consistently point to the Public API secondary-resource lifecycle.

Detailed Verification Suggestions

• Build a test card whose base SpendIfAvailable cost is A and whose OnUpgrade changes the cost to B (B < A or B != A).
• After a normal upgrade, confirm both the UI and SecondaryResourcePaymentResolver.Plan(...) display/resolve B.
• Invoke the same downgrade path used by suppress effects (CardCmd.Downgrade / DowngradeInternal) and confirm the UI and plan return to A.
• Restore the upgrade through the same path as DampenPower.AfterRemoved and confirm the UI and plan become B again, with no duplicate layers or leftover temporary layers.
• Cover both SecondaryCosts() and SecondaryResourceUses() API paths so the fix does not only handle optional spends while missing hard costs.

Risks and Open Questions

• Blindly clearing all RitsuLib-attached costs could remove valid runtime temporary costs, enchantment effects, or modifier/capability-added layers.
• The exact canonical-reset timing matters: it should remain consistent with the official downgrade flow and enchantment/affliction reapplication, or display and actual payment may diverge.
• If maintainers cannot reproduce locally, ask the reporter for the minimal “Ichimonji Slash” card class, the base/upgraded values, and the exact enemy/turn state that triggers suppress.

---

工具侧记录

• BAKAOLC/STS2-RitsuLib#78 · 退出码 0 · 进程 368.99s
• gpt-5.5(high) · API 366878ms · 29 轮 · ↓85997 ↑9291 · 缓存读519680 写0 · $0.9221
• MCP available: management tools exposed to Claude.

[BAKAOLC]

看起来缺少的行为还挺多的，今天上完班我就改一下
唉要是官方有提供更好的次级资源接口而不是硬编码辉星就省事多了

[iouter]

官方的硬编码行为还是挺多的，我猜也是为了省事（）