Download File

## DMZ Ragnarok 1.1.338 **The login timeouts, the dragon ball console flood, and the Super kit entitlement.** ### Dragon balls: one bad row stopped both open world shards from ever finishing their boot - **Every collected dragon ball made both open world shards spam the console several times a second.** The shared dragon ball record keeps a small marker for each ball that has been collected. When a shard started up and read that record, the very first collected marker threw an error, because the code asked an empty, read-only holder to forget an entry rather than creating a real one first. That aborted the whole startup step, and the next tick started it again from scratch: a full re-read of the shared record and a fresh pass over the world, many times a second, on the thread that runs the game. - **This was a large part of the lag and the login timeouts on the open world shards.** It was not just noise in the console: each retry re-read the network table and re-walked the world, competing with the players for the game thread. The SMP was unaffected because it has no twin, so those dragon balls are outside the scope it mirrors. - **The record is now created properly before an entry is forgotten**, which is what the running sync path always did; the startup path was the one place that did not. - **A startup that does fail now backs off instead of retrying every tick**, at one second, then two, four and so on up to a minute, and it logs the actual stack trace on the first few attempts. The error type raised here carries no message, so the console showed only its name and nothing about where it came from, which is why it could not be read off the log. ### Login: player data timed out - **All player data work across the whole network ran on a single thread**, so logins queued behind each other. Player data is now handled on six threads, with every operation for one player pinned to one of them, so two players log in at once while a single player's saves, loads and releases stay strictly in order. That ordering is the reason for pinning rather than a plain pool: two operations for one player running at once could let a save land after the release meant to follow it. - **The timeout was being counted from the moment a login was queued, not from when its work began**, so a login could be refused for taking too long when it had barely started. It is now armed as the work starts, which is what gives every player their full allowance. - **The retry loop no longer holds a thread while it waits.** A login waiting for another shard to release a player used to sleep on the shared thread, blocking everybody else's logins for the duration. It now schedules itself and occupies nothing while waiting. ### The Super kit could be claimed without the Super Dragon Balls - **Wishing on the Super Dragon Balls recorded nothing**, so the kit it is meant to unlock was gated on a permission that nothing ever granted. Because an unset permission of that kind reads as allowed, the kit was open to everybody instead of nobody. - **A Super Dragon Balls wish now records a permanent entitlement** and grants the kit permission across every shard. The kit itself is refused unless that entitlement is present, so summoning Super Shenron is the only way to it. The entitlement survives a character reset, and claiming the kit is written to the audit trail.