历史文档归档
之前零散写在桌面、工程目录、飞书里的方案文档和分析报告,全部盘点在这里。 结论已经吸收进百科正文,原件保留供追溯—— 需要「当时是怎么想的」「和谁确认过什么」时来这里。
0. 怎么用这一页
archive/legacy/,
点标题直接打开。样式是原来的,没有改动。最典型的:同步瞬移协议文档里写的是
15513 / 15514,实际落地时改成了 14716 / 14717。协议号以 协议总索引 为准,那一页是从
NetDefine.ts 实测出来的。
1. 传送专题(Desktop/传送/)
这是最大的一组,从 2026-04-29 的业界调研一路做到 8 月的超时兜底,完整记录了同步瞬移改造的全过程。
1.1 已原样归档(可直接打开)
这份文档直接催生了
SceneWaitWpStreamingCmd 的 10 秒超时放行。
看不懂「灯」这个说法的话,先读这一篇。
排查「传送后下坠」时先看这张时序。
内容已并入 场景加载命令链, 这里只作为图形版留存。图上把 ⑦⑧⑩⑪ 画成同一个开关, 实际是两组不同条件。
临时修复=两侧长度对齐(已验证);保底=双驱动完成闸门 + 长度校验(设计完成待实施)
1.2 方案文档五件套(已索引)
路径:C:\Users\zhaozibo\Desktop\传送\
| 文件 | 受众 | 核心内容 |
|---|---|---|
| README.md | 所有人 |
入口文档。阅读顺序、一句话需求、改造范围、推进流程。 范围(服务器 2026-04-29 确认):同关卡传送全部改, 跨关卡 / 副本进出 / 登录重连都不动。 |
| 01_业界调研.md | 所有人 | 19 KB。为什么要改:现状问题 + 业界 MMO 的通用做法 |
| 02_最终方案.md | 所有人 | 整体架构 + 时序 + 风险评估 |
| 03_服务器改动清单.md | 服务器 | 服务器要改的 9 项 + 排期参考 |
| 04_客户端改动方案.md | 客户端 | 整体设计、影响面、回归测试范围 |
| 05_客户端改动明细.md | 客户端实施 | 20 KB。每个 PR 改哪个文件哪一行 |
| 06_最终方案_v2.md | 所有人 | 2026-05-08 修订版 |
| 07_服务器立刻传送调研.md | 所有人 |
16 KB。回包时机 + 4 条防坠路径 + reason 判定表。 传送类问题先查它,再读代码。(另有 docx 版本 ×2) |
底层握手对所有 reason 统一,表现层按 reason 分支保留。
→ 这条设计一直沿用到现在, 参见 传送 reason 分支表。
1.3 协议改动文档
Desktop\传送\teleport-sync-client-protocol.md · 2026-05-12
服务器给的协议契约文档,含 mermaid 序列图和逐协议作用表。三条关键时序约束:
TeleportSelfSCNotify 必须先于 ServerEntityMoveSCNotifydoServerMove 内部保证server_move_version 已自增ClientEntityMove 如果 version 落后会被服务器丢弃server_move_versionClientSameSceneLoadDoneCSReq = 15513 / SCRsp = 15514,
实际落地为 14716 / 14717(WorldClientSameSceneLoadDone*)。文中「暂保留待清理」的
15504 / 15505 / 15506
(PreServerMove 三件套)已经删除完毕。协议号一律以 协议总索引 为准。
1.4 分析与修复文档
| 文件 | 内容 | 现在在哪 |
|---|---|---|
| 传送地形消失修复方案.md 2026-07-23 |
四个根因 + 四个 Fix 的完整方案: ① 两条命令链并发抢同一个全局灯(含日志证据) ② 玩家灯在交接间隙被 Tick 拉回旧位置 ③ TargetLevelId=0 生成不存在的 DataLayer 标签④ LevelLayerName 复制被 IsValid 守护,落点灯失效时丢失最后附验证方法表(哪些异常日志应该消失) |
Bug#5 传送 · 地形卸载 |
| 传送问题分析_视频对比.md 2026-07-22 |
18 KB。对着两段录屏逐帧分析(同目录有 飞书20260722-*.mp4 两个原始视频) |
分析过程,结论已吸收 |
| 08_流送源被回收卡Loading根因.md 2026-07-09 | HTML 版的文字底稿 | 已归档 HTML 版 |
| 切world时序风险分析.md 2026-05-22 |
五个风险点:ClearServerEntityData 清空所有实体、
ClearHandlerAndCancelLoading 强 cancel 挂起态(黑屏没移除 / 锁没解 /
pending handler 变孤儿)、TryEnterWorldServer 相当于软重连、
OnLeaveWorldNotify 的 TODO 没填、同 world 与换 world 判定不同抗损建议: OnLeaveWorldNotify 里主动收尾再让 EnterWorld 跑 |
未落地。 待和服务器确认 LeaveWorld+EnterWorld 在哪些场景触发 |
2. 爬塔星级系统方案
C:\Users\zhaozibo\Desktop\爬塔星级系统方案.md · 2026-06-08
面向服务器 / QA / 策划的方案变更说明,记录了一次重要的设计转向:
Condition 的 ID,条件本身自带判定逻辑 + 描述文本。收益:新增任何星级维度 = 条件系统里加一个条件类型, 星级判定和追踪提示两端自动支持,业务代码零改动。
这也回到了需求文档原本的设计。
| 端 | 职责 |
|---|---|
| 策划 | ① 条件表配条件(判定逻辑 + Description);② 关卡组表「星级条件 1/2/3」填条件 ID |
| 服务器 | 通关结算时按条件 ID 逐档判定 → 得出星级 → 下发客户端 |
| 客户端 | ① 结算界面显示星级(读服务器结果);② 关卡内追踪星级提示实时显示 |
关卡内追踪提示的设计(需求第 5 条)
新增 ChildQuest 子任务类型「显示星级提示」,关卡行为树调用。
节点激活 → 左上角列出每条条件的 Description →
客户端 CheckConditionNew 实时判定,
达成 = 实心图标 + 正常字体,未达成 = 空心 + 置灰。
个别纯服务器条件客户端测不了 → 降级方案: 只显示文本不实时切换,或由服务器下发「第几条已达成」。
→ 最终落地用的是服务器下发路线:
20532 全量 + 20533 单档增量,
参见 爬塔 · 局内 HUD。
文档最后还留了 4 条待服务器 / QA 反馈的问题,都是设计阶段该问的: 星级判定改条件 ID 是否 OK、新条件类型客户端能否本地检测、 提示节点是手填还是自动取、条件文本统一用 Description 是否可行。
3. 环境子弹 TypeId 拼装规则
C:\Users\zhaozibo\Desktop\环境子弹TypeId拼装规则.md · 2026-06-16
这份文档已经完整吸收进 关卡子弹 · TypeId,
包括分段表、fixServerBulletId / GetBulletIdFromInfo 源码、
实例验算和反查方法。看百科页即可,不必再翻原文。
唯一值得单独拎出来的是那条命名陷阱:
BulletTypeId 实际是 BulletType
function GetBulletIdFromInfo(EntityConfigId, BulletConfigId, BulletTypeId) {
// ↑ 第三个形参名叫 BulletTypeId,实际是 BulletType(0=子弹 / 1=发射器)
// 不是最终拼出来的 TypeId,别被名字误导
const ConfigStr = BulletTypeId === 1 ? '1' : '0';
}
实例验算:950101 + 00201 + 000 + 0
= 950101002010000,与行为树截图完全一致。
4. 结算相机调度(Desktop/文档/)
4.1 结算相机配置说明(给美术填表用)
Desktop\文档\结算相机配置说明.md · 2026-06-02
这是一份写给非程序看的说明书,是这批文档里质量最高的一份,值得作为写策划文档的模板。
② 字段表带「建议初值」列——填表的人不用猜从哪开始。
③ 专门一节讲坐标空间:「UE 角色前方 = +X」「相机跑到背后就把 X 改成负数」。
④ 最后是「现象 → 原因 → 改哪」的速查表, 覆盖了 6 种常见翻车,美术能自己解决大部分问题不用来问程序。
| 现象 | 原因 | 改哪 |
|---|---|---|
| 相机贴脸 / 看不到角色 | CameraOffset 是 0 | 填 (300,0,150) 类偏移 |
| 相机在角色背后 | 前后方向反了 | CameraOffset.X 取负 |
| 相机看向角色脚下 | LookAtOffset 是 0 | Z 抬高到 100 左右 |
| 运镜瞬间完成 / 不动 | TweenDuration 是 0 | 填 1~2 秒 |
| 进不了最后的特写 | MVP 行 Seq2 没填 | 填上 Seq2 资产 |
| 运镜很生硬 | 没配缓动曲线 | 给 CameraPosCurve 做 ease-out |
调试时日志过滤关键字:副本结算。
UCurveVector 的横轴是归一化时间 0~1,纵轴是插值进度 0~1,留空 = 匀速直线。
4.2 结算相机调度 · 结构设计方案
Desktop\文档\结算相机调度-结构设计方案.md · 2026-06-01 · 9 KB
程序侧设计:FSSettlementCameraConfig(FTableRowBase + UCurveVector)的结构定义,
以及把 Seq1 换成逐帧 Tween 相机调度的方案。
→ 落地情况见 结算 · Tween 相机。
5. 飞船 / 落兵船惯性
最后那节「方案演进」是精华——记录了被证伪的假设。
Desktop\飞船跳跃惯性丢失+跳出碰撞体_解决方案.md核心教训:一开始判断是
GetActorBounds 参数用错,
改了没效果——假设被证伪;
真根因是同帧 Spawn 时序,包围盒还是全零。→ Bug#19
6. 工作流与环境
6.1 开分支操作手册
Desktop\文档\开分支操作手册.md · 2026-04-29
和业务无关,但每次开新分支都要用。 Claude Code 的 memory 按项目目录哈希隔离, 每个分支 workspace(065 / 070 / 080…)会各自生成一份独立 memory。 解决办法是用 NTFS junction 把所有分支的 memory 指向同一份真实数据。
C:\Users\zhaozibo\.claude\shared-memory\ ← 真实数据,唯一一份
▲ ▲
│ │
065\memory 070\memory ← 都是 junction
新开分支时两条 cmd 命令(必须用 cmd,不能用 bash / PowerShell):
rmdir "C:\Users\zhaozibo\.claude\projects\<新项目目录>\memory"
mklink /J "C:\Users\zhaozibo\.claude\projects\<新项目目录>\memory" "C:\Users\zhaozibo\.claude\shared-memory"
目录名规则:分支根路径删掉 :、\ 换成 -。
如 C:\Client080\Source\Client\TypeScript →
c--Client080-Source-Client-TypeScript。
rm -rf——
bash 看不出 junction 是链接,会跟进去把 shared-memory 里所有文件全删光。
删 junction 必须用 cmd 的 rmdir(不带 /s)。② 不要直接删
shared-memory——真实数据,删了所有分支一起丢。③ mklink 一律用绝对路径——相对路径按 cwd 解析,容易接错。
④ 不要在 PowerShell 里跑 mklink——它是 cmd 内建命令, 要么开 cmd,要么
cmd /c mklink ...。
6.2 其它 Markdown
| Desktop\文档\v3.12.2-zh.md | 某工具的中文版本说明,7 KB |
7. 仅登记(docx / xlsx,需 Office 打开)
路径:C:\Users\zhaozibo\Desktop\文档\(除特别标注外)
| 文件 | 什么时候用得上 |
|---|---|
| 客户端技术问题快速QA.docx 11.8 MB · 2025-11-21 |
体量最大的一份。客户端通用技术问答, 遇到框架层面的陌生问题可以先搜这个 |
| 战斗代码review问题记录2025_11_12.docx 11.4 MB |
战斗模块的 review 问题记录。改 Src/CombatDesignerScript
(有独立严格 lint 的那个目录)之前值得看 |
| 爬塔2期需求文档.xlsx 79 MB · 2026-06-08 |
爬塔需求原件。查「这个功能当初到底要求的是什么」时用 |
| 范围组件迭代.xlsx 1.3 MB |
边界检查重生用的范围盒组件的迭代需求 |
| 子弹优化推进.docx 1.8 MB |
关卡子弹的优化推进记录 |
| 怪物关卡指令技能 WarpingToLevelLocation.docx 1.2 MB |
怪物传送到关卡点位的指令技能。和玩家传送是不同的链路,别混 |
| 试用角色功能.docx 914 KB |
试用角色(entity 替换模式 + SkinId 换皮)的需求原件 |
| 程序需求-0.7.0-结算相机调度配置工具.docx 配置工具-结算相机调度.docx 各 35 KB |
结算相机调度的需求文档与配置工具说明, 4.1 的 Markdown 版是它的通俗改写 |
| 宇宙编辑器AI开发实战.docx 597 KB |
宇宙编辑器相关的开发实践记录 |
| Nami Agent知识库搭建.docx ×2 AI开发工作流探索.docx 273 / 227 / 159 KB |
AI 辅助开发工作流的探索记录 |
| 传送\07_服务器立刻传送调研.docx 传送\07_..._v2.docx 传送\调研传送逻辑改为服务器立刻传送的方案.docx 40 / 40 / 203 KB |
1.2 节那份 Markdown 的 docx 版本(含排版,用于对外发送) |
8. 原始素材
| 传送\飞书20260722-192653.mp4 传送\飞书20260722-192707.mp4 |
35 MB / 30 MB。传送问题的录屏原件,
配合 传送问题分析_视频对比.md 看。
需要复现某个已修 bug 的原始表现时用 |
9. 从这批文档里总结出的写作经验
服务器同学只看 03,不用被客户端细节淹没—— 一份「什么都有」的文档等于所有人都不看。
这一条在后面几个月里挡掉了大量「顺手也改一下」的诉求。
文档的价值不是「写清楚了」,是「别人不用来问你」。
解法不是不断更新旧文档(成本太高且容易漏), 而是建一个「以什么为准」的单一事实源—— 就是 协议总索引 这样的页面。