攻沙期间城堡内出现两个行会反复争夺占领权，且机器人脚本无法自动关闭活动，核心原因在于脚本逻辑中的“占领判定条件”缺失或“结束触发机制”失效。当城堡区域内存在多个行会成员且无单一行会完全控制皇宫时，系统会判定战争持续，导致占领状态在两者间频繁切换。解决此问题需从脚本源码修改、手动强制干预及参数配置三个维度入手，彻底阻断无限循环。
首先分析反复占领的根本逻辑。标准攻沙脚本通常设定为：当皇宫内仅剩单一行会成员且持续一定时间（如5分钟），则判定该行会获胜并结束活动。若脚本未设置“最大持续时间”或“强制结束时间点”，一旦双方行会人数相当或在皇宫门口拉锯，系统永远无法满足“单一行会独占”的条件，从而陷入死循环。机器人脚本若仅依赖“检测皇宫人数”这一单一条件来执行关闭命令，必然在人数胶着时失效。必须引入“时间优先”原则，即无论战场形势如何，到达预设结束时间必须强制结算。
修改脚本以添加强制结束时间是首要方案。打开服务端脚本文件（通常位于 QFunction.txt 或专门的攻沙脚本文件如 SabukWar.txt）。查找攻沙开始的时间触发段（如 @OpenSabuk）。在该段落之后，必须明确写入一个基于绝对时间的结束触发器。使用 SETONTIME 或 TIMER 命令，设定活动开始后特定分钟数自动跳转至结束标签。例如：SETONTIME 120 @EndSabuk 表示活动开启120分钟后强制执行 @EndSabuk 标签。在 @EndSabuk 标签下，编写清理逻辑：调用 KILLMON 清理皇宫内所有怪物，使用 GOMAP 将所有参战玩家传送至安全区或主城，执行 CLEARGUILDWAR 清除行会战争状态，最后通过 SENDMSG 全服公告获胜行会（若此时仍无法判定，可默认原城主守城成功或宣布平局），并重置攻沙标志位 CLEAR SabukFlag。
针对“两个行会反复占领”的判定逻辑进行修正。检查脚本中用于判断占领成功的 #IF 条件块。原始代码可能仅写了 CHECKCOUNTMAP 皇宫地图 行会A > 0 和 CHECKCOUNTMAP 皇宫地图 行会B = 0。这种逻辑在双方都有人时会卡住。需改为“计时器锁定机制”：当检测到皇宫内只有一方行会时，启动一个内部变量计时器（如 CALC A0 = A0 + 1），每轮脚本循环（通常为1秒）累加一次。只有当该计时器达到设定阈值（如300秒）且期间未被打断（即对方行会未进入），才执行占领成功逻辑。若中途对方进入，立即 CLEAR A0 重置计时。这样可避免因瞬间的人数波动导致状态反复跳变。同时，增加“人数下限”检查，若双方人数均低于设定值（如各少于3人），直接判定活动无效或提前结束，防止挂机号导致死锁。
手动强制关闭攻沙的紧急操作步骤。若脚本已运行且陷入死循环，无需重启服务器，可通过管理员指令或控制台直接干预。登录游戏管理员账号，使用 @FIREOFF 或特定引擎的 @ENDSABUK 命令（视具体引擎版本而定，如GOM引擎常用 @AdminEndWar）。若无专用命令，可利用 M2Server 控制台执行脚本命令：!CALL @ForceEndSabuk。若上述无效，最直接的方法是修改内存变量。在M2控制台输入 SETV G100 0（假设G100是攻沙进行中标记），强制将战争状态标记清零。随后手动执行 MAPMOVE 将所有在皇宫地图的玩家批量传送至比奇安全区，命令格式可为 GROUPMAPMOVE 3 50 50（假设3为比奇地图号）。清理完人员后，重新初始化攻沙变量，确保下次活动能正常开启。
修复机器人脚本的自动检测盲区。很多机器人脚本仅在游戏主线程运行，若主线程因复杂的战斗计算出现延迟，脚本的检测频率会下降，导致错过结束窗口。建议将攻沙结束逻辑独立到一个高频触发的定时器中，不再依赖主战斗脚本的循环。在 QManage.txt 中设置一个全局秒级定时器 TIMER 1 @CheckSabukEnd。在 @CheckSabukEnd 中，第一行即判断当前系统时间是否超过预定结束时间。若超过，直接执行结束流程，忽略任何战场人数判断。这种“时间熔断”机制能确保无论战场多么混乱，活动必将在指定时刻终止。同时，在脚本中加入日志记录 SENDMSG 7 [系统] 攻沙结束逻辑已触发，便于管理员监控脚本是否正常跑通。
处理行会数据残留导致的异常。有时脚本看似执行了关闭，但行会间的战争状态（PK模式）未解除，导致玩家感觉活动仍在继续。需在结束脚本中显式调用 SETGUILDWAR 0 或遍历所有行会执行 STOPGUILDWAR 命令。检查数据库中的 GuildWar 表，若发现活动结束后仍有记录，需手动清空或通过脚本执行SQL语句 UPDATE GuildWar Set Status=0 Where MapID=Sabuk。此外，清除城堡所有权变量，确保下一次攻沙开始时，系统能重新读取正确的城主信息，避免读取到上一轮错误的中间状态。
预防措施的配置建议。在 GameCenter.txt 或活动配置表中，明确设定攻沙的“最长时间限制”。不要仅依赖开始时间，必须设定结束时间。例如：开始时间 20:00，结束时间 22:00。系统底层应优先遵循此时间窗口。对于容易出错的“占领判定”，建议改为“积分制”而非“独占制”。在攻沙期间，根据行会在皇宫内的停留时间和击杀敌对行会成员数量累计积分。时间一到，直接比较积分高低决定胜负。这种模式从根本上杜绝了因人数胶着导致的反复占领问题，因为积分是单向累加的，不会出现状态回滚。
排查引擎版本特有的脚本缺陷。部分老版本引擎（如早期BLUE内核）在处理多行会同图判定上存在先天Bug，当两个行会人数完全一致时，变量赋值会出现随机跳动。若确认是此类底层问题，唯一的解决办法是升级引擎核心文件或打官方补丁。若无法升级，则需在脚本中人为制造“微小差异”，例如在判断时优先判定行会ID较小的那一方，或者引入随机数 RANDOM 2 打破平衡，强行让系统做出选择，避免死锁。虽然这略显粗糙，但在无法修改内核的情况下是有效的临时方案。
验证修复效果的测试流程。修改完成后，切勿直接在全服上线。开启测试服，创建两个测试行会，模拟攻沙场景。故意让两个行会同时在皇宫内保持人数平衡，观察到达预定结束时间时，脚本是否强制弹出结束公告并传送玩家。同时测试在最后一秒一方突然退出的情况，确保获胜判定逻辑依然准确。检查服务器日志，确认没有报错信息，且变量重置干净。只有经过多次极端情况测试无误后，方可将脚本同步至正式环境。
彻底解决攻沙无法自动关闭及反复占领问题，关键在于摒弃单纯的“人数判定”逻辑，转而采用“时间熔断 + 积分结算 + 强制清理”的组合策略。通过完善脚本中的定时器机制，确保活动按时终结；通过优化占领算法，避免状态抖动；通过手动指令备份，掌握紧急控制权。这套组合拳能保障攻沙活动在各类复杂战况下均能平稳运行，给予玩家清晰的活动体验，维护游戏世界的秩序稳定。
