沙城主老区奖励能无限领取，核心是脚本中 “变量控制逻辑偏差” 和 “领取后状态未重置” 导致。结合你给出的脚本代码，具体问题点及修复方案如下：
一、老区奖励无限领的核心漏洞：变量操作不匹配
这是最关键的问题，直接导致领取条件永远满足：
问题代码位置：
老区奖励清理触发的 [@qc] 里，设置的控制变量是mov g211 1（意为 “允许领取老区奖励”）；
领取老区奖励的 [@yd] 脚本中，领取成功后却执行dec g212 1（意为 “减少 g212 变量数值”）。
漏洞原理：控制 “能否领取老区奖励” 的变量是 g211，但领取后却修改了无关的 g212 变量，导致 g211 始终保持 1 的 “可领取” 状态，下次点击领取仍能满足equal g211 1的条件，实现无限领取。
二、其他潜在问题：加剧漏洞的 2 处细节
除核心变量问题外，以下 2 点会让漏洞更难察觉，也影响奖励发放准确性：
1. 老区奖励变量未初始化 “不可领取” 状态：
脚本中只有 [@qc] 能将 g211 设为 1，但未在服务器重启、每日凌晨等节点设置mov g211 0（意为 “禁止领取”）。若管理员忘记手动触发 [@qc]，老区奖励会一直处于 “不可领取”；但一旦触发，又因变量不匹配导致无限领。
2. 领取成功提示重复且无 “单日限制” 判断：
[@yd] 脚本中sendmsg 0重复 4 次相同提示，仅造成冗余；更关键的是，未添加 “当日是否已领取” 的额外判断（如新增变量g213记录领取日期，领取后标记日期，次日重置），若修复变量后未加此判断，仍可能出现 “一天内多次领取” 的问题。
三、针对性修复方案：3 步改代码，彻底解决无限领
结合脚本结构，直接修改以下代码即可，无需大幅调整框架：
第一步：统一老区奖励控制变量：
将 [@yd] 中的dec g212 1改为dec g211 1，让领取后能正确减少控制变量数值。修改后 [@yd] 的核心代码为：
[@yd]
#if
HOUR 22 22
MIN 1 59
ISCASTLEMASTER
#act
give 城主之刃 2
（中间省略装备发放代码）
GameGold + 8000
dec g211 1 // 关键修改：将g212改为g211
sendmsg 0 沙城主%s,已经成功领取老区每日攻城奖励！
（说明：领取后 g211 从 1 变为 0，下次再触发 [@lqc1] 时，会因EQUAL g211 0跳转到 [@wb] 提示 “奖励已发放完毕”）
第二步：添加变量每日自动重置逻辑：
在服务器脚本的 “每日定时任务” 模块（通常是 QFunction-0.txt 或专属定时脚本）中，添加凌晨 0 点重置代码，避免管理员手动操作：
[@DayReset] // 每日0点自动触发的标签
#act
mov g211 0 // 重置老区奖励为“不可领取”状态
mov g25 0 // 同步重置合区奖励变量（避免合区奖励也出现类似问题）
第三步：新增 “单日领取限制” 判断（可选但推荐）：
若想更严谨，可新增日期变量g213记录领取日期，防止修复后仍有 “一天内多次领取”（如变量被误改回 1）：
在 [@yd] 的 #if 条件中添加日期判断：
#if
HOUR 22 22
MIN 1 59
ISCASTLEMASTER
EQUAL g213 0 // 新增：判断当日是否未领取
#act
（原有装备、金币发放代码不变）
dec g211 1
mov g213 1 // 标记当日已领取
sendmsg 0 沙城主%s,已领取今日老区攻城奖励！
在每日定时任务的 [@DayReset] 中同步重置g213 0。
四、修复后测试要点
模拟领取流程：用管理员账号触发 [@qc]（设置 g211=1），切换沙城主账号在 22:01-22:59 领取，查看 g211 是否变为 0，再次领取是否跳转到 [@wb]；
跨日测试：等待每日定时任务触发后，查看 g211、g213 是否自动重置为 0，是否需要重新触发 [@qc] 才能领取；
变量检查：通过脚本调试命令（如@checkvar g211）查看变量数值变化，确认领取前后变量修改正确。
