[Bug]

[mous233]

模块范围

Public API（公开 API）

严重程度

Critical / crash（严重 / 崩溃）

发生了什么？

godot2026-06-21T09.38.36.log
)好像是和废墟图书馆的前置有冲突，今天在更新后才出现的问题，昨天玩还好好的，表现为无法启动游戏

复现步骤

装废墟图书馆以及其前置再装本模组的最新版本

期望行为

No response

日志 / 堆栈

RitsuLib 版本

No response

运行环境

No response

[ritsukage-local-analyzer]

Warning

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

摘要

用户在更新 RitsuLib 后（同日提交 1fbf49b feat(Compat): Add gameplay relevance check for loaded mods），同时安装废墟图书馆及其前置 mod 时游戏无法启动。问题极可能由新增的 IsGameplayRelevantLoadedModType 过滤逻辑所触发：该逻辑根据 mod manifest 中的 affectsGameplay 字段排除序列化缓存中的模型，若废墟图书馆前置 manifest 声明 affectsGameplay=false，则其所注册模型将被从确定性序列化缓存中移除，导致 net-id 重新分配或哈希错位，进而在启动时引发反序列化异常。由于缺少 RitsuLib 版本号、运行环境及日志正文，当前无法完全确认原因；建议维护者查看附件日志并核查相关 mod 的 manifest。

重点结论

维度	内容
简单介绍	装有废墟图书馆及其前置 mod 时，更新 RitsuLib 后游戏无法启动
可能原因（高置信度）	1fbf49b 新增的 IsGameplayRelevantLoadedModType 过滤逻辑将 affectsGameplay=false 的前置 mod 模型排除出确定性序列化缓存，导致 hash / net-id 变化，启动时反序列化失败
可能原因（次要）	ContentModLoadOrderInventory.TryCreateCurrentModEntry（L234）直接访问 manifest?.affectsGameplay，若当前游戏版本 ModManifest 无该字段则在启动时抛出 MissingFieldException
可能解决方案	① 查看附件 Godot 日志获取确切堆栈；② 核查废墟图书馆及其前置 manifest 中 affectsGameplay 的值；③ 若确认为过滤逻辑缺陷，考虑在 GetSortedModelEntries 中回退为包含所有已加载模型，或在 IsGameplayRelevantLoadedModType 返回 false 时仅记录 warning 而非排除
需要补充	RitsuLib 版本号、游戏版本、废墟图书馆及其前置的 mod ID / manifest、日志正文（shell 块为空，附件有效）

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

问题描述

实际行为

安装废墟图书馆及其前置 mod，更新 RitsuLib 至最新版本后，游戏完全无法启动。

期望行为

报告者未填写（字段值为 _No response_）。

复现步骤

1. 安装废墟图书馆及其前置 mod
2. 安装/更新至最新版本的 RitsuLib
3. 启动游戏 → 无法启动

环境与版本

字段	值
RitsuLib 版本	未填写
运行环境	未填写
问题首次出现	2026-06-21 更新后（更新前昨日正常）

日志、附件与原文摘录

报告者上传了 Godot 日志附件（godot2026-06-21T09.38.36.log），但 issue body 内 shell 代码块为空；实际日志内容仅存在于附件中，本分析无法直接读取。

原文：

好像是和废墟图书馆的前置有冲突，今天在更新后才出现的问题，昨天玩还好好的，表现为无法启动游戏

要点：用户明确指出冲突对象是「前置 mod」而非废墟图书馆本体，且与今日 RitsuLib 更新时间吻合。

详细分析依据

最可能触发点：ModelIdSerializationCacheDynamicContentPatch + 新增过滤逻辑

提交 1fbf49b 在 Sts2ModManagerCompat.cs（L74–93）新增：

internal static bool IsGameplayRelevantLoadedModType(Type type)
{
    foreach (var mod in EnumerateLoadedModsWithAssembly())
        try
        {
            if (ReadAssembly(mod) != type.Assembly) continue;
            var manifest = ReadManifest(mod);
            return manifest == null || ReadManifestAffectsGameplay(manifest);
        }
        ...
    return true;
}

该方法在 ModelIdSerializationCacheDynamicContentPatch.GetSortedModelEntries（L171）中被调用：

if (!Sts2ModManagerCompat.IsGameplayRelevantLoadedModType(modelType))
    continue;   // 跳过该 mod 的所有模型

若废墟图书馆前置 manifest 中 affectsGameplay=false（前置/工具库类 mod 可能这样声明），则其注册的所有 AbstractModel 子类均被排除在确定性缓存重建之外。这导致：

• 缓存 net-id 分配序列改变
• ComputeHash 结果与更新前不同
• 启动时若游戏尝试用旧 net-id 反序列化存档或网络数据，则抛出异常

次要触发点：ContentModLoadOrderInventory.TryCreateCurrentModEntry L234

manifest?.affectsGameplay ?? true,

此处为编译期直接字段访问（IL ldfld）。若正在运行的游戏版本 ModManifest 不含 affectsGameplay 字段，在 BuildCurrentOrder() 被调用时抛出 MissingFieldException。不过该情形应影响所有 mod 组合而非仅废墟图书馆用户，置信度较低。

Sts2ModManagerCompat.ReadManifestAffectsGameplay 已做反射防御（CreateManifestBoolAccessor 先检测字段是否存在，不存在则返回默认值 true），与直接访问路径行为不一致。

反馈规范性提醒

维度	状态	备注
复现步骤	含糊	缺少具体 mod 版本和 ID，步骤描述笼统
期望 / 实际	含糊	期望行为留空；实际行为仅一句话
环境与版本	缺失	RitsuLib 版本、游戏版本均未填写
日志 / 附件	含糊	附件已上传但 shell 块为空；body 存在多余 ) 格式错误
标题与背景	缺失	标题仅为 [Bug]，无描述性内容

详细验证建议

• 下载并阅读附件日志 godot2026-06-21T09.38.36.log，定位崩溃堆栈（Exception、MissingFieldException、InvalidOperationException 等）
• 确认废墟图书馆及其前置 mod 的 manifest 文件中 affectsGameplay 字段值
• 在无废墟图书馆/前置情况下启动游戏，确认 RitsuLib 最新版本本身是否正常
• 检查 ContentModLoadOrderInventory.TryCreateCurrentModEntry 在低版本 ModManifest（无 affectsGameplay 字段）下是否抛出 MissingFieldException
• 如确认为 IsGameplayRelevantLoadedModType 过滤逻辑问题，评估是否需要将 GetSortedModelEntries 的过滤策略改为「包含所有已加载模型，仅对纯工具 mod 豁免」

风险与未决

• 缺乏日志正文，无法确认崩溃发生在哪个阶段（patch 执行期 vs 游戏初始化 vs 存档加载）
• 废墟图书馆/前置 mod ID 未知，无法直接验证 affectsGameplay 字段值
• 若为 MissingFieldException 路径，则影响面可能远不止该 mod 组合
• priority/p0 + severity/critical 标签当前已设置；若仅与特定第三方 mod manifest 配置相关，实际严重程度可酌情调整

---

English translation

Summary

After updating RitsuLib (same-day commit 1fbf49b feat(Compat): Add gameplay relevance check for loaded mods), the game fails to start when the "Ruined Library" (废墟图书馆) mod and its prerequisites are installed. The most likely trigger is the newly introduced IsGameplayRelevantLoadedModType filter: it excludes models from mods with affectsGameplay=false during deterministic serialization cache rebuilding, which can change net-id assignments and the computed hash, causing deserialization failures at startup. Without the RitsuLib version, game version, and log body, the root cause cannot be fully confirmed; maintainers should review the attached log and the prerequisites' manifests.

Key Takeaways

Dimension	Detail
Brief description	Game cannot start after updating RitsuLib when Ruined Library and its prerequisite mods are installed
Most likely cause (high confidence)	New IsGameplayRelevantLoadedModType filter (added in 1fbf49b) excludes models from mods with affectsGameplay=false from the deterministic serialization cache, changing hash/net-ids and causing deserialization failure on startup
Secondary cause	ContentModLoadOrderInventory.TryCreateCurrentModEntry (L234) directly accesses manifest?.affectsGameplay via compiled IL; if the running game version's ModManifest lacks this field, a MissingFieldException is thrown at startup
Suggested actions	① Read the attached Godot log for the exact stack trace; ② Check the affectsGameplay value in the prerequisite mod's manifest; ③ If the filter is the culprit, consider reverting to include all loaded models in GetSortedModelEntries, or only warning instead of excluding
Information needed	RitsuLib version, game version, mod IDs/manifests for Ruined Library and its prerequisites, log body (shell block in the report is empty; file attachment is present)

Expand detailed analysis, evidence, and verification

Problem Description

Actual behavior

Game completely fails to start when Ruined Library and its prerequisite mods are installed together with the latest RitsuLib.

Expected behavior

Not provided by the reporter (_No response_).

Reproduction steps

1. Install Ruined Library (废墟图书馆) and its prerequisite mods
2. Install/update to the latest version of RitsuLib
3. Launch the game → game fails to start

Environment and Versions

Field	Value
RitsuLib version	Not provided
Running environment	Not provided
First occurrence	2026-06-21, after update (game was working fine the day before)

Logs, Attachments, and Excerpts

The reporter uploaded a Godot log file (godot2026-06-21T09.38.36.log) as a GitHub attachment. The shell code block in the issue body is empty — the actual log content is only in the attachment and was not available for direct analysis.

Reporter (translated):

Seems to conflict with Ruined Library's prerequisites. Started after today's update — was working fine yesterday. Symptom: game cannot start.

Key point: the reporter specifically attributes the conflict to a prerequisite mod, not Ruined Library itself, and ties it precisely to today's RitsuLib update.

Detailed Analysis

Primary suspected trigger: ModelIdSerializationCacheDynamicContentPatch + new filter

Commit 1fbf49b added IsGameplayRelevantLoadedModType in Sts2ModManagerCompat.cs (L74–93):

internal static bool IsGameplayRelevantLoadedModType(Type type)
{
    foreach (var mod in EnumerateLoadedModsWithAssembly())
        try
        {
            if (ReadAssembly(mod) != type.Assembly) continue;
            var manifest = ReadManifest(mod);
            return manifest == null || ReadManifestAffectsGameplay(manifest);
        }
        ...
    return true;
}

This method is called in ModelIdSerializationCacheDynamicContentPatch.GetSortedModelEntries (L171):

if (!Sts2ModManagerCompat.IsGameplayRelevantLoadedModType(modelType))
    continue;   // skip all models from this mod

If the Ruined Library prerequisite mod declares affectsGameplay=false in its manifest (plausible for a utility/library-type prerequisite), all AbstractModel subclasses it registers are excluded from the cache rebuild. This results in:

• Changed net-id assignment sequence
• Different ComputeHash result compared to before the update
• If the game attempts to deserialize saves or network data using old net-ids, an exception is thrown at startup

Secondary suspected trigger: ContentModLoadOrderInventory.TryCreateCurrentModEntry L234

manifest?.affectsGameplay ?? true,

This is a compiled direct field access (IL ldfld). If the running game version's ModManifest does not have affectsGameplay, calling BuildCurrentOrder() will throw MissingFieldException. However, this would affect all mod combinations, not just Ruined Library users — lower confidence.

Note the inconsistency: Sts2ModManagerCompat.ReadManifestAffectsGameplay uses CreateManifestBoolAccessor which first checks whether the field exists via reflection and falls back to default true if absent. The direct-access path in ContentModLoadOrderInventory does not have this safety.

Normative Feedback

Dimension	Status	Notes
Reproduction steps	Vague	Missing specific mod versions and IDs; description is generic
Expected / actual behavior	Vague	Expected behavior left blank; actual behavior is a single vague sentence
Environment & version	Missing	RitsuLib version and game version both not provided
Logs / attachments	Vague	Log file attached but shell block is empty; body contains a stray ) formatting error
Title & context	Missing	Title is just [Bug] with no descriptive content

Detailed Verification Checklist

• Download and read the attached log godot2026-06-21T09.38.36.log to locate the crash stack trace (look for Exception, MissingFieldException, InvalidOperationException, etc.)
• Check the affectsGameplay field value in the Ruined Library prerequisite mod's manifest
• Reproduce without Ruined Library/prerequisites to confirm whether the latest RitsuLib works in isolation
• Verify whether ContentModLoadOrderInventory.TryCreateCurrentModEntry throws MissingFieldException on older game versions that lack the affectsGameplay field on ModManifest
• If IsGameplayRelevantLoadedModType filtering is confirmed as the cause, evaluate changing GetSortedModelEntries strategy to include all loaded models by default (or only emit a warning when affectsGameplay=false) rather than excluding them from the cache

Risks and Open Questions

• Without the log body, it is unknown at which startup phase the crash occurs (patch execution, game initialization, or save loading)
• Ruined Library and prerequisite mod IDs are unknown, so affectsGameplay cannot be verified directly
• If the MissingFieldException path is the actual cause, the impact may extend far beyond this specific mod combination
• Current labels priority/p0 + severity/critical may be appropriate; if the root cause is a third-party mod manifest configuration issue, severity could be reconsidered once more information is available

---

工具侧记录

• BAKAOLC/STS2-RitsuLib#60 · 退出码 0 · 进程 245.20s
• claude-sonnet-4-6 · API 243410ms · 13 轮 · ↓15 ↑12246 · 缓存读344601 写59738 · $0.6455
• MCP available: management tools exposed to Claude.

[mous233]

更正一下，看了群友说是薄荷尖塔的问题关掉薄荷尖塔就可以正常进入游戏了

[BAKAOLC]

这个问题在前面的版本应该已经解决，是因为部分处理不完善导致的，并且也同步给了薄荷尖塔作者相关信息
将会关闭此问题

/r set confirmed