基準快照遺失 Lost baseline for delta compression

原因 ID pt-baseline · 主要負責 遊戲開發團隊（伺服器開發） · 協同遊戲開發團隊（用戶端開發）

在伺服器只送「與上次不同的部分」的方式中，最初送一次的完整資訊（基準）遺失時，之後的變化量就無法套用。

為什麼 物件的完整資訊（基準）封包遺失，或在處理前被丟棄 → 於是用戶端沒有可以套用後續變化量的對象，只好忽略 → 畫面上 那個物件看不見，或過了很久才突然出現

症狀: 看不見／幽靈物件, 瞬移
因素: 遺失
誰會遇到: 同一台電腦只有其中一個用戶端, 只有我
何時: 偶爾隨機發生
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同遊戲開發團隊（用戶端開發）
遊戲開發團隊要做的事: 伺服器：基準在收到接收確認（ACK）前一定要重傳，變化量只針對用戶端已確認收到的基準產生。用戶端：基準實際套用後才送出接收確認（ACK），收到未知物件的變化量時向伺服器重新請求。
圖表上: 偶爾隨機飆高 · 收到未知物件變化量的次數
查看位置: 把用戶端在沒有基準時丟棄變化量的次數與物件 ID，與伺服器送出該物件基準、收到 ACK 的時間對照。在開發環境加入封包遺失（tc netem 的 loss、Unreal 網路模擬的封包遺失比例）來重現
符合的跡象: 對於看不見的物件，伺服器送了基準卻沒收到 ACK，仍持續只送變化量，而用戶端丟棄了這些變化量
不符合的跡象: 基準已收到 ACK 並套用到用戶端、仍看不見時，是消失通知遺失或物件 ID 重複使用造成誤認
確認方式: 需要遊戲伺服器／用戶端的 log 與指標

出處

Snapshot Compression Gaffer On Games
變化量只能針對對方已確認收到（ack）的基準（baseline）產生，初始狀態另外傳送
Quake III Arena source: code/server/sv_snapshot.c id Software
以用戶端確認過的快照為基準做差異壓縮，基準太舊時就送完整快照
tc-netem(8) — Linux manual page iproute2
對送出的封包加入延遲、抖動（delay TIME JITTER）與遺失（loss random PERCENT），模擬真實網路的測試工具
Using Network Emulation in Unreal Engine Epic Games
在伺服器、用戶端加入最小／最大延遲與封包遺失比例來測試，在主控台以 NetEmulation.PktLag 這類指令設定