首页 / 资料归档 / 历史文档归档

历史文档归档

之前零散写在桌面、工程目录、飞书里的方案文档和分析报告,全部盘点在这里。 结论已经吸收进百科正文,原件保留供追溯—— 需要「当时是怎么想的」「和谁确认过什么」时来这里。

7 篇已原样归档,可直接打开 14 篇 Markdown 已索引 12 篇 docx/xlsx 仅登记路径

0. 怎么用这一页

① 已归档
HTML 原件复制到了 archive/legacy/, 点标题直接打开。样式是原来的,没有改动。
② 已索引
Markdown 留在原位置,这里记录绝对路径 + 核心结论。 需要细节时按路径去找。
③ 仅登记
docx / xlsx 需要 Office 打开, 这里只记它是什么、什么时候用得上。
归档文档的时效性 这些文档写于 2026 年 4~8 月,其中的代码行号、协议号可能已经过时。
最典型的:同步瞬移协议文档里写的是 15513 / 15514,实际落地时改成了 14716 / 14717。
协议号以 协议总索引 为准,那一页是从 NetDefine.ts 实测出来的。

1. 传送专题(Desktop/传送/)

这是最大的一组,从 2026-04-29 的业界调研一路做到 8 月的超时兜底,完整记录了同步瞬移改造的全过程。

1.1 已原样归档(可直接打开)

同图传送超时兜底 · 业界方案调研
业界三种做法对比 + 三条没有例外的铁律(任何等待必须有超时、 超时后要降级不能卡死、单点故障不能饿死队列)+ 逐条对照本项目的代码。
这份文档直接催生了 SceneWaitWpStreamingCmd 的 10 秒超时放行。
2026-08-12 · 24 KB · 原名 08_同图传送超时兜底业界调研.html
流送源怎么丢的 · 跨图卡 Loading 根因
「灯」(StreamingSource)的完整机制说明:玩家灯 vs 落点灯、 两条命令链并发抢同一个全局灯、交接间隙玩家灯漂回旧位置。
看不懂「灯」这个说法的话,先读这一篇。
2026-07-09 · 25 KB · 原名 08_流送源怎么丢的.html
A→B 传送时序 · 重力锁与 WP 流送
四个角色(脚下 WP / 目标 WP / 重力锁 / 玩家输入)的 8 步完整时序、 重力锁窗口有多长、解锁的 6 个出口、两种典型翻车、关键常量表。
排查「传送后下坠」时先看这张时序。
2026-07-30 · 22 KB · 原名 09_传送时序_重力锁与WP流送.html
跨关卡传送流程 · SceneLoadingWpMapCmd
2026-07-08 · 19 KB · 原在 TypeScript/docs/
TeleportController Seq 嵌套回调与循环问题
2026-07-10 · 37 KB · 原在 TypeScript/ 根目录
传送落地「弹起几帧」根因与保底方案 · 角色1014
下落技能 1018 先于落地 Seq3 播完结束,硬切蒙太奇 + 恢复重力 + 切相位三连击 与还在驱动角色的 Seq3 打架。
临时修复=两侧长度对齐(已验证);保底=双驱动完成闸门 + 长度校验(设计完成待实施)
2026-08-31 · 23 KB · Codely 会话分析留档

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)
一句话方案(README 原文) 把「客户端流送 → Confirm → 服务器才传送」的两阶段握手, 改成 MMO 通用的「服务器立刻改坐标,客户端用演出 + 缓存协议遮盖流送过程」。
底层握手对所有 reason 统一,表现层按 reason 分支保留。
→ 这条设计一直沿用到现在, 参见 传送 reason 分支表。

1.3 协议改动文档

Desktop\传送\teleport-sync-client-protocol.md · 2026-05-12

服务器给的协议契约文档,含 mermaid 序列图和逐协议作用表。三条关键时序约束:

1
TeleportSelfSCNotify 必须先于 ServerEntityMoveSCNotify
玩家自己也在 AOI 内会收到位置广播,顺序反了就会先看到瞬移再黑屏。 由服务器在 doServerMove 内部保证
2
位置广播携带的 server_move_version 已自增
客户端后续上行 ClientEntityMove 如果 version 落后会被服务器丢弃
3
LoadDone 必须携带最近一次本地玩家的 server_move_version
用于区分短时间内的多次连续传送。 服务器校验 version 匹配才生效,落后则丢弃—— 否则旧 loading 的 Done 会错配新传送, 导致玩家还在新 loading 里服务器就解禁了主控选举
这份文档的协议号已过时 文中写的是 ClientSameSceneLoadDoneCSReq = 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 / 策划的方案变更说明,记录了一次重要的设计转向:

最初诉求
星级按通关时间判定,服务端希望简单配一个 int 分钟数组 (10/9/5 分 → 1/2/3 星)。
为什么废弃
QA 提出星级条件要可扩展,不只时间, 后续会有「受击次数」等维度。 int 只能表达时间,表达不了不受伤、用指定角色等。
最终结论:星级判定改走「条件系统」(条件 ID) 星级条件 = 指向条件表 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 是 0Z 抬高到 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. 飞船 / 落兵船惯性

落兵船跳跃惯性 + 防跳出 实现说明
已原样归档,可直接打开。结构很完整: 名词解释 → 之前什么情况 → 根本原因 → 关键突破:找到可靠的数据源 → 现在怎么改 → 防弹飞的安全阀 → 方案演进(踩过的坑)。
最后那节「方案演进」是精华——记录了被证伪的假设。
2026-07-09 · 19 KB · 原名 落兵船惯性实现说明.html
飞船跳跃惯性丢失 + 跳出碰撞体_解决方案.md
44 KB,最长的一份。Desktop\飞船跳跃惯性丢失+跳出碰撞体_解决方案.md
核心教训:一开始判断是 GetActorBounds 参数用错, 改了没效果——假设被证伪; 真根因是同帧 Spawn 时序,包围盒还是全零。
→ Bug#19
2026-07-08 · ConfigId 70215 落兵船

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。

四条安全红线(原文照录) ① 绝对不要在 bash / git bash / WSL 里对 junction 用 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. 从这批文档里总结出的写作经验

给不同人写不同的文档
传送方案拆成 5 份(README / 调研 / 服务器清单 / 客户端方案 / 客户端明细), 每份标明受众。
服务器同学只看 03,不用被客户端细节淹没—— 一份「什么都有」的文档等于所有人都不看。
先写「一句话需求 / 一句话方案」
README 开头两句话就把整件事说清楚了。 读者用 30 秒判断这份文档是不是自己要找的,比目录管用。
明确标出「范围外」
传送 README 用 ✅/⏸️ 标出「同关卡全改、跨关卡不动、副本进出不动、 登录重连不动」,还注明是哪天和谁确认的。
这一条在后面几个月里挡掉了大量「顺手也改一下」的诉求。
给非程序写的文档要带「速查表」
结算相机配置说明的「现象 → 原因 → 改哪」表, 让美术自己解决了大部分问题。
文档的价值不是「写清楚了」,是「别人不用来问你」。
记录被证伪的假设
落兵船那份的「方案演进(踩过的坑)」一节最有价值—— 它说明了为什么最后的方案长这样, 避免后人把已经试过的错路再走一遍。
文档会过时,要留追溯路径
协议文档里的 15513/15514 已经变成 14716/14717。
解法不是不断更新旧文档(成本太高且容易漏), 而是建一个「以什么为准」的单一事实源—— 就是 协议总索引 这样的页面。