68 lines
4.3 KiB
Go
68 lines
4.3 KiB
Go
|
package routers
|
|||
|
|
|
|||
|
|
import (
|
|||
|
|
"context"
|
|||
|
|
"sync"
|
|||
|
|
)
|
|||
|
|
|
|||
|
|
var _ = sync.Mutex{}
|
|||
|
|
var _ = context.Background
|
|||
|
|
|
|||
|
|
//
|
|||
|
|
// 赛车「赛事车辆 + 检查点推进」两个 C2S 回执（R217, 2026-10-01）。
|
|||
|
|
// WHY THIS FILE EXISTS
|
|||
|
|
// 这两个包在 R216 之前**从来没有 handler**（Handlers 里连名字都没有，只有 MethodId 常量），
|
|||
|
|
// 于是它们落到 DefaultUnknownInvoke4229938 的 typed-default 兜底：客户端拿到 err=0 的**假 OK**
|
|||
|
|
// 就继续跑。表面无害，实际有两个代价：
|
|||
|
|
// 1. 服务端**完全不知道**玩家选了哪条赛道 / 哪辆车，也不知道检查点走到第几个 —— 结算、AI 路线
|
|||
|
|
// 和任何防作弊校验都没有数据来源，只能重新从 raidId 反推。
|
|||
|
|
// 2. 一旦哪天客户端在回调里读回执的**真实载荷**（而不是只看 err），typed-default 的空体立刻变成
|
|||
|
|
// 「字段全 0」的伪数据，而那时故障点会跑到客户端里去，比在这里显式回一句更难查。
|
|||
|
|
// 所以本轮把它们补成「显式 ack + 落日志」，语义与 typed-default 完全一致（都是 void → 空 OK），
|
|||
|
|
// 但服务端从此握有真相。不改变任何既有行为：注册前是兜底回 0，注册后是显式回 0。
|
|||
|
|
// 线格式（客户端 generated writer，LuaGen/AutoGen/ClientToGameDelegate.lua，逐字节核对过）：
|
|||
|
|
// <code>
|
|||
|
|
// AskSetRacingCompetitionVehicle 63764162
|
|||
|
|
// SerializerHelper.AskSetRacingCompetitionVehicle_Serializer(writer, trackid, vehicleid)
|
|||
|
|
// WriteUInt32(trackid) + WriteUInt32(vehicleid) = 8 B
|
|||
|
|
// 客户端调用点：RacerManager.lua:208 gClientToGameDelegate:AskSetRacingCompetitionVehicle(trackId, vehicleId)
|
|||
|
|
// AskSetTaskCounterValue 63753212
|
|||
|
|
// SerializerHelper.AskSetTaskCounterValue_Serializer(writer, taskid, counterindex, value)
|
|||
|
|
// WriteUInt32(taskid) + WriteInt32(counterindex) + WriteInt32(value) = 12 B
|
|||
|
|
// 客户端调用点：CarRaceManager.lua:204 / :247 / :431（过检查点、换圈、终点）
|
|||
|
|
// </code>
|
|||
|
|
// ★ 这两个日志是**判读检查点是否真的在推进**的判据（R216 的结论：检查点 = taskCounterList =
|
|||
|
|
// SpoonTaskMgr 的 workActions，空图 ⇒ 永不上报）。白天实测时：
|
|||
|
|
// * 出现 [RACE][COUNTER] ⇒ 客户端真的在过检查点 ⇒ 任务图装载成功；
|
|||
|
|
// * 一条都没有 ⇒ 图仍为空（workActions=0），检查点这条线依旧死。
|
|||
|
|
// ⛑ 回滚：删掉 GameRouter.cs 的 Enabled4229938MethodIds 里对应的两行即可（回到 typed-default 兜底），
|
|||
|
|
// 本文件保留无害。
|
|||
|
|
//
|
|||
|
|
//
|
|||
|
|
// AskSetRacingCompetitionVehicle(63764162) — 玩家在挑战面板选定的赛事车辆。
|
|||
|
|
// 触发时机：RacerManager.TrySetCompetitionVehicle 走完所有早退分支之后。★ 反过来说，
|
|||
|
|
// 这条日志**出现与否本身就是「门开没开」的判据**：R216 定案该函数有两个**不打日志**的早退分支
|
|||
|
|
// （trackId 无效 / 没有赛车手职业），以及一个打日志的「未找到玩家载具」分支。现在把门修好了
|
|||
|
|
// （urbanJobOverrides 给 15020967 加了 job 4），这条日志应当开始出现。
|
|||
|
|
//
|
|||
|
|
func GameRouter_RacingVehicle_AskSetRacingCompetitionVehicleAccept(ctx context.Context, conn any, msg any) any {
|
|||
|
|
// Router implementation for GameRouter_RacingVehicle_AskSetRacingCompetitionVehicleAccept
|
|||
|
|
var zero any; return zero
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
//
|
|||
|
|
// AskSetTaskCounterValue(63753212) — 检查点计数器上报。
|
|||
|
|
// counterIndex 在客户端是**下标**语义（CarRaceManager.lua 传的是 rankPointIndex-1 之类），
|
|||
|
|
// value 是 0/1（0=离开，1=到达）。这里原样记录，不做校验 —— 检查点状态由客户端自己
|
|||
|
|
// 维护 taskCounterList，服务端目前没有可与之对齐的权威表（任务图的 workActions 才是，
|
|||
|
|
// 而它取决于 Spoon 图是否装载成功）。
|
|||
|
|
// ★ R234（2026-10-01）：本 handler 不再只是「记录」。`index == RacingClientCheckpointCount`
|
|||
|
|
// 的那一条 = 客户端**跑完全程**的完成上报（见方法内注释），它会立刻叫醒
|
|||
|
|
// `RunRacingAutoStartAsync` 里等待的那局 ⇒ 推 `GAMEOVER` + `SyncRacingResultData`。
|
|||
|
|
// 这就是「服务端接进结算逻辑」——R217 写下这段注释时留的那个挂点。
|
|||
|
|
//
|
|||
|
|
func GameRouter_RacingVehicle_AskSetTaskCounterValueAccept(ctx context.Context, conn any, msg any) any {
|
|||
|
|
// Router implementation for GameRouter_RacingVehicle_AskSetTaskCounterValueAccept
|
|||
|
|
var zero any; return zero
|
|||
|
|
}
|
|||
|
|
|