KErr — Kick / soft-error codes
KErr is what the server sends when it rejects an action or signals a state-machine miss. The error code rides on the ER field of the KErr packet.
Important: most
KErrcodes are warnings, not real kicks. The TCP connection survives; the server just refused the most recent action. Treating them as fatal will break tutorial automation and routine flows. Seraph logs them and reacts only on the codes documented below.
Code table
ER | Meaning | Seraph reaction |
|---|---|---|
0 | Generic error / forced disconnect | Logged; status preserved. |
1 | Spam / packet rate limit | Logged; back off your send cadence. |
3 | Floating (player position desync) | Logged; ignored — server re-syncs on next mP. |
4 | Player died | Auto-respawn (Rez) fires immediately. Without this the server waits for Rez indefinitely and resets the TCP socket. |
6 | Warp target rejected | The Rez / portal target was rate-limited or pointed at the same tile. Don't retry the exact same coordinate. |
7 | Speed hack / movement-rate violation | Movement packets faster than ~250ms/tile flagged. Slow your walk cadence. |
8 | Broken pickaxe / no valid tool | A last_pickaxe_broken_signal timestamp is stamped on session state so auto-mine can detect and either repair (kit available) or stop cleanly. Without this, the loop chains ER=8 packets that look identical to anti-cheat triggers. |
15 | Duplicate LeaveWorld | Logged; ignored. Common during tutorial completion (TState=7 + LW) when both client and server emit the leave-world transition. |
| other | Unknown | Logged as "KErr ER=N (unknown)". Status preserved — server hasn't escalated yet. |
Why most codes are warnings
KErr codes are server-side state-machine signals — the client treats them as opaque integers and forwards them to analytics. Confirmed via PW client disassembly: there's no client-side mapping that escalates a KErr to a kick.
The server does drop the TCP connection after some KErrs, but only if the bad behaviour continues. A single ER=4 is harmless if you respond with Rez within ~10 seconds. Ten ER=4s in a row without Rez will get the socket reset.
Reading KErr from Lua
The runtime auto-handles ER=4 and ER=8 (respawn / pickaxe-broken signal). For other codes — or if you want to react to ER=7 by slowing your script's send rate — subscribe to p:KErr:
client:on("p:KErr", function(msg)
local er = msg.ER or -1
if er == 7 then
print("[script] speed-hack warning — backing off")
task.wait(1.0)
elseif er == 1 then
print("[script] rate limited — pausing")
task.wait(0.5)
end
end)
When KErr does become fatal
Three patterns where KErr chains lead to actual disconnect:
ER=4with noRezreply — server gives up after ~10 s.- Repeated
ER=8from a broken pickaxe — auto-mine without the broken-signal check chains these forever; the server eventually resets. - Any
KErrstorm>= 10per second — the rate of error packets itself becomes a kick trigger.
The auto-handlers in Seraph are sized to keep all three out of the danger zone.