玩家申诉"打了 boss 没掉东西",客服核对流水属实后需要补发——补发没有流程约束时会重复补发(同一申诉两个客服各发一次),或者补发未绑定导致道具二次流通。掉落补偿封装:申诉受理生成补偿单,核验流水后按单补发绑定物品,补偿标记防重复,全程留痕。
补偿单与核验补发:流水核验、绑定补发、标记防重。示例代码如下:
local function createClaim(actorName, bossId, itemHash)
local claimId = "CL" .. os.time() .. math.random(100, 999)
local actor = getplayerbyname(actorName)
setplayvar(actor, "HUMAN", "Claim_" .. claimId,
bossId .. "|" .. itemHash .. "|pending", 1)
sendmsg(actor, 1, "申诉已受理,编号 " .. claimId .. "。")
return claimId
end
local function approveClaim(actorName, claimId, item, num)
local actor = getplayerbyname(actorName)
local rec = getplayvar(actor, "HUMAN", "Claim_" .. claimId) or ""
if string.find(rec, "|done", 1, true) then
sendmsg(actor, 1, "该补偿已发放,请勿重复领取。")
return false
end
giveitem(actor, item, num, 1, "掉落补偿")
setplayvar(actor, "HUMAN", "Claim_" .. claimId,
string.gsub(rec, "|pending", "|done"), 1)
return true
end
流水核验示例代码如下:
local function verifyDrop(actorName, bossId, ts)
local log = getsysvar("DropLog_" .. actorName) or ""
return string.find(log, bossId .. "|" .. ts, 1, true) ~= nil
end
createClaim 把 boss、物品特征与 pending 状态打包落库生成补偿单号。approveClaim 先查单据状态,done 标记拦截重复补发;giveitem 第 4 参 1 绑定发放,补发物不可流通。verifyDrop 用服务端掉落流水核验申诉真实性,查无记录的申诉直接驳回。
掉落补偿踩过三个坑:一是掉落流水只保留了 7 天,超期申诉无从核验只能按玩家口述补发,流水保留期对齐申诉期(30 天);二是两名客服同时处理同一申诉,都查到 pending 各自发奖——补发动作以补偿单状态做原子闸门,先查后改必须同事务;三是补发的绑定物品再次丢失无法追溯,补发记录单独留痕,二次丢失可凭记录走升级流程。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
一、一行代码拆解:PENDING[reqId] = callback —— 异步调用的请求与应答是两次独立触发,靠请求号在 …
一、隐蔽陷阱:穿戴只查等级不查部位,两件武器同时"在身",属性双倍叠加 15 分钟后才被巡查发现;每个部位是唯一槽,穿戴前先…
一、线上事故:仓库键被历史 bug 写坏成 "a,,3",读取端解析出空段报错 800 次;与其堵每个读取方,不如读取时发现…
一、抛坑提问:战报队列被写入端疯狂灌,消费端来不及取,队列涨到 5 万条内存告警——队列满时的正确姿势不是硬塞,是背压拒收加…
一、抛坑提问:名单表用 pairs 遍历发奖励,"第一个领的当队长"——为什么今天队长换人了?pairs 的顺序由哈希内部决…
一、一行代码拆解:Top-K 的候选榜按组各留一份——先按职业分桶,桶内各自维护前 3 小榜,全表一遍扫完,免掉先全排再按组…