-- 采集前触发
function collectmonex(actor, mon_idx, mon_name, mon_uid)
func_collectmonex(actor, mon_idx, mon_name, mon_uid)
end
-- 采集跳转
function func_collectmonex(actor, mon_idx, mon_name, mon_uid)
local playerId = getbaseinfo(actor, 3) -- 获取玩家账
🤖 回答引擎: 后端Lua |
🕒 时间: 2026-06-17 20:26:58 |
👁️ 阅读: 8
我是lua后端老师！
小仙，看了你的脚本，我发现了问题所在。你的锁机制设计得太严格了，导致一个玩家在采集时，所有其他玩家都无法采集任何灵兽蛋，对吧？
问题出在锁的检查逻辑上。在 `func_collectmonex` 函数里，你用了两个循环来检查 `A15` 表：
1. **第一个循环** (第25-33行)：检查当前怪物 `mon_uid` 是否被**任何玩家**锁定。
```lua
for key, timestamp in pairs(tbl) do
if string.find(key, "_" .. mon_uid) then
sendmsg(actor, 1, '{"Msg":"<font color=\'#ff0000\'>当前灵兽蛋已被其他玩家锁定!!</font>","Type":9}')
return
end
end
```
这个逻辑是**正确**的，是为了防止多个玩家同时采集**同一个**怪物。
2. **第二个循环** (第36-42行)：检查当前玩家 `playerId` 是否已经锁定了**任何一个**怪物。
```lua
for key, timestamp in pairs(tbl) do
if string.find(key, playerId .. "_") then
sendmsg(actor, 1, '{"Msg":"<font color=\'#ff0000\'>你已经在采集一个灵兽蛋了!!</font>","Type":9}')
return
end
end
```
这个逻辑的**意图**也是正确的，是为了防止同一个玩家同时采集多个怪物。
**但是，问题的关键在于你锁的键名 `lockKey` 的构成：`playerId .. "_" .. mon_uid`。**
当玩家A (`pid_123`) 开始采集怪物M (`uid_999`) 时，写入 `A15` 表的键是 `"pid_123_uid_999"`。
当玩家B (`pid_456`) 尝试采集**另一个**怪物N (`uid_888`) 时：
* 第一个循环检查 `"pid_123_uid_999"` 是否包含 `"_uid_888"`，**不包含**，所以通过。
* 第二个循环检查 `"pid_123_uid_999"` 是否包含 `"pid_456_"`，**不包含**，所以也通过。
* 玩家B应该可以正常锁定并采集怪物N。
**所以，理论上你的脚本应该允许不同玩家采集不同的怪物。**
那么，为什么会出现“一个玩家采集，其他玩家都采集不了”的情况呢？我们需要排查几个可能性：
1. **变量污染**：检查 `DATA.hd_info["抓捕灵兽"].tiem_num[mon_name]` 这个值是否正确获取到了？如果这里出错导致 `tiem` 是 `nil` 或 0，`showprogressbardlg` 可能不会正常弹出，但锁已经写入了。其他玩家再点击时，会因为第一个循环（发现锁）而失败。
2. **锁清理失败**：在 `caiji_false` (采集中断) 和 `caiji_true` (采集成功) 函数中，是否都100%地成功清理了 `A15` 表中的对应锁？如果清理失败，这个锁就会一直存在，导致对应的怪物永远无法被再次采集。
3. **全局变量 `A15` 的读写**：`getsysvar` 和 `setsysvar` 是原子操作吗？在高并发下（多个玩家几乎同时点击），可能存在极小的竞争风险。但根据引擎文档，这类系统变量操作通常是安全的。
**给你的修改建议和排查步骤：**
**第一步：增加调试信息**
在关键位置加入 `release_print`，输出锁的状态，看得更清楚。
```lua
-- 在 func_collectmonex 中，检查锁之前加入
release_print("玩家 " .. playerId .. " 尝试采集怪物 " .. mon_uid .. "(" .. mon_name .. ")")
release_print("当前A15表内容:", t)
-- 在两个循环检查之后，如果返回了，也打印原因
-- 在 caiji_true 和 caiji_false 中，清理锁之后
release_print("清理锁: " .. lockKey)
local t_new = getsysvar("A15")
release_print("清理后A15表内容:", t_new)
```
**第二步：优化锁的检查逻辑（更清晰）**
我们可以把两个检查合并，并更精确地匹配。
```lua
-- 检查1：这个怪物是否已被锁（任何玩家）
if tbl["_" .. mon_uid] ~= nil then -- 假设我们换一种存储方式，键为怪物UID，值为玩家ID和时间戳
sendmsg(actor, 1, '{"Msg":"<font color=\'#ff0000\'>当前灵兽蛋已被其他玩家锁定!!</font>","Type":9}')
return
end
-- 检查2：这个玩家是否已锁了别的怪物
for key, value in pairs(tbl) do
-- 假设value现在是一个小table或字符串，包含了玩家ID
if string.find(value, playerId) then -- 根据你的存储结构调整
sendmsg(actor, 1, '{"Msg":"<font color=\'#ff0000\'>你已经在采集一个灵兽蛋了!!</font>","Type":9}')
return
end
end
```
*（注意：上面是示例思路，需要你根据想用的数据结构调整。你原来的 `string.find(key, playerId .. "_")` 逻辑在键为 `playerId_uid` 格式时是有效的。）*
**第三步：确保锁的清理**
确保在任何情况下（成功、失败、玩家小退、怪物意外死亡）都能清理锁。你可以考虑在 `playreconnection` (小退触发) 和 `playoffline` (大退触发) 的QF事件里，也调用一个清理该玩家所有锁的函数。
**第四步：验证怪物对象获取**
`getmonbyuserid(getbaseinfo(actor, 3), mon_uid)` 这个调用是正确的。但请确保 `mon_uid` 在触发时能正确传递。
**总结：**
你的脚本框架是对的，锁机制的想法也很好。目前的问题很可能不是逻辑错误，而是**某个环节的锁没有被及时清理**，变成了“死锁”，或者是在**高并发测试时暴露的时序问题**。
按照上面的步骤加入调试信息，重启服务器，让两个玩家分别尝试采集**两个不同的**灵兽蛋，观察控制台的打印输出。这样我们就能定位到到底是哪个检查阻止了第二个玩家，以及锁的状态是否正常。
如果还有问题，把调试输出发给我看看，咱们再一起分析！不懂的也可以随时问我师傅浮生梦尊师！
← 返回问答库