传奇夺宝脚本漏洞解析：背包满状态下的宝盒归属错误与修复方案

当玩家背包已满时站在宝盒刷新点，系统会错误判定其“持有宝盒”（显示红箭头标记并触发公告），但实际宝盒仍在地面。30分钟后，所有被标记的玩家均可触发@打开宝盒事件领取奖励，导致多人重复开奖，严重破坏活动公平性。

漏洞根源分析
逻辑缺陷：拾取验证缺失

脚本中[@MapEventPickUpItem]事件在玩家接触宝盒时立即触发，但未检测背包空间是否充足。若背包已满，系统仍执行以下操作：

发送全服公告：“玩家XX携带宝盒”

添加顶戴花翎（红箭头标记）

启动定时器SetOnTimer 7 30

关键问题：宝盒实际未被拾取，但玩家已被标记为“持有者”。
开奖条件宽松

[@打开宝盒]事件仅依赖定时器触发，未验证玩家是否真实持有宝盒（如检测背包或变量状态）。

修复方案与优化脚本

步骤1：增加拾取成功验证

在[@MapEventPickUpItem]中插入背包检测逻辑，仅当宝盒进入背包才标记持有者：
[@MapEventPickUpItem]
IF

CHECKBAGITEM 宝盒 1 // 检测宝盒是否在背包
ACT

SendMsg 0 宝盒已经在:[%M].坐标:[%x:%y]被玩家〖<$USERNAME>〗拾取
SENDMSG 0 玩家〖<$USERNAME>〗携带宝盒出现在[%M][%x:%y]...
SendCenterMsg 180 251 还剩余%d开启宝盒... 0 60 @打开宝盒
SetOnTimer 7 30
CALL [\游戏登陆\顶戴花翎.txt] @顶戴花翎

ELSEACT // 背包满时进入此分支

SendMsg 0 玩家〖<$USERNAME>〗尝试拾取宝盒失败（背包已满）！
Break

步骤2：开奖前验证宝盒持有状态

在[@打开宝盒]事件开头增加双重验证：
[@打开宝盒]
IF

CHECKBAGITEM 宝盒 1 // 验证背包是否有宝盒
CheckContainsText <$SERVERNAME> 宝盒持有者 // 验证变量标记（需新增）
ACT

movr N6 34
goto @开奖
ELSEACT

SendMsg 5 错误：你未持有宝盒，无法开奖！
SetOffTimer 7 // 关闭定时器
Break

步骤3：新增宝盒持有者全局变量
初始化变量：在宝盒生成时，用全局变量（如宝盒持有者）记录唯一持有者名字。

清除机制：玩家丢弃宝盒或开奖后，立即清空该变量。

漏洞危害与修复必要性
风险类型 具体影响 修复后效果

经济失衡 多人重复领取顶级道具（如情侣男装） 仅实际持有者可领取奖励
活动崩溃 10人同时开奖导致服务器资源耗尽 单次开奖减轻服务器压力
玩家信任 利用漏洞刷奖励引发普通玩家不满 保障活动公平性

补充优化建议
丢弃宝盒的惩罚机制

当前[@DropItem]会踢出玩家，但未清除其“持有者”标记。需在KICK前添加：
DELTEXTLIST ..\QuestDiary\宝盒持有者.txt <$USERNAME> // 删除持有记录
SetOffTimer 7 // 关闭定时器

宝盒唯一性保障

地图每次仅刷新1个宝盒，避免多个宝盒同时存在引发混淆。

开奖后立即销毁宝盒实体，防止残留触发事件。
日志监控

记录宝盒拾取/开奖的玩家IP、时间，便于追溯异常行为。

最终修复效果：只有实际拾取宝盒并背包有空间的玩家会被标记，开奖时通过双重验证确保奖励唯一性，彻底解决多人重复开奖问题。建议测试时模拟背包满、断线等极端场景，以验证稳定性。