Ananta-ps/internal/gameserver/routers/game_router_traffic.go

package routers

import (
	"context"
	"sync"
)

var _ = sync.Mutex{}
var _ = context.Background

// 
// T3-7 真实车流 —— 服务端驱动车辆沿车道跑。
// ★ 为什么必须服务端驱动：客户端侧没有任何「车流密度解锁」S2C 包。
// 人流有 SyncSetCrowdDensity(68996045) + SyncCrowdSpecifiedDensityRefresh(68195167)，
// 车流只有 C2S 的 GmChangeAetherVehicleDensity(69493525)。实测：服务端一个 vehicle 包都不发
// 时，街上一台车都没有（含路边停放）。所以车必须逐台下发并持续推进。
// ★ 推进方式：服务端只发「车道 handle + DistanceAlongLane」，客户端 AetherCity 侧的
// MassTrafficInterpolationUtils 按本地 ZoneGraph 曲线插值出位置与朝向。
// 这是捐赠端 §88「车歪 + 走一点就停」的正解 —— 那条路靠服务端算世界坐标，这里不算。
// ★ ControlType：VehicleControlType { Invalid=0, AetherVehicle=1, RaidVehicle=2 }。
// T1-16 骇入用 2（不接管驾驶），T3-7 必须用 1，否则客户端不做车道模拟。
// 
func GameRouter_Traffic_ShouldPushLaneData(ctx context.Context, owner any) bool {
	// Router implementation for GameRouter_Traffic_ShouldPushLaneData
	return true
}

func GameRouter_Traffic_TrafficState(ctx context.Context, session *GameSession) any {
	// Router implementation for GameRouter_Traffic_TrafficState
	var zero any; return zero
}

// 
// 世界就绪后调用一次；幂等。配置关掉或车道表缺失就直接返回。
// ⛑ 2026-09-29：改为 async —— 起循环前先清掉**上一个会话残留**的车
// （见 LiveTrafficIds 的注释）。不清的话切场景 / 切角色后
// 上一批车会原封不动留在客户端世界里冻着。
// 
func GameRouter_Traffic_EnsureTrafficAsync(ctx context.Context, session *GameSession) any {
	// Router implementation for GameRouter_Traffic_EnsureTrafficAsync
	var zero any; return zero
}

// 断开 / 切场景时停掉循环。
func GameRouter_Traffic_StopTraffic(ctx context.Context, session *GameSession) any {
	// Router implementation for GameRouter_Traffic_StopTraffic
	var zero any; return zero
}

func GameRouter_Traffic_RunTrafficLoopAsync(ctx context.Context, session *GameSession, owner any, token context.Context) any {
	// Router implementation for GameRouter_Traffic_RunTrafficLoopAsync
	var zero any; return zero
}

// 
// 一台车的服务端视角位置（XZ）。
// ⛑ Cruise 车（TrafficCar.Cruise）没有真实坐标 —— 客户端不上报 AI 车的
// 移动，而我们也不再推车道插值 ⇒ 只能用「上次下发的目标点」当估算值。
// 回收距离判定、出生避撞判定都读这里，别直接调 VehicleLaneGraph.PositionOf
// （对 Cruise 车那是冻结在出生点的假坐标，会导致永远回收不掉）。
// 
func GameRouter_Traffic_TrafficCarPos(ctx context.Context, car any, x float32, z float32) any {
	// Router implementation for GameRouter_Traffic_TrafficCarPos
	var zero any; return zero
}

// 
// 这条车道上已经有车了吗（按各车的出生车道比）。见 TrafficSpawnAvoidSameLane。
// ⛑ 近似判据：车的 Drive.Lane 是出生车道、之后不再更新，所以这是
// 「这条车道最近被占着」的保守判断（会占到那台车被回收为止），方向正是我们要的「错开」。
// 
func GameRouter_Traffic_LaneAlreadyUsed(ctx context.Context, owner any, lane int32) bool {
	// Router implementation for GameRouter_Traffic_LaneAlreadyUsed
	return true
}

// 
// 这条车道的前进方向是不是朝着玩家（玩家在车头前方 ⇒ 车会开过来，形成迎面车流）。
// 见 AetherSettings.TrafficSpawnFacePlayerRatio。
// 
func GameRouter_Traffic_HeadsTowardPlayer(ctx context.Context, lane int32, sx float32, sz float32, player Vec3) bool {
	// Router implementation for GameRouter_Traffic_HeadsTowardPlayer
	return true
}

// 候选出生点是否与现有车辆离得足够远。
func GameRouter_Traffic_FarFromOtherCars(ctx context.Context, owner any, x float32, z float32, minGap float32) bool {
	// Router implementation for GameRouter_Traffic_FarFromOtherCars
	return true
}

// 按玩家位置把车辆数维持在 target 台；跑出路网或跑太远的车回收。
func GameRouter_Traffic_ReconcileTrafficAsync(ctx context.Context, session *GameSession, owner any, player Vec3, cfg any, rng any, stamp float64, token context.Context) any {
	// Router implementation for GameRouter_Traffic_ReconcileTrafficAsync
	var zero any; return zero
}

// 
// 建出 BaseVehicle 实体本身（捐赠端 GameRouter.Vehicles.SpawnDirectAsync 的 proven 序列）：
// SyncLogicVehicleEnter → SyncSpawnVehicle → SyncChangeVehicleInteractable。
// Aether 的 AddData 只接管**已存在**的车，所以这一步必须在它之前。
// 
func GameRouter_Traffic_SpawnTrafficVehicleBodyAsync(ctx context.Context, session *GameSession, entityId uint64, configId uint32, x float32, y float32, z float32, facingDeg float32, speed float32, cfg any, token context.Context) any {
	// Router implementation for GameRouter_Traffic_SpawnTrafficVehicleBodyAsync
	var zero any; return zero
}

// 
// ★★ 方案 A（2026-10-01）：给一台车流车下发 SyncAssignVehicleAITask(68549522) +
// VehicleCruiseParameters，让客户端本地 AI 把它开走。
// 为什么换这条管线（两轮证伪后的结论）：
// ① 服务端没有「别把车提升成 GO」的有效通道（ForceGo 实机无效）；
// ② 客户端那个疑似负责 GO 切换的类 AetherVehicleViewManager，8 个探针 24 分钟
// 全 0 命中 ⇒ 根本没在用，按它设计的注入器 hook 方案整体作废。
// ⇒ 与其继续猜，不如用我们已实机验证过的驱动方式：出租车 / 玩家自驾都走
// SyncAssignVehicleAITask，车真的会自己开、会避障、会等红灯。
// ⛑ 前置条件（由调用方保证）：这台车的 AddData 必须是
// ControlType=2 + LaneHandle=-1，否则客户端的车道模拟会和本地 AI 抢方向盘。
// ⛑ 已知局限：客户端不上报 AI 车的坐标 ⇒ 服务端的 car.CruiseX/Z 只是
// 「上次下发的目标点」，回收/避撞判定全是近似值。
// 
// 
// 挑一串「能往前开」的车道当 Cruise 目标点。
// ⛑⛑ 为什么不能只从「上次目标所在车道」往后规划（2026-10-01 23:2x 实机根因）：
// 车开完第一次目标后，`CruiseLane` 落在那条路径的最后一段上 —— 而我们路网里有
// 大量死路车道（286 个孤岛分量、很多车道没有合格后继）⇒ `PlanRoute` 只给出 1 段，
// 日志刷成一串 `points=1/1`，每台车每次都拿到同一个目标点
// （`target=(901,1775) lane=6817` 反复出现）⇒ 车到点就停，再也不走。
// ⇒ 判据：规划出来的段数 < trafficCruiseMinHops 就判「死路口袋」，
// 改从玩家附近随机挑一条车道重新规划（车本来就在玩家周围 ⇒ 新目标一定可达）。
// 同时避开 RecentTargetLanes ⇒ 不会好几台车挤向同一个点互撞。
// 
// 车道终点串；空 = 实在规划不出来（调用方应跳过这次下发）。
func GameRouter_Traffic_PickCruiseRoute(ctx context.Context, owner any, car any, cfg any, rng any) any {
	// Router implementation for GameRouter_Traffic_PickCruiseRoute
	var zero any; return zero
}

// 快照场上其它 Cruise 车的当前目标点（用于新目标的空间去重）。
func GameRouter_Traffic_SnapshotOtherTargets(ctx context.Context, owner any, self any) []any {
	// Router implementation for GameRouter_Traffic_SnapshotOtherTargets
	return nil
}

// 把这条目标车道记进「最近用过」的滑动窗口（最多 24 条）。
func GameRouter_Traffic_NoteTarget(ctx context.Context, owner any, lane int32) any {
	// Router implementation for GameRouter_Traffic_NoteTarget
	var zero any; return zero
}

// 从一条车道往后规划，把每段终点收集成点串。起点拿不到几何 ⇒ 返回空串。
func GameRouter_Traffic_BuildChain(ctx context.Context, startLane int32, cfg any) any {
	// Router implementation for GameRouter_Traffic_BuildChain
	var zero any; return zero
}

func GameRouter_Traffic_AssignTrafficCruiseAsync(ctx context.Context, session *GameSession, owner any, car any, cfg any, rng any, token context.Context) any {
	// Router implementation for GameRouter_Traffic_AssignTrafficCruiseAsync
	var zero any; return zero
}

// 
// Cruise 车的推算位置推进（dead reckoning）：按当前速度朝目标点走，到点即停。
// ⛑ 为什么必须推：客户端不上报 AI 车的坐标，而回收/避撞/骇入判定全靠这个估算值。
// · 不推（一直停在出生点）⇒ 车开走了也永远判成「在身边」，老车占着名额；
// · 直接跳到目标 ⇒ 目标一超出回收半径，车刚出生就被判出界回收（23:2x 实机踩过）。
// 
func GameRouter_Traffic_AdvanceCruiseEstimates(ctx context.Context, owner any, dt float32) any {
	// Router implementation for GameRouter_Traffic_AdvanceCruiseEstimates
	var zero any; return zero
}

// 
// 客户端回报 AI 任务状态时（AskUpdateVehicleAITaskStatus）在车流这边认领一下。
// ★ 为什么要接：车开到目标点会自己停住，而服务端收不到到达通知 ⇒ 只能干等
// trafficCruiseRefreshSec（默认 30s）。日志里其实早就有这些包，只是被
// `[VEHICLE-HACK] ignored stale/duplicate/unowned AI status … status=2` 丢掉了。
// ⇒ 这里认领后把刷新时刻归零，下一 tick 立刻续发目标点，车不会在原地杵半分钟。
// ⛑ 只置标志、不在 handler 里发包（热路径上不能同步 await 一堆 Notify）。
// 
func GameRouter_Traffic_TryApplyTrafficCruiseStatus(ctx context.Context, session *GameSession, token uint64, status byte) bool {
	// Router implementation for GameRouter_Traffic_TryApplyTrafficCruiseStatus
	return true
}

// 
// 方案 A 的续驶：给到期（TrafficCruiseRefreshSec）的 Cruise 车重发目标点。
// ⛑ 为什么还要定时重发兜底：客户端不一定回状态（被顶住/卡住时可能什么都不发），
// 所以「定时器」和「收到终止状态立刻续发」是双保险 ——
// 前者兜住「客户端沉默」，后者消灭「到了还要干等 30 秒」的空窗。
// 重发对两种情形都成立：没到 ⇒ 新目标仍在它前方，等价续驶；到了 ⇒ 从脚下继续往前。
// 
func GameRouter_Traffic_RefreshTrafficCruiseAsync(ctx context.Context, session *GameSession, owner any, cfg any, rng any, token context.Context) any {
	// Router implementation for GameRouter_Traffic_RefreshTrafficCruiseAsync
	var zero any; return zero
}

// 
// 把一台车流车从车道流里摘出来，交还给玩家（骇入 / 上车）。幂等：非车流车直接返回。
// ★★ 为什么必须摘：车道流每 50ms 用 SyncAetherAIVehicleLaneDatas 覆盖里程，
// 而骇入下发的是 SyncAssignVehicleAITask（RaidVehicle 通道）—— 两套驱动源。
// 同时作用时车会「刚加速就被拽回原地」，表现为骇入「能显示但没效果」。
// 所以玩家接管的第一件事就是停掉车道流。
// ★ 摘出的手段：重发一条 SyncAetherAIVehicleAddData，
// ControlType=2(RaidVehicle) + LaneHandle=-1。
// 这与 RegisterHackVehicleAsync() 的做法一致，其注释原文：
// "ControlType=RaidVehicle avoids activating lane simulation"。
// 
func GameRouter_Traffic_DetachTrafficVehicleFromLaneAsync(ctx context.Context, session *GameSession, vehicle any) any {
	// Router implementation for GameRouter_Traffic_DetachTrafficVehicleFromLaneAsync
	var zero any; return zero
}

// 
// 每 tick 计算纵向动力学（跟车 / 交叉让行 / 加减速）→ 推进里程 → 批量下发。
// 走到死路的车直接回收。
// ★★ 为什么服务端必须自己做跟车：客户端的 AetherVehicleDetector（前方 trigger）
// 只对**近距离 GO 车**生效，实测它只避让玩家/行人（AetherVehicleStopReason.Block），
// 车与车之间照样对撞。客户端那边没有「远程车流互避」逻辑 —— 它只按服务端给的点插值。
// 所以纵向决策只能放服务端：这里是简化 IDM + 最近接近点(TTC)让行。
// 
func GameRouter_Traffic_PushTrafficLaneDataAsync(ctx context.Context, session *GameSession, owner any, dt float32, stamp float64, cfg any, rng any, token context.Context) any {
	// Router implementation for GameRouter_Traffic_PushTrafficLaneDataAsync
	var zero any; return zero
}

// 一台车的寿命摘要（回收日志用）—— 用来量化「车开多远就没了」。
func GameRouter_Traffic_CarLife(ctx context.Context, car any) string {
	// Router implementation for GameRouter_Traffic_CarLife
	return ""
}

// 
// 回收一台车流车 —— **必须连 SyncDestroyVehicle 一起发**。
// ★★ 只发 SyncAetherAIVehicleRemove 是不够的（2026-09-28 实测）：
// 那个包只把车从 Aether 车流系统里摘掉，**BaseVehicle 实体仍留在客户端场景里**。
// 服务端这边已经把它从 Cars 移除、不再推里程，所以 [TRAFFIC-STAT] 看着一切正常
// （stop=0、avg 10m/s），但客户端那台车就那么杵在原地 ——
// 用户看到的就是「大部分车停在十字路口」，以及「有些车开着开着变色然后停下」
// （实体脱离 Aether 驱动后渲染状态异常）。
// ⇒ 补发 SyncDestroyVehicle 才是真正销毁，与 DestroyVehicleAsync 的做法一致。
// 
func GameRouter_Traffic_RemoveTrafficVehicleAsync(ctx context.Context, session *GameSession, runtime any, id uint64, token context.Context) any {
	// Router implementation for GameRouter_Traffic_RemoveTrafficVehicleAsync
	var zero any; return zero
}

// 本会话当前持有的车流车 id。
func GameRouter_Traffic_OwnedIds(ctx context.Context, owner any) []any {
	// Router implementation for GameRouter_Traffic_OwnedIds
	return nil
}

// 
// 把本会话的车流车**真回收**：逐个发 SyncAetherAIVehicleRemove + SyncDestroyVehicle。
// 照抄 RetireAmbientPedsAsync 的做法（分块 + 间隔，别一次性连发打爆 socket）。
// 
func GameRouter_Traffic_RetireTrafficAsync(ctx context.Context, session *GameSession) any {
	// Router implementation for GameRouter_Traffic_RetireTrafficAsync
	var zero any; return zero
}

// 
// 清掉**上一个会话**留下的残留车（本会话不知道它们、但客户端世界里还在）。
// 判据：进程级 LiveTrafficIds 里不属于本会话的那些 id。
// 
func GameRouter_Traffic_RetireStrayTrafficAsync(ctx context.Context, session *GameSession, owner any) any {
	// Router implementation for GameRouter_Traffic_RetireStrayTrafficAsync
	var zero any; return zero
}

// 
// 挑一台「能上路」的车。
// ★ 第一优先是 VehicleSpawnCatalog4229938（客户端 MassAI.MassTraffic 的
// VehicleSpawnConfig 表，InMass+CanDrive 共 54 个车型）。只有在这张表里的 cfgId 才能
// 建出 VehicleDataEntity —— 否则客户端打
// VehicleInit_Drop_NoConfig ... not found in VehicleSpawn 并丢弃，车看得到但不会动。
// fleet 列表只作为该表缺失时的兜底。
// 
func GameRouter_Traffic_PickTrafficConfigId(ctx context.Context, rng any) any {
	// Router implementation for GameRouter_Traffic_PickTrafficConfigId
	var zero any; return zero
}

// ★ 车辆实体必须用 8_200_000_000_000_000_000 号段（与 GameRouter.Vehicle.cs:25 同一分配器）。
//   2026-09-21 实测：用 7_000_000 这种小整数时客户端完全不建实体 —— 街上没车，
//   而服务端日志一切正常（AddData / LaneDatas 都在发）。号段不对 = 实体识别失败。
//   参照：行人 8_300_000_000_000_000_000（DonorNpc.cs:32）、NPC 归属 8_310_...、token 7_100_...
type TrafficCar struct {
	Id uint64 `json:"id"`
	ConfigId uint32 `json:"configId"`
	Drive DriveState `json:"drive"`
	Speed float32 `json:"speed"`
	TargetSpeed float32 `json:"targetSpeed"`
// 速度接近 0 的累计秒数（用于僵局解除）。
	StallSeconds float32 `json:"stallSeconds"`
// --- 寿命计量（2026-09-29）：用来量化「车开多远就停/消失」，别再靠肉眼猜 -------
// 累计行驶里程（米）。回收/超距时打进日志。
	TraveledMeters float32 `json:"traveledMeters"`
// 累计换道次数。
	Hops int32 `json:"hops"`
// 存活秒数。
	AliveSeconds float32 `json:"aliveSeconds"`
// 出生时刻（Environment.TickCount64）。Cruise 车不进 tick 推进，寿命只能这么算。
	SpawnTicks int64 `json:"spawnTicks"`
// 僵局解除后的「硬冲」剩余秒数：> 0 时无视让行约束，低速强行通过。
	BoostSeconds float32 `json:"boostSeconds"`
// 
// 红灯前已经等了的秒数（只在真正被红灯刹停时累加）。
// 超过 TrafficSignalMaxWaitSec 就放行 —— 给「等红灯」一个统一上界，
// 否则腿数多的路口（4 组周期 44s）会让人觉得车杵在那儿不动。
// 
	RedWaitSeconds float32 `json:"redWaitSeconds"`
// 
// 在 VehicleRuntimeState.Vehicles 里对应的登记记录（null = 未登记）。
// 有了它车才是「可骇入」的：ExecuteVehicleControlAsync 第一步就是
// runtime.Vehicles.TryGetValue(vehicleId)，找不到直接拒绝。
// 每 tick 会把位置/朝向同步进去（骇入的 30m 距离判定和 AI 任务包都读它）。
// 
	Record *VehicleRecord `json:"record"`
// 
// 预规划路径（接下来要走的车道序列，不含当前车道）。null/空 = 退回随机挑后继。
// 由 VehicleLaneGraph.PlanRoute 生成，走完会自动重新规划。
// 
	Route []int32 `json:"route"`
// 当前走到 Route 的第几段。
	RouteIdx int32 `json:"routeIdx"`
// --- 2026-10-01 方案 A：Cruise（客户端本地 AI 驾驶）------------------------------------
// 
// true = 这台车交给客户端本地 AI 开（SyncAssignVehicleAITask + Cruise 参数），
// 不参与服务端的车道推进与 LaneDatas 批次（两套驱动源会打架：
// 「刚加速就被拽回原地」）。见配置 TrafficCruiseDrive。
// 
	Cruise bool `json:"cruise"`
// 当前 Cruise 任务的 token（刷新时要先拿它发 Abort(4)）。0 = 还没下发过。
	CruiseToken uint64 `json:"cruiseToken"`
// 上次真正下发 Cruise 目标的时刻（Environment.TickCount64），提前量判定用。
	CruiseAssignedTicks int64 `json:"cruiseAssignedTicks"`
// 下次重发目标点的时刻（Environment.TickCount64）。
	CruiseRefreshTicks int64 `json:"cruiseRefreshTicks"`
// 
// ★ 估算位置：朝当前目标按速度推算（dead reckoning）出来的坐标。
// Cruise 车的位置客户端不上报，服务端只能这么估（回收距离判定 /
// 出生避撞判定 / 骇入距离判定都读它）。推进逻辑见 AdvanceCruiseEstimates。
// ⛑⛑ 别直接把它设成目标点 —— 目标一旦超出回收半径，车会「刚出生就被判出界回收」
// （2026-10-01 23:2x 实机：`despawn id=… (out of range) after=0m alive=0s`）。
// 
	CruiseX float32 `json:"cruiseX"`
	CruiseZ float32 `json:"cruiseZ"`
// 当前目标点（估算位置朝它推进，到达即停住等下一次下发）。
	CruiseTargetX float32 `json:"cruiseTargetX"`
	CruiseTargetZ float32 `json:"cruiseTargetZ"`
// 估算位置所在的车道（= 上一个目标点所属车道），下一次规划从这里往后接。
	CruiseLane int32 `json:"cruiseLane"`
// 
// 客户端最近一次回报的 AI 任务状态
// （0 Pending / 1 Running / 2 Success / 3 Pause / 4 Abort / 5 Override）。
// 收到 2/3/4/5 就把 CruiseRefreshTicks 归零 ⇒ 立刻续发目标点，
// 不用干等 trafficCruiseRefreshSec。
// 
	CruiseStatus byte `json:"cruiseStatus"`
// 
// 这台车**固定**的巡航速度倍率（出生时按 trafficCruiseSpeedJitter 摇一次，全程不变）。
// ⛑ 为什么每台车要不一样：全都同一速度 ⇒ 两台车一旦挨上就永远并排贴着开
// （相对速度 0，谁也甩不开谁）。给了差值，快车自然拉开、慢车自然落后。
// 
	CruiseSpeedScale float32 `json:"cruiseSpeedScale"`
}

type TrafficSessionState struct {
	SyncRoot any `json:"syncRoot"`
	Cts *context.CancelFunc `json:"cts"`
	Loop *any `json:"loop"`
	Cars []TrafficCar `json:"cars"`
	LastReseedTicks int64 `json:"lastReseedTicks"`
	LastTickTicks int64 `json:"lastTickTicks"`
// 车流健康度诊断（[TRAFFIC-STAT]）的上次输出时刻。
	LastStatTicks int64 `json:"lastStatTicks"`
// 推送节拍采样：[TRAFFIC-STAT] 输出 dt 均值/峰值用，输出后清零。
	TickSamples int32 `json:"tickSamples"`
	TickSumMs float64 `json:"tickSumMs"`
	TickMaxMs float64 `json:"tickMaxMs"`
// 上次真正下发 SyncAetherAIVehicleLaneDatas 的时刻（节流用，见 TrafficLanePushIntervalMs）。
	LastLanePushMs int64 `json:"lastLanePushMs"`
// 
// 上一包 LaneDatas 的时间戳（秒，Unix）。
// ★ 客户端的 TimedSpringInterpolationMethod 是「定时弹簧」：每个点带 TargetTimeStamp，
// 客户端在 currentServerTime 走到该时刻之前把 DeltaDistance 平滑排空。
// 所以时间戳必须①指向未来（+lead）②单调递增③增量稳定 —— 三条缺一条就会出现
// 「冲一下就停 / 停很久突然补距离」。
// 
	LastTimestampSeconds float64 `json:"lastTimestampSeconds"`
// 
// 玩家最近一次的位置（XZ）。Cruise 车掉进死路口袋时要换一个「离玩家不远的新目的地」，
// 得知道玩家在哪（PickCruiseRoute 用它挑候选车道）。
// 
	PlayerX float32 `json:"playerX"`
	PlayerZ float32 `json:"playerZ"`
// 
// 最近发过的目标车道（最多 24 条）。挑新目标时避开它们 ⇒ 不会好几台车挤向同一个点
// （2026-10-01 23:2x 实机：四台车同时被分到 `target=(872,1874)`，后车顶上前车、
// 客户端 AI 倒车脱困后又停）。
// 
	RecentTargetLanes []int32 `json:"recentTargetLanes"`
}