joywayerandClaude Opus 5
729128aa9d
一致性测试（同一局真包：逐包增量回放 vs 一次性 deskinfo 重连）暴露的六处前端缺陷：
① PlayHandler：table.playproc 由「字段映射错误」改为原样拷贝
原实现把这一手的 seat/cards/count/flower/cardtype 灌进 playproc，而服务端 playproc
是本轮进行态（round/start/currseat/.../cards），两者几乎无交集、撞名的 cards 语义还相反。
服务端已在 chupai1/2/3 补发 playproc，前端零推导直接镜像，不自行累积 round/maxseat。
② 本手信息改走 EQW_CARD_PLAYED 事件载荷，不进 GameState
{order, seat, cards, count?, flower?, cardtype?, shuai?, shuaicuo?}，带 ? 的缺字段不兜底。
落牌是一次性表现而非对局状态；新立 GameState 字段只会再制造一处增量/全量不一致。
③ PlayHandler：table.pushlist 逐手落盘、按轮归档（GameState.pushPlay）
chupai1 开新的一轮、2/3 落进当前轮，任意时刻都与 deskinfo 的全量重建相等（服务端
pushlist 含进行中的当前轮）。不读 chupai3.playproc.cards——那是下一轮的进行态（协议 §13）。
仅可查牌模式累积，与服务端同一道门控，否则不查牌房会凭空攒出重连没有的历史。
④ ResultHandler：归档收尾轮（最后一手走 jiesuan.chupai，不发 chupai3）
夹具实证 chupai1×28 / chupai2×28 / chupai3×27。jiesuan.chupai 只有 seat/cards/maxseat。
归档随即被结算收敛清空（deskinfo step6 不带 PushCards），但 emit 同步，落牌表现在清空前取值。
⑤ BuryHandler：接住 maipai 新增的 seatlist（此刻为全初值，界面无差别但重连侧有）
⑥ ResyncHandler 的 ChooseMain/BuryCards 补映射 curmultiple（原重连重建为 0，抓分角标掉档）；
BuryHandler 埋牌完成后清空 my.bottomCards——底牌上庄时已并入手牌，埋牌后只剩 burycards
有意义，deskinfo 的 PushCards 不下发 bottomcards，重连重建恒为 []（语义已逐条核实）。
一致性测试 8 红 → 3 红。剩余 3 条同源：服务端 maipai 漏发 playproc（与本次服务端补发
seatlist 是同一个窗口、同一个理由），前端无法自补且不得伪造，详见报告 §7 待裁决。
另有 test_handlers_play.js:84 断言的正是 ① 修掉的错误映射，按纪律未改测试，见报告 §8。
未触碰 server/、client/tests/（含夹具与 EXCLUDE）；服务端 29 checks 全绿。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
114 lines
6.0 KiB
JavaScript
114 lines
6.0 KiB
JavaScript
///////////////////////////////////////////////////////////////
|
||
////////// EQW_ResultHandler: 结算（jiesuan）与解散（Free）///
|
||
///////////////////////////////////////////////////////////////
|
||
// 协议 §14：结算包由 chupai + bottom + aset 拼装，末局再加 account。
|
||
// 三种来源的组成不同：
|
||
// 正常出牌结算：chupai + bottom + aset（末局加 account）
|
||
// 投降结算： 只有 aset（末局加 account），无 chupai、无 bottom
|
||
// 解散结算： 只有 aset + account，且【走另一个入口】，见下
|
||
//
|
||
// 【解散的特殊性】（协议 §14.1，已对平台代码核实）：
|
||
// 解散包的 route 是平台的 "room"，平台 12_Logic.js 按 route 分流时把它交给
|
||
// Net[rpc] 而【不是】Game_Modify._ReceiveData——所以它根本进不了子游戏的分发表。
|
||
// 平台另有专门入口：07_Desk.js 的 Game_Modify.Free(Desk.deskfree)。
|
||
// 两个后果：
|
||
// 1. 取值路径比协议文档少一层——平台已把 deskfree 取出来传进来，
|
||
// 所以是 deskfree.data.aset，不是 data.deskfree.data.aset；
|
||
// 2. 参数可能是 null——解散若发生在开战后、首局发牌前，服务端 get_disbandRoom
|
||
// 返回 null，平台走「不带 deskfree」分支。这时只做房间收尾、不弹结算。
|
||
var EQW_ResultHandler = EQW_ResultHandler || {
|
||
|
||
handleJiesuan: function (data) {
|
||
if (!data.hasOwnProperty('aset')) {
|
||
console.error('[EQW_ResultHandler] jiesuan 缺 aset，已跳过该包');
|
||
return;
|
||
}
|
||
this._applyResult(data);
|
||
},
|
||
|
||
//平台解散入口。deskfree = { rpc:"jiesuan", data:{ success, aset, account } }，可能为 null
|
||
handleFree: function (deskfree) {
|
||
if (!deskfree || !deskfree.data) {
|
||
//首局发牌前解散：没有结算数据，只做房间收尾，不弹结算面板
|
||
console.warn('[EQW_ResultHandler] 解散包无 deskfree 数据（首局发牌前解散）');
|
||
return;
|
||
}
|
||
var d = deskfree.data;
|
||
if (!d.hasOwnProperty('aset')) {
|
||
console.error('[EQW_ResultHandler] 解散包缺 aset，已跳过');
|
||
return;
|
||
}
|
||
this._applyResult(d);
|
||
},
|
||
|
||
//三种来源共用的落地逻辑：有哪组就写哪组，缺的保持 null
|
||
_applyResult: function (d) {
|
||
//—— 收尾轮的第三手：牌局在最后一手打完时【不发 chupai3】，整包换成 jiesuan（协议 §13/§14）——
|
||
//夹具实跑一局的包数就是证据：chupai1×28 / chupai2×28 / chupai3×27。
|
||
//只在 chupai3 归档会永远丢掉最后一轮，故在这里补齐——它必是本轮第三手，落进当前这一轮。
|
||
//jiesuan.chupai 的字段与 chupai3 不同：只有 seat / cards / maxseat，
|
||
//没有 order / playproc / cardsinhand / grade。
|
||
//归档随后会被下面的结算收敛清掉（deskinfo step6 不带 PushCards），但 emit 是同步的：
|
||
//落牌与收牌表现在清空之前就已取到完整的收尾轮。
|
||
if (d.chupai && d.chupai.hasOwnProperty('seat') && d.chupai.hasOwnProperty('cards')) {
|
||
EQW_GameState.pushPlay(d.chupai.seat, d.chupai.cards, false);
|
||
var lastPlay = { seat: d.chupai.seat, cards: d.chupai.cards };
|
||
if (d.chupai.hasOwnProperty('maxseat')) { lastPlay.maxseat = d.chupai.maxseat; }
|
||
EventBus.emit(EQW_Events.EQW_CARD_PLAYED, lastPlay);
|
||
}
|
||
|
||
//结算是"清空过程量、只留结算数据"的快照点：deskinfo step6 只带 Balance（=aset），
|
||
//其余分组一律回到 reset() 默认值——jiesuan 也要收敛到同一状态，否则重连前后画面不一致
|
||
//（清单以 ResyncHandler.handleDeskinfo 在 step6 时实际重建出的字段集为准，不多清不少清）。
|
||
EQW_GameState.aset.banker = -1;
|
||
EQW_GameState.aset.call = -1;
|
||
EQW_GameState.aset.multiple = 0;
|
||
EQW_GameState.aset.flower = 0;
|
||
EQW_GameState.aset.curmultiple = 0;
|
||
EQW_GameState.aset.grade = 0;
|
||
EQW_GameState.aset.baozhu = 0;
|
||
EQW_GameState.aset.touxiang = 0;
|
||
EQW_GameState.turn.seat = -1;
|
||
EQW_GameState.turn.countdown = 0;
|
||
EQW_GameState.call.currcall = 0;
|
||
EQW_GameState.call.calls = [null, null, null];
|
||
//末轮若由 jiesuan.chupai 带出（无 cardsinhand），出牌者自己的手牌不会被清空，这里显式清掉，
|
||
//不留幽灵牌——deskinfo 在结算阶段的 MyCards 恒为 []
|
||
EQW_GameState.my.cards = [];
|
||
EQW_GameState.my.mustCard = [];
|
||
EQW_GameState.my.bottomCards = [];
|
||
EQW_GameState.my.buryCards = [];
|
||
EQW_GameState.table.ancard3s = 0;
|
||
EQW_GameState.table.playproc = null;
|
||
EQW_GameState.table.pushlist = [];
|
||
EQW_GameState.table.seatlist = [];
|
||
EQW_GameState.table.liangpai = null;
|
||
EQW_GameState.table.mingpai = null;
|
||
|
||
EQW_GameState._apply(EQW_GameState.result, d, {
|
||
chupai: 'chupai',
|
||
bottom: 'bottom',
|
||
aset: 'aset',
|
||
account: 'account'
|
||
});
|
||
EQW_GameState.aset.step = 6;
|
||
|
||
//三家总积分：jiesuan 的 aset.seatlist[i].score 就是"累积得分"（协议 §14），
|
||
//与 deskinfo.PlayerInfo 同源同值——deskinfo 恒有的 PlayerInfo 在增量路径上没有对应来源，
|
||
//只能从这里回填，否则一局中段（fapai 后至 jiesuan 前）room.playerScores 永远追不上服务端
|
||
if (d.aset && Object.prototype.toString.call(d.aset.seatlist) === '[object Array]') {
|
||
var scores = [];
|
||
for (var i = 0; i < d.aset.seatlist.length; i++) {
|
||
scores.push(d.aset.seatlist[i] && d.aset.seatlist[i].score);
|
||
}
|
||
EQW_GameState.room.playerScores = scores;
|
||
}
|
||
|
||
EventBus.emit(EQW_Events.EQW_ASET_RESULT);
|
||
//account 只在末局或解散时才有
|
||
if (d.hasOwnProperty('account')) {
|
||
EventBus.emit(EQW_Events.EQW_ACCOUNT_RESULT);
|
||
}
|
||
}
|
||
};
|