Hey is the conflict with the HUD Ballistic Trajectory Overlay mod, something that could possibly be fixed or not?

# P-11 Self Heal v8 — permanent self-disable during a laggy session
# P-11 Self Heal v8 —— 卡顿局中永久自我关闭

**Status / 状态**：Confirmed from logs + byte-level payload inspection. Not a guess.
已由日志 + 载荷字节级核对确认，非推测。

**Reported build / 涉及版本**：`v8-wild-bridge` (Wild Bridge) with Codex Module Bridge v1, deployed as
`9ba626afa44a3aa3.patch_2` (23104 bytes). Loader: Bingus Shared Loader v15 (API 1).
采用 `v8-wild-bridge` + Codex Module Bridge v1，部署为 `9ba626afa44a3aa3.patch_2`（23104 字节）。
加载器：Bingus Shared Loader v15（API 1）。

---

## 1. Symptom / 症状

**EN** — Mid-session the mod stops working. It does **not** come back in a later mission, and a **fresh
solo session does not restore it either** — only restarting the game does. The trigger session had
network lag (one squad member stuttering, which stalls the whole room).

**中文** —— 一局中途失效；后续任务不恢复，**新开单人房间也不恢复**，只有重启游戏才能恢复。
触发的那一局有网络卡顿（联机中一人卡顿会导致整房间卡顿）。

---

## 2. The decisive log line / 决定性日志

`%LOCALAPPDATA%\StimPistolSelfHeal.log`, last two lines / 最后两行：

```
17093.062 real shot confirmed transition=rise
17093.062 stopped: table overflow
```

**EN** — The mod received a real shot, then **immediately stopped itself**. Nothing is logged after
that, although the game kept running for another hour (see §6).

**中文** —— 识别到一次真实开火，紧接着**自己停掉了**。此后日志完全空白，而游戏还继续跑了一个小时（见 §6）。

`%LOCALAPPDATA%\CodexModuleBridge.log` shows the bridge itself is fine / bridge 本身工作正常：

```
Codex Module Bridge v1; API 1
mods/codex/constitution_bolt_amr: not installed
mods/codex/p11_self_heal: loaded
```

---

## 3. Why a new session does not recover / 为什么换房间不恢复

**EN** — `stopped` is a **process-level field**, not mission state. The v8 payload's state table
contains this field list:

```
read_cycle | apply | last_key | last_status | last_report | step | loader | previous | stopped | after
```

Once `stop()` sets it, the per-frame `step` returns early every frame. No mission change, no world
reload and no new lobby clears it. **Only a game restart recovers it.**

**中文** —— `stopped` 是**进程级字段**，不是任务级状态。v8 载荷的状态表字段列表见上。
`stop()` 置位后，每帧的 `step` 都直接返回；换任务、换世界、换房间都不会清它。
**只有重启游戏能恢复。**

---

## 4. `table overflow` is a Lua runtime error, not an authored guard / 它是 Lua 运行时错误，不是作者写的守卫

**EN** — I extracted the deployed payload and searched it byte-by-byte:

| search / 检索 | result / 结果 |
|---|---|
| archive entry length / 归档条目长度 | 22902 (= 8-byte envelope + 22894 payload) |
| payload / 载荷 | 22894 bytes, LuaJIT bytecode (`1b4c4a02`) |
| literal `overflow` | **0 occurrences / 0 次** |
| literal `table overflow` | **0 occurrences / 0 次** |
| literal `table` | offset 1828 |
| literal `stopped` | offset 18333 |

The bytes around `stopped` (offset 18333) read as:

```
tostring | "stopped: " | pcall | error | stopped | step | log | called | ok | reason
```

So the code path is plainly:

```lua
local ok, reason = pcall(step, ...)
if not ok then
state.stopped = true
log("stopped: " .. tostring(reason)) -- reason == the Lua error message
end
```

**Conclusion: `table overflow` is the Lua/LuaJIT runtime error message**, caught by the mod's own
`pcall` and stringified into the log. It is **not** one of the author's guard strings.
**中文** —— 我把已部署的载荷提出来逐字节检索，结果见上表：`overflow` / `table overflow`
**一次都没出现**，而 `stopped: ` 就在偏移 18333，紧邻的字符串是
`tostring / pcall / error / stopped / step / log / ok / reason` —— 典型的
「pcall 抓错 → 置 stopped → 把错误消息 tostring 进日志」写法。
**所以 `table overflow` 是 LuaJIT 的运行时错误消息，不是作者写的守卫串。**

---

## 5. What `table overflow` means / 它的技术含义

**EN** — In Lua/LuaJIT, `table overflow` is raised when an integer used as a table key is too large
for the array part to be sized — i.e. **an oversized (or garbage) integer was used as a table index**.
Given v8's new reload/ammo-correction code (`P11_ROUNDS_MAP`, `P11_ROUNDS_PREFIX`,
`P11_ROUNDS_RECORD_OFFSET`, `P11_ROUNDS_RECORD_SIZE`, `MAX_RUNTIME_RESERVE`,
`reload correction rejected unexpected state`), the most likely candidate is a value read out of
memory being used as a map key without validation.

**中文** —— 在 Lua/LuaJIT 里，`table overflow` 的触发条件是**用作表键的整数过大**，导致数组部分无法分配 ——
也就是「**一个过大的（或垃圾）整数被当成表索引**」。结合 v8 新增的换弹/弹药校正代码
（`P11_ROUNDS_MAP`、`P11_ROUNDS_PREFIX`、`P11_ROUNDS_RECORD_OFFSET`、`P11_ROUNDS_RECORD_SIZE`、
`MAX_RUNTIME_RESERVE`、`reload correction rejected unexpected state`），
最可能是**某个内存读值未经校验就被当成 map 的键**。

I cannot pin the exact table from the outside — that needs one line of instrumentation on your side.
从外部无法确定是哪一个表，这需要作者加一行插桩。

---

## 6. Correlation with the lag event / 与卡顿的关联

**EN** — Lag stalls the game's tick rate, so per-frame sampling misses or double-samples transitions.
v8's new reload-correction path is the most timing-sensitive part. Two anomalies appear in the log
shortly before the stop:

**(a) The scan found two P-11 entities instead of one / 扫到两个 P-11：**

```
16526.484 avatar ready eid=8389030
16527.609 P-11 scan complete count=2 <-- should be 1 / 正常应为 1
```

Latching the wrong entity makes every subsequent read wrong.
latch 到错实体后，后续所有读取都会歪。

**(b) Avatar entity ids jump by three orders of magnitude / 角色实体 id 跳三个数量级：**

```
220 → 503 → 1052 → 1271 → 4194500 → 1597 → 8389030 → 12583197 → 12583628
```

I checked these: `4194500 ≈ 4×2²⁰`, `8389030 ≈ 8×2²⁰`, `12583197 ≈ 12×2²⁰` — consistent with a
`(generation << 20) | index` encoding, i.e. **legitimate ids, not misreads**. But it means ids
routinely reach the **tens of millions**. Any place that uses such an id (or a bad-offset read) as a
table key will overflow the array part.
我核算过：这几个大值分别约等于 `4/8/12 × 2²⁰`，符合 `(世代 << 20) | 索引` 的编码 ——
**是合法 id，不是读错**（我上一份报告里把它当异常，这里更正）。但这说明 **id 会常态达到千万量级**，
任何拿它当表键的地方都会炸数组部分。

---

## 7. Independent corroboration: the mod died, the game did not / 独立旁证：是 mod 死的，不是游戏

**EN** — A different v15 addon in the same process (Solo Bunker Probe) installs its clock on the
chained `_G.update` and `_G.WwiseFlowCallbacks`. It kept ticking straight through and long after the
stop:

```
2026-09-21 20:09:08 phase2 tick #261000
2026-09-21 20:10:24 phase2 tick #267000
2026-09-21 20:11:09 phase2 tick #270000 <-- 40 s AFTER the stop / 停止后 40 秒
2026-09-21 20:16:52 phase2 tick #294000
```

So the game was healthy, the shared `update` chain was alive, and the loader's hooks were intact.
**The failure is entirely internal to the P-11 mod.**
游戏健康、共享 `update` 链路正常、loader 钩子完好。**失效完全在 P-11 mod 内部。**

---

## 8. Timeline / 时间线

| Time / 时刻 | Event / 事件 |
|---|---|
| 19:20:55 | game start; bridge logs `mods/codex/p11_self_heal: loaded` / 游戏启动，bridge 报告已加载 |
| 19:20:55 → 20:10:29 | mod runs **2974 s (≈49.6 min)**, applies **22 self-heals** / 正常跑 2974 秒，自愈 22 次 |
| **20:10:29** | **`stopped: table overflow` — permanent stop / 永久停机** |
| 20:10 → 21:11:45 | game continues ≈**61 min** with the mod dead / 游戏继续约 61 分钟，mod 全程死亡 |

Log prefix is `GetTickCount64/1000`; the derived start time matches the loader log to the second.
日志前缀是 `GetTickCount64/1000`；换算出的启动时间与 loader 日志精确吻合。

---

## 9. Suggested fixes / 修复建议

| # | EN | 中文 |
|---|---|---|
| 1 | **`stopped` must not be permanent.** Clear it and re-arm on `avatar ready` / world change. | **`stopped` 不该是永久的**：在 `avatar ready` / 世界切换时清零并重新 arm。 |
| 2 | **The error branch should not hard-stop the mod.** Log once, then retry with backoff — a single bad frame should not kill the whole session. | **错误分支不要硬停机**：记一次日志 + 退避重试；单帧异常不该终结整个会话。 |
| 3 | **Validate every value read from memory before using it as a table key**, e.g. `local k = read(...); if type(k) ~= "number" or k < 0 or k > 0x100000 then reject end`. | **所有内存读值在当表键前都要校验**，例如 `if type(k)~="number" or k<0 or k>0x100000 then reject end`。 |
| 4 | **Do not latch when the scan count is not 1.** This session produced `count=2`. | **`count ~= 1` 时不要 latch**：本次出现了 `count=2`。 |
| 5 | **Give `stop()` a recoverable entry point** (a global function, or via the loader API) so users are not forced to restart the game. | **给 `stop()` 一个可恢复入口**（全局函数或走 loader API），别逼用户重启游戏。 |
| 6 | **Log which table / which value overflowed.** Right now the message is unactionable. | **日志里打印是哪个表、哪个值溢出**：现在这条消息无法定位。 |

---

## 10. Relation to the earlier v7 report / 与上一份 v7 报告的关系

**EN** — This is a **different** failure mode. v7's issue was the shot-gate / six-round model drifting
out of sync, with no `stopped:` line at all. v8 fails by catching a Lua runtime error and permanently
disabling itself. v7's desync fix does appear to have helped — v8 fired 22 clean activations this
session before this new failure.
**中文** —— 这是**另一个**失效模式。v7 的问题是开火门控/六发循环模型脱同步，日志里**没有** `stopped:` 行；
v8 这次是抓到 Lua 运行时错误后**永久自我关闭**。v7 那个脱同步问题看起来确实修好了 ——
本次会话在触发这个新问题之前干净地成功自愈了 22 次。

---

## 11. Disclosure: AI analysis / 披露：AI 分析生成

**EN** — `AI-ASSISTED ANALYSIS`. This report was produced with AI assistance. The log parsing, the
byte-level search of the deployed payload, the resource-hash reverse lookups and the write-up were
done by an AI assistant (DeepSeek) working from the reporter's own log files and copies of the
deployed mod files.

- The quoted log lines and byte offsets are raw evidence and can be re-verified directly.
- The causal interpretation in §5–§6 is **inference**, and is labelled as such where it appears.
- No game process was attached, and no process memory was read or written, during this analysis.
The payload was inspected by decoding the files on disk.
- §10 contains a correction of an earlier, weaker AI claim about the `eid` values.

**中文** —— `AI 辅助分析`。本报告由 AI 辅助生成：日志解析、已部署载荷的字节级检索、
资源哈希反查以及撰写，均由 AI 助手（DeepSeek）基于报告者本人的日志文件与已部署 mod 文件的副本完成。

- 文中引用的日志行与字节偏移属于**原始证据**，可直接复核。
- §5–§6 的因果解释属于**推断**，文中已逐处标注。
- 本次分析**全程未附加游戏进程、未读写进程内存**；载荷是通过解析磁盘文件得到的。
- §10 更正了 AI 早前一个较弱的判断（关于 `eid` 数值）。

The game needs to be fixed after the update because this mod has version checks and is incompatible after the update.

broken

Hey bro, could u update this mod?
The AW update made the mods not working.

yes please - I only usaed it once before the latest update

mod is broken atm