Skip to content

Commit 4fbbc2d

Browse files
AlbusKenAlbusKen
committed
再次优化了表格保存的一点小BUG
1 parent 3c614b9 commit 4fbbc2d

2 files changed

Lines changed: 109 additions & 1 deletion

File tree

‎scripts/runtime/separateTableUpdate.js‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -335,7 +335,9 @@ export async function triggerTableFillFromLastMessage() {
335335

336336
try {
337337
Logger.info('[Memory Enhancement] 填表成功，正在将更新后的数据同步回主内存状态...');
338-
BASE.load(messagePiece.hash_sheets, messagePiece.cell_history);
338+
// [hotfix] 修复了v6.0.6版本中因API调用错误导致外部触发填表失败的问题。
339+
// 旧的 `BASE.load` 不存在，应使用 `applyJsonToChatSheets` 来更新内存中的表格数据。
340+
BASE.applyJsonToChatSheets(messagePiece.hash_sheets, 'data');
339341
Logger.info('[Memory Enhancement] 主内存状态同步完成。');
340342
} catch (e) {
341343
Logger.error('[Memory Enhancement] 将更新后的表格同步回BASE内存失败:', e);

‎项目文档.txt‎

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,109 @@
1+
v6.0.7-hotfix-external-trigger
2+
- **核心修复: 解决了在特定场景下（如使用“0层模式”或特殊角色卡）外部触发填表功能时，因调用了不存在的API而导致的致命错误。**
3+
- **问题:** 在 `triggerTableFillFromLastMessage` 函数中，当一次增量填表成功后，它尝试通过调用 `BASE.load()` 函数来将更新后的表格数据同步回内存中的主状态。然而，`BASE` 管理器对象上并没有 `load` 方法，这是一个错误的API调用，导致了 `TypeError: BASE.load is not a function` 的错误，中断了整个流程。
4+
- **解决方案:**
5+
1. **API调用修正:**
6+
- 深入分析了 `core/manager.js` 中 `BASE` 对象的可用方法。
7+
- 确定了正确的函数应为 `BASE.applyJsonToChatSheets(jsonData, 'data')`。这个函数专门用于接收一个包含表格数据的JSON对象，并将其安全地应用到内存中对应的表格实例上。
8+
2. **代码替换:**
9+
- 在 `scripts/runtime/separateTableUpdate.js` 中，将错误的 `BASE.load(messagePiece.hash_sheets, messagePiece.cell_history)` 调用替换为正确的 `BASE.applyJsonToChatSheets(messagePiece.hash_sheets, 'data')`。
10+
- **实现方式:**
11+
- **1. 修改 `scripts/runtime/separateTableUpdate.js`:**
12+
- 在 `triggerTableFillFromLastMessage` 函数的 `try` 块中，将对 `BASE.load` 的调用改为对 `BASE.applyJsonToChatSheets` 的调用。
13+
- **结果:**
14+
- **功能恢复:** 外部触发的填表功能（如0层模式）现在可以成功完成，并在操作后正确地将数据同步回内存，消除了相关的 `TypeError` 错误。
15+
- **健壮性提升:** 确保了与核心数据管理器的交互使用了正确的API，提升了系统的稳定性和可靠性。
16+
- **受影响文件:**
17+
- `scripts/runtime/separateTableUpdate.js` (修正了核心API调用)
18+
- `项目文档.txt` (新增此条目)
19+
20+
v6.0.6-hotfix-typing-effect
21+
- **核心修复: 解决了v6.0.6版本中因逻辑错误导致打字机效果完全失效的问题。**
22+
- **问题:** 在实现“点击正文跳过”功能时，错误地通过 `cloneNode` 复制并替换了正文的容器元素。这导致原始的、用于显示文本的 `textContainer` 变量失去了与DOM的关联，后续所有向其添加文本的操作都无法在界面上呈现，造成“不出字”的现象。
23+
- **解决方案:**
24+
1. **重构 `startTypingEffect` 函数:**
25+
- **移除错误的 `cloneNode` 逻辑:** 不再复制或替换任何DOM元素，确保所有操作都在原始的、正确的元素上执行。
26+
- **统一的 `finishTyping` 函数:** 创建了一个统一的函数来处理所有结束打字机的场景（自然完成、点击Skip、点击正文）。该函数负责清除定时器、显示完整文本，并最重要地——**移除事件监听器**。
27+
- **安全的事件监听器管理:**
28+
- 在每次打字机效果**开始时**，为`.skip-text-btn` 和 `.maho-text-container` **直接**绑定 `onclick` 事件，指向 `finishTyping` 函数。
29+
- 在 `finishTyping` 函数中，将这两个元素的 `onclick` 属性设置为 `null`，确保事件监听器被彻底清除，避免了内存泄漏和后续的意外触发。
30+
- **实现方式:**
31+
- **1. 修改 `新界面美化完全版.html`:**
32+
- 在 `startTypingEffect` 函数内部，彻底重写了其逻辑。
33+
- 删除了所有 `cloneNode` 和 `replaceChild` 的调用。
34+
- 将事件绑定从 `addEventListener` 改为直接的 `element.onclick` 赋值，以便于通过 `element.onclick = null` 来轻松移除。
35+
- 增加了 `finishTyping` 辅助函数来集中管理所有收尾工作。
36+
- **结果:**
37+
- **功能恢复:** 打字机效果和文本显示已恢复正常。
38+
- **功能完善:** “点击正文跳过”和速度控制功能现在可以无冲突地协同工作。
39+
- **健壮性提升:** 新的事件管理机制更加安全和高效。
40+
- **受影响文件:**
41+
- `新界面美化完全版.html` (重构并修复了 `startTypingEffect` 函数)
42+
- `项目文档.txt` (将 `v6.0.6` 更新为修复日志)
43+
44+
v6.0.5-feature-avatar-management
45+
- **核心功能: 为重要人物的自定义头像增加了删除功能，完善了头像管理的生命周期。**
46+
- **问题:** 用户上传了自定义头像后，没有简便的方式可以撤销该操作并恢复到默认或文件头像。
47+
- **解决方案:**
48+
1. **动态添加删除按钮:**
49+
- 在 `openCharacterModal` 函数中，当为角色弹窗加载头像时，会检查 `localStorage` 中是否存在该角色（以角色名为键）的自定义头像。
50+
- **如果存在**，则在头像的右上角动态创建一个小巧的 “×” 删除按钮。
51+
- **如果不存在**，则不显示该按钮，保持界面简洁。
52+
2. **安全的删除流程:**
53+
- 点击删除按钮会弹出一个确认框，请求用户二次确认，防止误操作。
54+
- 用户确认后，程序会从 `localStorage` 中移除对应的头像缓存条目。
55+
3. **即时反馈:**
56+
- 删除成功后，会弹出一个提示，告知用户操作已完成。
57+
- 整个UI会自动刷新，弹窗会关闭，此时该角色的头像会立即回退到加载列表中的下一个可用头像（文件系统头像或最终的默认头像）。
58+
- **实现方式:**
59+
- **1. 修改 `新界面美化完全版.html`:**
60+
- 在 `openCharacterModal` 函数内部：
61+
- 为头像容器 `#modal-character-portrait` 增加了相对定位。
62+
- 在 `findAndSetAvatar` 调用之后，增加了一段逻辑：检查 `localStorage` 中是否存在 `st-beautify-ui-avatar-角色名` 的键。
63+
- 如果存在，则动态创建、设置样式并添加一个绝对定位的删除按钮到头像容器中。
64+
- 为删除按钮绑定 `onclick` 事件，该事件包含了 `e.stopPropagation()` (防止触发上传)、调用 `showCustomConfirm`、在确认后从 `localStorage` 中 `removeItem`，以及最后调用 `refreshWithData` 刷新界面的完整流程。
65+
- **结果:**
66+
- **完善了管理闭环:** 用户现在不仅可以上传自定义头像，还可以随时、安全地将其删除，实现了完整的“增-删”管理功能。
67+
- **提升了用户体验:** 功能入口直观（直接在头像上），操作流程有防误触机制，且反馈及时清晰。
68+
- **受影响文件:**
69+
- `新界面美化完全版.html` (在角色弹窗逻辑中增加了动态创建和处理删除按钮的功能)
70+
- `项目文档.txt` (新增此条目)
71+
72+
v6.0.4-feature-avatar-enhancement
73+
- **核心功能: 彻底重构了角色头像的加载与管理机制，实现了强大的自定义与健壮性。**
74+
- **问题 1 (功能):** 重要人物的头像（侧边栏与弹窗）无法像主角头像一样支持用户自定义上传，降低了沉浸感。
75+
- **问题 2 (健壮性):** 图片加载逻辑过于单一，仅尝试加载特定名称的 `.png` 文件，缺乏对网络波动、其他图片格式（如 `jpg`）以及用户自定义缓存的支持。
76+
- **解决方案:**
77+
1. **引入统一的头像加载服务 (`findAndSetAvatar`):**
78+
- 新增了一个核心辅助函数 `findAndSetAvatar`，它封装了所有头像的加载逻辑。
79+
- **加载优先级:** 严格按照以下顺序进行加载，确保最佳用户体验：
80+
1. **浏览器缓存 (LocalStorage):** 优先加载用户为特定角色（通过角色名唯一识别）上传的自定义头像 (Base64)。
81+
2. **本地/网络文件系统:** 如果缓存中没有，则根据表格中填写的“头像”字段，智能尝试加载多种常见图片格式（`png`, `jpg`, `jpeg`, `gif`, `webp`）。
82+
3. **最终回退:** 如果以上所有尝试均失败，则显示一个统一的、硬编码的默认“未知人物”头像。
83+
4. **容错处理:** 如果连默认头像也加载失败，则显示一个带“?”的纯色背景，保证UI的完整性。
84+
2. **为重要人物开启头像上传功能:**
85+
- **弹窗内头像:** 现在点击重要人物弹窗中的圆形头像，会直接触发文件选择框，允许用户上传新图片。
86+
- **侧边栏头像:** 点击右侧重要人物列表中的方形头像，同样会触发文件选择。
87+
- **智能命名与存储:** 上传的图片会被转换成Base64格式，并以 `st-beautify-ui-avatar-角色名` 的格式作为键名，存储在浏览器的 `localStorage` 中。这完美实现了您要求的“通过提取姓名对图片进行改名”的缓存效果。
88+
3. **逻辑集成:**
89+
- 全面修改了 `openCharacterModal` (角色弹窗) 和 `refreshWithData` (渲染右侧人物列表) 中的代码，使其不再使用旧的、脆弱的图片加载方式，而是统一调用新的 `findAndSetAvatar` 服务。
90+
- **实现方式:**
91+
- **1. 修改 `新界面美化完全版.html`:**
92+
- **新增 `findAndSetAvatar` 函数:** 实现了上述的多源、多格式、多层回退的头像加载逻辑。
93+
- **修改 `openCharacterModal` 函数:**
94+
- 为弹窗内的头像元素 (`#modal-character-portrait`) 增加了 `onclick` 事件，用于触发文件上传。
95+
- 上传成功后，以角色名为键，将图片Base64存入 `localStorage`，并立即刷新界面。
96+
- 将原有的 `img.src` 赋值逻辑替换为对 `findAndSetAvatar` 的调用。
97+
- **修改 `refreshWithData` 函数:**
98+
- 在渲染右侧重要人物列表 (`people-around-container`) 的循环中，为每个角色的头像元素 (`person-portrait`) 也增加了 `onclick` 事件。
99+
- 同样，将其图片加载逻辑也替换为对 `findAndSetAvatar` 的调用。
100+
- **结果:**
101+
- **极大的自定义自由度:** 所有角色（包括主角和重要人物）的头像现在都支持用户随时更换，且更换后立即在所有界面生效。
102+
- **前所未有的健壮性:** 新的图片加载逻辑能从容应对各种情况（自定义、多种格式、网络失败），确保角色头像始终能以最佳方式显示。
103+
- **受影响文件:**
104+
- `新界面美化完全版.html` (新增核心函数，并重构了所有与角色头像相关的加载和交互逻辑)
105+
- `项目文档.txt` (新增此条目)
106+
1107
v6.0.3-hotfix-collaborative-saving
2108
- **核心修复: 再次重构并完善了协同保存机制，以完美实现“等待-接力”式的数据持久化。**
3109
- **问题:** 上一版的修复（v6.0.2）通过跳过自动保存来避免冲突，但这并不完全符合用户的期望，因为在锁定期间发生的新更改可能会丢失。用户的意图是“等一方记录完了再进行另一方的记录”，而不是直接取消。

0 commit comments

Comments
 (0)