寄售行挂单后玩家想调价:一口价 800 万金币的裁决之杖挂了一整天无人问津,降价才有流量。但改价裸奔会出事:截拍前一秒压价狙击正常竞价者、反复横跳刷系统结算、先涨价钓鱼再跳票。工程化三道闸:只许降不许涨、改价收差价 2% 手续费(最低 5000 金币)、截拍前 10 分钟禁改。
挂单登记:写订单变量(价格|截止时刻)与寄售托管物。示例代码如下:
local function listOrder(actor, itemName, price)
actor = getplayerbyname(actor)
if not takeitem(actor, itemName, 1) then
sendmsg(actor, 1, "背包里没有" .. itemName .. "。")
return
end
local orderId = "O" .. os.time()
local deadline = os.time() + 86400
setplayvar(actor, "HUMAN", "Order_" .. orderId, price .. "|" .. deadline, 1)
setplayvar(actor, "HUMAN", "Escrow_" .. orderId, itemName, 1)
sendmsg(actor, 1, "寄售已挂单[" .. orderId .. "],24 小时后截拍。")
end
改价三闸依次过:截止窗、方向闸、手续费闸,全部通过才落新价。示例代码如下:
local function relist(actor, orderId, newPrice)
actor = getplayerbyname(actor)
local record = getplayvar(actor, "HUMAN", "Order_" .. orderId) or ""
local oldPrice, deadline = string.match(record, "(%d+)|(%d+)")
if oldPrice == nil then
sendmsg(actor, 1, "订单不存在或已结算。")
return
end
if os.time() > tonumber(deadline) - 600 then
sendmsg(actor, 1, "距截拍不足 10 分钟,禁改价。")
return
end
if newPrice >= tonumber(oldPrice) then
sendmsg(actor, 1, "只许降价,不许回调。")
return
end
local fee = math.max(5000, math.floor((tonumber(oldPrice) - newPrice) * 2 / 100))
if not takeitem(actor, "金条", math.ceil(fee / 10000)) then
sendmsg(actor, 1, "改价手续费需 " .. fee .. " 金币,金条不足。")
return
end
setplayvar(actor, "HUMAN", "Order_" .. orderId, newPrice .. "|" .. deadline, 1)
sendmsg(actor, 1, "改价成功:" .. oldPrice .. " => " .. newPrice .. "。")
end
setplayvar(actor, varType, varName, varValue, isSave):订单与托管物两个变量都要 isSave 传 1,寄售是资产链路。string.match(record, "(%d+)|(%d+)") 一次解析价格与截止时刻。takeitem 返回布尔:手续费扣不到即改价失败,新价不落。orderId 由服务端用时间戳生成,玩家输入永远不参与变量名拼接,杜绝越权改单。
改价功能踩过三个坑:一是手续费按差价 2% 没设下限,改 1 金币收零头引发大量微小改价占结算,最低 5000 金币的费用门槛把横跳压干净;二是截止窗早期用"剩余 10 分钟"的客户端提示做判断,玩家改本机时间绕过,服务端必须拿 os.time 与落库的绝对截止时刻比;三是订单变量名早期拼接了玩家提交的单号,攻击者扫别人的 Order_ 键直接改了他人的价,变量键一律服务端生成、校验归属后才可操作。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
学员常见误区 Lua函数可返回多个值,学员用固定变量数接收时如果变量少于返回值,多余返回值被静默丢弃;如果变量多于返回值,多…
设计初衷 行会建筑的死穴是一次全解锁:会员没有逐步建设的过程感。梯度设计让每栋建筑都有前置条件和资源门槛。 数值模型 建筑分…
设计初衷 婚姻系统的属性加成是社交玩法的经济锚点:加成太弱没人结婚,太强则"为了属性被迫结婚"扭曲了社交本质。婚姻边界的设计…
设计初衷 宝箱类玩法的信任危机都源于同一句话:"概率是不是骗人的。"期望公示把概率从事后争议变成事前契约:奖池概率表全量公示…
设计初衷 流拍物(拍卖未成交的退回物品)堆积在卖家背包里成为死资产:低价值物流拍后无人问津,高价值物流拍后卖家不愿降价重拍。…
业务场景 沙巴克战功榜每周结算,玩家提交战功前不知道"再打多少能进前 10、前 10 的奖励是什么"。名次预览:输入自己的战…