fix: 解歌 11820 的查表结论与道具回读容错

排查「解锁 11820 机台不显示」的结果:

- 11820 = Xaleid◆scopiX(xi),lockType=4(MusicLockType.KaleidScope)、
  longMusic=1,eventName 与 subEventName 都是 26100124。
  NotesListManager.cs:251 的分支确认:KaleidScope 曲落到 IsUnlockBase →
  MusicUnlockList,也就是 itemKind 5 的行对它确实有效,包没发错。
  真正卡点是前一道门:曲池准入要 IsOpenEvent(26100124)(NotesListManager.cs:70),
  机台 mai2.ini 的 AllOpen=0,所以完全依赖服务器 GetGameEventApi 给的窗口;
  而 G:\Package 的 StreamingAssets 只装了 A000/A005/A011/A015,没有 A031,
  GetMusic(11820) 直接是 null —— 这是数据没装,不是协议问题。
- 重生成映射表时改用 D:/A031OptDump/Root 作数据根(上一版读错了根):
  现在 music 含 11820、gate 为 1~10(7=棱镜塔、9=希望之门)、
  title 3001→3031、chara 983→987。
- 解锁/收藏品路径里 GetUserItemApi 的回读改成失败可降级:私服不实现它时
  退回一律 '1'(加这段之前的行为),不要让回读把整个解锁功能拖挂。
- 按你的要求删掉 README 的「ID 映射表」一节。
This commit is contained in:
Cookiues committed 2026-10-02 01:51:11 +08:00
1 parent 2c7f9c1de7
commit a5fb2c97cd
8 files changed
+678 -398

No files matched your search

+21 -12
View File
@@ -320,21 +320,30 @@ class _MusicRiskFeatureViewState extends State<MusicRiskFeatureView>
// isNewItemList 得按 (itemKind, itemId) 主键比对服务器快照来给 0/1,
// 不能一律发 '1':重复解锁一首已经存在的歌时,服务器会把插入冲突的
// 行整行丢掉,表现就是「上传成功但没生效」。
final existingKeys = await service.getUserItemKeys(
widget.userId,
items.map((e) => e['itemKind'] as int),
);
// 但这次回读不能让整件事失败——私服要是不实现 GetUserItemApi,
// 退化成一律 '1'(就是加这段之前的行为)总比解锁整个不能用强。
Set<String>? existingKeys;
try {
existingKeys = await service.getUserItemKeys(
widget.userId,
items.map((e) => e['itemKind'] as int),
);
} catch (_) {
existingKeys = null;
}
builder.applyItemListPatch(
packet,
items: items,
newFlags: [
for (final item in items)
existingKeys.contains(
'${item['itemKind']}:${item['itemId']}',
)
? '0'
: '1',
].join(),
newFlags: existingKeys == null
? null
: [
for (final item in items)
existingKeys.contains(
'${item['itemKind']}:${item['itemId']}',
)
? '0'
: '1',
].join(),
);
if (_isUnlock) {
builder.applyMusicDetailPatch(packet, musicData: musicData);