[Bug] 附魔图标与次要资源图标重叠，次要资源图标只应该升级预览中变绿

[iouter]

模块范围

UI

严重程度

Minor（轻微）

发生了什么？

附魔图标与次要资源图标重叠，还有次要资源图标只应该升级预览中变绿（下图中文本就没有变绿），升级后，再查看升级好像就不应该变绿了。

复现步骤

造一张带有附魔图标和次要资源图标的卡

期望行为

可以让附魔图标自动（或着加个参数？）下移

日志 / 堆栈

RitsuLib 版本

0.4.38

运行环境

No response

[ritsukage-local-analyzer]

Warning

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

摘要

附魔卡牌同时显示附魔标记和次级资源费用图标时，两个 UI 元素会发生重叠，属于低风险但影响读图的卡牌表现问题。当前信息足以按 UI 布局冲突 triage：优先在卡牌费用挂载层加入避让/偏移能力，或在默认示例中明确为次级资源图标预留空间。

重点结论

项目	结论
简单介绍	带附魔图标的卡牌再叠加次级资源费用图标后，左上/费用区域可读性下降。
可能原因	较可能是 RitsuLib 的次级资源卡牌 UI 通过 RegisterCardUi(...) 挂到 NCard.Body 后由注册方自行定位，未与游戏内置附魔标签位置协同。
可能解决方案	为 NSecondaryResourceCardCostUi 或默认注册示例增加 collision-aware 的基准位置/垂直偏移参数；或在刷新时检测 NCard.EnchantmentTab.Visible 后自动下移次级资源费用节点。

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

问题描述

期望行为

附魔图标与次级资源图标不重叠；报告者建议可让附魔图标自动下移，或提供参数控制位置。

实际行为

截图显示卡牌左上费用/标记区域中，附魔图标与次级资源图标占用相近位置并重叠，影响识别。

复现步骤

1. 制作或生成一张同时带有附魔图标和次级资源图标的卡牌。
2. 在卡牌 UI 中查看该卡，观察图标是否重叠。

环境与版本

• RitsuLib 版本：0.4.38
• 模块范围：UI
• 严重程度：Minor
• 运行环境：报告中未提供

日志、附件与原文摘录

• 截图：issue 正文包含一张 744×940 的图片附件，展示图标重叠。
• 原文：造一张带有附魔图标和次要资源图标的卡
  • 要点：复现依赖“同一卡牌同时具备附魔与次级资源费用显示”。
• 原文：可以让附魔图标自动（或着加个参数？）下移
  • 要点：期望是自动避让或暴露可配置偏移。

详细分析依据

• RitsuLib 的次级资源卡牌费用节点 NSecondaryResourceCardCostUi 默认单槽尺寸为 48×48，图标尺寸为 46×46，自身只负责槽内居中与标签布局；相关定义见 src/Combat/SecondaryResources/SecondaryResourceCardCostUi.cs:21、src/Combat/SecondaryResources/SecondaryResourceCardCostUi.cs:27、src/Combat/SecondaryResources/SecondaryResourceCardCostUi.cs:464。
• 该节点在 ApplyLayout() 中只按自己的 SlotSize/IconSize/LabelOffset 计算 _texture 与 _label 的位置，没有读取或避让卡牌上的附魔标签；见 src/Combat/SecondaryResources/SecondaryResourceCardCostUi.cs:464。
• RitsuLib 的默认卡牌 UI attach parent 是 NCard.Body，即次级资源 UI 会作为卡牌主体内的附加节点刷新；见 src/Combat/SecondaryResources/SecondaryResourceUi.cs:369 与 src/Combat/SecondaryResources/SecondaryResourceUi.cs:409。
• 文档也说明 NSecondaryResourceCardCostUi 是用于 RegisterCardUi(...) 的单资源包装节点，“每个节点绑定一个 resource id，并由注册方分别指定位置”；见 docs/pages/guide/secondary-resources.md:525。这意味着库当前更像提供基础节点，而不是内建全局排版避让策略。
• 游戏侧 NCard.UpdateEnchantmentVisuals() 只根据星星费用是否存在，在默认位置与上移 45 像素之间切换附魔标签；它不了解 RitsuLib 的次级资源费用节点，因此不会自动为自定义挂载图标让位。参考本地 0.104.0 源码 src/Core/Nodes/Cards/NCard.cs:433。
• 因此，最可能的修复点不在支付逻辑，而在表现层：为次级资源卡牌费用 UI 提供推荐/默认位置策略，或让注册方可基于 NCard.EnchantmentTab 状态调整 Position。

反馈规范性提醒

维度	状态
复现步骤	含糊：给出了触发条件，但没有具体卡牌、mod 配置或最小样例。
期望/实际	已提供：实际问题与期望方向清楚。
环境与版本	含糊：RitsuLib 版本已提供，运行环境为 _No response_。
日志/附件	已提供：有截图；日志为空但对纯 UI 重叠问题影响不大。
标题与背景	已提供：标题与正文范围一致。

详细验证建议

• 用 RitsuLib 0.4.38 构造一张同时拥有附魔与至少一个次级资源费用的测试卡，确认截图中的重叠是否稳定复现。
• 在有/无星星费用、普通预览/手牌显示等不同 PileType 与 CardPreviewMode 下检查附魔标签位置。
• 对比调整 NSecondaryResourceCardCostUi.Position 或自定义 SecondaryResourceCardCostUiStyle 后的效果，确认只需布局偏移即可消除重叠。
• 若实现自动避让，回归无附魔卡、多次级资源费用、X/可选费用、不可支付颜色等现有显示路径。

风险与未决

• 若直接移动附魔标签，可能影响原版对星星费用的已有布局规则；更安全的方向通常是移动 RitsuLib 附加的次级资源费用节点，或提供 opt-in 参数。
• 需要确认报告截图中的次级资源 UI 是项目内示例/默认注册，还是下游 mod 自行注册的位置；这会决定是修库默认行为、补文档，还是建议下游调整注册代码。
• 运行环境缺失不阻塞初步定位，但若不同分辨率或 UI 缩放会改变重叠程度，后续仍建议补充。

---

English translation

Summary

When an enchanted card also displays a secondary-resource cost icon, the two UI elements overlap, creating a low-risk but visible card readability issue. The issue is actionable as a UI layout conflict: first look at adding avoidance/offset support in the card-cost attachment layer, or reserve space for secondary-resource icons in the default examples.

Key Takeaways

Item	Takeaway
Brief description	Cards with both an enchantment icon and a secondary-resource cost icon lose readability around the cost/marker area.
Likely cause	Most likely, RitsuLib secondary-resource card UI is attached through RegisterCardUi(...) under NCard.Body and positioned by the registrant, without coordination with the built-in enchantment tab position.
Possible fix	Add a collision-aware anchor/vertical offset option for NSecondaryResourceCardCostUi or the default registration examples; alternatively, during refresh, detect NCard.EnchantmentTab.Visible and move the secondary-resource cost node downward.

Expand detailed analysis, evidence, and verification

Problem Description

Expected Behavior

The enchantment icon and secondary-resource icon should not overlap. The reporter suggests either automatically moving the enchantment icon downward or exposing a positioning parameter.

Actual Behavior

The screenshot shows the enchantment marker and secondary-resource icon occupying nearby space around the card's top-left cost/marker area, reducing readability.

Reproduction Steps

1. Create or generate a card that has both an enchantment icon and a secondary-resource icon.
2. View the card in the card UI and check whether the icons overlap.

Environment and Versions

• RitsuLib version: 0.4.38
• Module scope: UI
• Severity: Minor
• Runtime environment: not provided in the report

Logs, Attachments, and Source Excerpts

• Screenshot: the issue body includes a 744×940 image attachment showing the overlap.
• Original: 造一张带有附魔图标和次要资源图标的卡
  • Key point: reproduction depends on one card showing both enchantment and secondary-resource cost UI.
• Original: 可以让附魔图标自动（或着加个参数？）下移
  • Key point: expected handling is automatic avoidance or a configurable offset.

Detailed Analysis Basis

• RitsuLib's secondary-resource card cost node, NSecondaryResourceCardCostUi, defaults to a 48×48 slot and a 46×46 icon. It only handles layout inside its own slot; see src/Combat/SecondaryResources/SecondaryResourceCardCostUi.cs:21, src/Combat/SecondaryResources/SecondaryResourceCardCostUi.cs:27, and src/Combat/SecondaryResources/SecondaryResourceCardCostUi.cs:464.
• In ApplyLayout(), the node computes only its own _texture and _label positions from SlotSize, IconSize, and LabelOffset; it does not read or avoid the card's enchantment tab. See src/Combat/SecondaryResources/SecondaryResourceCardCostUi.cs:464.
• RitsuLib's default card UI attach parent is NCard.Body, so secondary-resource UI is refreshed as an extra node inside the card body. See src/Combat/SecondaryResources/SecondaryResourceUi.cs:369 and src/Combat/SecondaryResources/SecondaryResourceUi.cs:409.
• The documentation states that NSecondaryResourceCardCostUi is a single-resource wrapper node for RegisterCardUi(...), and that each node should be bound to one resource id and positioned by the registrant; see docs/pages/guide/secondary-resources.md:525. This suggests the library currently provides a base node rather than a global collision-avoidance layout policy.
• On the game side, NCard.UpdateEnchantmentVisuals() only switches the enchantment tab between its default position and 45 pixels upward depending on whether a star cost exists. It does not know about RitsuLib's secondary-resource cost nodes, so it cannot automatically make room for custom attached icons. See the local 0.104.0 source at src/Core/Nodes/Cards/NCard.cs:433.
• Therefore, the most likely fix area is presentation rather than payment logic: provide a recommended/default positioning strategy for secondary-resource card-cost UI, or let registrants adjust Position based on NCard.EnchantmentTab state.

Reporter Hygiene Reminder

Dimension	Status
Reproduction steps	Ambiguous: the trigger condition is provided, but no exact card, mod configuration, or minimal sample is given.
Expected/actual	Provided: the visible problem and desired direction are clear.
Environment and version	Ambiguous: RitsuLib version is provided, but runtime environment is _No response_.
Logs/attachments	Provided: a screenshot is attached; empty logs are not a major blocker for a pure UI overlap issue.
Title and background	Provided: the title and body are aligned in scope.

Detailed Verification Suggestions

• With RitsuLib 0.4.38, construct a test card that has both an enchantment and at least one secondary-resource cost, then confirm whether the screenshot overlap reproduces consistently.
• Check enchantment tab placement across cards with and without star costs, and across normal preview/hand display contexts such as different PileType and CardPreviewMode values.
• Adjust NSecondaryResourceCardCostUi.Position or a custom SecondaryResourceCardCostUiStyle and confirm whether a layout-only offset removes the overlap.
• If automatic avoidance is implemented, regress cards without enchantments, cards with multiple secondary-resource costs, X/optional costs, and unaffordable-color display paths.

Risks and Open Questions

• Moving the enchantment tab directly may interfere with the game's existing star-cost layout rule. The safer direction is usually to move RitsuLib's attached secondary-resource cost node, or expose an opt-in parameter.
• It still needs confirmation whether the secondary-resource UI in the screenshot comes from a project example/default registration or from downstream mod code. That determines whether maintainers should change library defaults, update documentation, or ask the downstream mod to adjust its registration code.
• The missing runtime environment does not block initial triage, but if resolution or UI scale affects the overlap, those details would still be useful later.

---

工具侧记录

• BAKAOLC/STS2-RitsuLib#70 · 退出码 0 · 进程 336.60s
• gpt-5.5(high) · API 335608ms · 25 轮 · ↓79011 ↑7880 · 缓存读831488 写0 · $1.0078
• MCP available: management tools exposed to Claude.

[BAKAOLC]

最新的 devbuild 应该已解决，还有问题的话欢迎随时反馈

[iouter]

已修复