[Feature] 让次要资源的卡牌上的UI显示的更像原版能量，减费（或升级）时显示为绿色，加费但能打出时显示为蓝色等等

[iouter]

模块范围

Public API（公开 API）

动机 / 使用场景

让次要资源的卡牌上的UI显示的更像原版能量

方案设想

1. 减费（或升级）时显示为绿色
2. 加费但能打出时显示为蓝色
3. 费用不够时显示为红色（这个有待商榷，目前可选打出是不会让卡牌UI颜色变化的）

最好也额外提供一套类似的formatter？用于一般的文本显示。

替代方案

No response

其他补充

原始费用和是否升级，或许可以让注册的时候（或者什么时候）绑定一个DynamicVar

[ritsukage-local-analyzer]

Warning

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

摘要

此 Feature Request 要求次级资源卡牌费用 UI 参照原版能量/星形费用的四色逻辑：减费显绿、增费但可打显蓝、资源不足显红。当前 SecondaryResourceCardCostUiStyle 仅有"可支付（米色）"与"不可支付（红色）"两档，且 SecondaryResourcePaymentLine 不携带用于比较的基础费用值，无法判断费用是升高还是降低。该需求有清晰的原版蓝图可参照，实现范围集中在 SecondaryResourceCardCostUi.cs 与 SecondaryResourceCosts.cs，复杂度适中，建议纳入规划。

重点结论

维度	内容
简单介绍	次级资源卡牌费用数字目前只有米色/红色两态，不能像原版能量那样用绿/蓝/红区分减费、增费可打、费用不足三种状态
可能原因	SecondaryResourceCardCostUiStyle 缺少 DecreasedColor（绿）和 IncreasedColor（蓝）两个色档；SecondaryResourcePaymentLine 不携带基础费用，Refresh() 无法做费用高低比较
可能解决方案	① 向 SecondaryResourcePaymentLine 添加 BaseCost 字段（resolver 已有该中间值）；② 扩展 SecondaryResourceCardCostUiStyle 增加绿/蓝两档颜色属性；③ 将 Refresh() 的双态分支改为与原版 CardCostHelper 对称的四态逻辑；④ 可选：提供对应的文本 formatter 供 DynamicVar / 描述文本复用

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

问题描述

期望行为

• 减费（低于基础费用）或升级后费用降低 → 文本显示 绿色（StsColors.green / energyGreenOutline）
• 增费但资源充足可打出 → 文本显示 蓝色（StsColors.energyBlue / energyBlueOutline）
• 资源不足无法打出 → 文本显示 红色（StsColors.red / unplayableEnergyCostOutline）
• 未修改 → 保持现有米色（StsColors.cream）
• 额外提供与上述颜色对应的文本 formatter，用于 DynamicVar / 一般文本着色

实际行为

NSecondaryResourceCardCostUi.Refresh() 仅根据 line.CanPlay 二元切换颜色（AffordableColor ↔ UnaffordableColor），无绿/蓝态，也无基础费用对比逻辑。

复现步骤

功能缺失，无需复现步骤（Feature Request）。

---

详细分析依据

原版蓝图（0.104.0 基准源码）

// CardCostColor.cs
public enum CardCostColor { Unmodified, Increased, Decreased, InsufficientResources }

// NCard.cs — GetCostTextColorInHand
CardCostColor.Increased           → StsColors.energyBlue
CardCostColor.Decreased           → StsColors.green
CardCostColor.InsufficientResources → StsColors.red
CardCostColor.Unmodified          → defaultColor（cream）

原版通过 CardCostHelper.GetEnergyCostColor() 将当前费用与基础费用（card.EnergyCost.GetWithModifiers(CostModifiers.None) / card.BaseStarCost）比较后返回枚举，再映射到颜色。次级资源缺少同等机制。

当前库状态（SecondaryResourceCardCostUi.cs:348–352）

_label.AddThemeColorOverride(ThemeConstants.Label.FontColor,
    line.CanPlay ? _style.AffordableColor : _style.UnaffordableColor);
_label.AddThemeColorOverride(ThemeConstants.Label.FontOutlineColor,
    line.CanPlay ? _style.AffordableOutlineColor : _style.UnaffordableOutlineColor);

只有两态；SecondaryResourceCardCostUiStyle 无绿/蓝属性；SecondaryResourcePaymentLine 无 BaseCost 字段。

resolver 中基础费用已可获取（SecondaryResourceCosts.cs:649–653）

var localCost = ModifyLocalCost(card, definition, use, cost.Amount);  // 本地修改后
var modifiedCost = SecondaryResourceHook.ModifyCost(...);              // hook 修改后
var fixedCost = Math.Max(0, (int)Math.Ceiling(modifiedCost));          // 最终费用

cost.Amount（注册时的原始费用）在此处已可得，只需将其透传到 SecondaryResourcePaymentLine 作为 BaseCost。

DynamicVar 建议

reporter 提议在注册时绑定原始费用和升级状态到 DynamicVar。现有 DynamicVarExtensions（src/Cards/DynamicVars/DynamicVarExtensions.cs）支持 WithTooltip、GetIntOrDefault 等，但 DynamicVar 机制主要面向文本插值，而非费用颜色比较。更直接的方案是在 SecondaryResourcePlayUse / SecondaryResourcePaymentLine 层面携带 BaseCost。若确需文本着色 formatter，可在样式或工具类中单独提供，两者不互斥。

"可选打出不变色"说明

reporter 已自行标注第 3 条（红色）"有待商榷"——当费用为 IsOptional（BlocksPlay = false）时，原版也不对 optional cost 显示红色。实现时应保持与 line.BlocksPlay / line.IsOptional 一致的语义。

---

详细验证建议

• 确认 SecondaryResourcePaymentLine 新增 BaseCost 后，resolver 在 preview 路径（ResolvePreviewLine）和正常路径（ResolveLine）均能正确填充
• 扩展 SecondaryResourceCardCostUiStyle：新增 DecreasedColor、DecreasedOutlineColor、IncreasedColor、IncreasedOutlineColor，默认值与 NCard.cs 对齐
• 将 Refresh() 的双态逻辑改为四态（!CanPlay → 红；Cost < BaseCost → 绿；Cost > BaseCost → 蓝；其余 → 米色），并为 IsOptional 路径保持原有行为
• 若提供文本 formatter，验证其在 DynamicVar 描述文本中输出正确的富文本颜色标签
• 回归：已有使用自定义 FormatCost 委托的 mod 不受颜色逻辑变更影响（FormatCost 仅控制数字文本，颜色由样式独立控制）

风险与未决

• BaseCost 语义需明确：是注册时的 cost.Amount，还是包含本地修改（ModifyLocalCost）但不含 hook 修改的费用？建议与原版星形费用保持一致（使用 hook 修改前的基础值）。
• 升级时费用变化：若模组通过 SecondaryResourceCost 本身区分升级/未升级（而非 hook），BaseCost 是否指向"未升级"值需要在 API 文档中明确。
• Optional cost 的颜色语义：reporter 已主动标注该边界，实现时宜与 line.BlocksPlay 挂钩，避免给 optional cost 显示误导性红色。

---

English translation

Summary

This feature request asks for the secondary-resource card-cost UI to mirror the vanilla energy/star-cost four-color logic: green when cost is reduced, blue when cost is increased but still affordable, red when resources are insufficient. Currently SecondaryResourceCardCostUiStyle only supports two states (cream = affordable, red = unaffordable), and SecondaryResourcePaymentLine carries no base-cost value for comparison, so the UI cannot tell whether the displayed cost is higher or lower than the card's canonical cost. The feature has a clear vanilla blueprint and is scoped mainly to SecondaryResourceCardCostUi.cs and SecondaryResourceCosts.cs; moderate complexity, recommended for the backlog.

Key Takeaways

Dimension	Detail
Summary	Secondary-resource cost numbers currently show only cream/red, with no green (cost reduced) or blue (cost increased but playable) states
Likely cause	SecondaryResourceCardCostUiStyle is missing DecreasedColor (green) and IncreasedColor (blue); SecondaryResourcePaymentLine carries no BaseCost, so Refresh() cannot compare current vs. base cost
Recommended fix	① Add BaseCost to SecondaryResourcePaymentLine (the resolver already has this intermediate value); ② extend SecondaryResourceCardCostUiStyle with green/blue color properties; ③ update Refresh() to use four-state logic mirroring vanilla CardCostHelper; ④ optionally expose a matching text formatter for DynamicVar / description use

Expand detailed analysis, evidence, and verification

Problem description

Expected behavior

• Cost reduced below base (or lowered by upgrade) → green text (StsColors.green / energyGreenOutline)
• Cost increased but resources are sufficient → blue text (StsColors.energyBlue / energyBlueOutline)
• Insufficient resources → red text (StsColors.red / unplayableEnergyCostOutline)
• Unmodified → existing cream (StsColors.cream)
• Optional: a text formatter exposing the same coloring for DynamicVar / general text

Actual behavior

NSecondaryResourceCardCostUi.Refresh() only branches on line.CanPlay to switch between AffordableColor and UnaffordableColor. No green/blue state exists, and no base-cost comparison is performed.

Reproduction steps

N/A — this is a feature request with no existing behavior to reproduce.

---

Detailed analysis

Vanilla blueprint (0.104.0 baseline source)

// CardCostColor.cs
public enum CardCostColor { Unmodified, Increased, Decreased, InsufficientResources }

// NCard.cs — GetCostTextColorInHand
CardCostColor.Increased             → StsColors.energyBlue
CardCostColor.Decreased             → StsColors.green
CardCostColor.InsufficientResources → StsColors.red
CardCostColor.Unmodified            → defaultColor (cream)

Vanilla uses CardCostHelper.GetEnergyCostColor() to compare the current cost against the base cost (card.EnergyCost.GetWithModifiers(CostModifiers.None) / card.BaseStarCost) and then maps the result to a color. Secondary resources have no equivalent mechanism.

Current library state (SecondaryResourceCardCostUi.cs:348–352)

_label.AddThemeColorOverride(ThemeConstants.Label.FontColor,
    line.CanPlay ? _style.AffordableColor : _style.UnaffordableColor);
_label.AddThemeColorOverride(ThemeConstants.Label.FontOutlineColor,
    line.CanPlay ? _style.AffordableOutlineColor : _style.UnaffordableOutlineColor);

Only two states; SecondaryResourceCardCostUiStyle has no green/blue properties; SecondaryResourcePaymentLine has no BaseCost field.

Base cost is already available in the resolver (SecondaryResourceCosts.cs:649–653)

var localCost  = ModifyLocalCost(card, definition, use, cost.Amount); // after local mods
var modifiedCost = SecondaryResourceHook.ModifyCost(...);              // after hook mods
var fixedCost  = Math.Max(0, (int)Math.Ceiling(modifiedCost));        // final cost

cost.Amount (the registered base cost) is available here and can be forwarded to SecondaryResourcePaymentLine as BaseCost with minimal churn.

On the DynamicVar suggestion

The reporter suggests binding original cost and upgrade status to a DynamicVar at registration time. The existing DynamicVarExtensions (src/Cards/DynamicVars/DynamicVarExtensions.cs) supports tooltip binding and value reads, but DynamicVar is primarily an interpolation mechanism for description text, not a color-comparison signal. A BaseCost field on SecondaryResourcePaymentLine is simpler and more direct. A separate text formatter for color-tagged rich text is a complementary, non-conflicting addition.

"Optional cost color" note

The reporter proactively flags that the red-color behavior for optional costs is debatable. The implementation should honor line.BlocksPlay — optional lines (BlocksPlay = false) should not display misleading red text when resources are insufficient.

---

Detailed verification checklist

• Confirm BaseCost in SecondaryResourcePaymentLine is filled correctly in both the preview path (ResolvePreviewLine) and the live path (ResolveLine)
• Extend SecondaryResourceCardCostUiStyle with DecreasedColor, DecreasedOutlineColor, IncreasedColor, IncreasedOutlineColor, defaulting to values from NCard.cs
• Update Refresh() to four-state logic (!CanPlay → red; Cost < BaseCost → green; Cost > BaseCost → blue; else → cream), with IsOptional lines excluded from red
• If a text formatter is added, verify it emits correct rich-text color tags in DynamicVar description strings
• Regression: mods using a custom FormatCost delegate should be unaffected — FormatCost controls the numeric string; color is applied independently by the style

Risks and open questions

• BaseCost semantics: should it be the registered cost.Amount, or the value after ModifyLocalCost but before hook modification? Recommend aligning with vanilla's approach (pre-hook base cost).
• Upgrade cost tracking: if a mod encodes upgraded vs. unupgraded cost directly in the SecondaryResourceCost struct rather than through hooks, it needs to be clear whether BaseCost refers to the unupgraded value. API documentation should address this.
• Optional-cost color: reporter has flagged this boundary; implementation should tie red display to line.BlocksPlay to avoid misleading UI on optional cost lines.

---

工具侧记录

• BAKAOLC/STS2-RitsuLib#66 · 退出码 0 · 进程 191.14s
• claude-sonnet-4-6 · API 189820ms · 21 轮 · ↓19 ↑9301 · 缓存读527937 写60084 · $0.6585
• MCP available: management tools exposed to Claude.

[BAKAOLC]

该功能是个合理的需求，不过由于目前因为有许多其他内容也在维护计划中（包括与原版游戏中的一些可能问题有关）所以这个的优先级不会特别高，但我有空就会开始计划实现
/r set p2 ui