Here is Claude AI’s explanation after we provided it with the logs:
**The bug**
In `celevator/controller.lua`, the function that queues elevator events works with the `celevator.controller.equeue` table (the event queue). It initializes it, inserts events into it, and serializes it into storage — everything is consistent.
Except for one line. When the queue exceeds 5 elements, the mod wants to log a warning, and to determine the queue length it uses:
```lua
local queuelen = #celevator.controller.queue[hash]
```
instead of:
```lua
celevator.controller.equeue[hash]
```
**Why it crashes**
`celevator.controller.queue` does not exist. In Lua, accessing a nonexistent field in a table returns `nil` — it does not immediately cause an error. The error occurs right after that: `nil[hash]` triggers `attempt to index field 'queue' (a nil value)`.
**Why only now?**
This code path is conditional. As long as an elevator processes its events faster than they arrive, the queue stays below 5 items and the faulty line is never executed. The mod could run for months without any issues.
In your case, the elevator at `(-2244,-95,2440)` fell behind once — enough to cross the threshold. The server crashed, `Restart=on-failure` restarted it, and the queue was still there, causing it to crash again. A loop. And each cycle added more unprocessed events, which is why there were 54 pending events when the issue was fixed.
**The irony**
The line that crashes is diagnostic code. It only exists to warn: *“Careful, this elevator is falling behind.”* Instead of warning, it killed the server — and completely hid the real symptom, which was simply that one elevator was a little slow.
**What you saw**
A server that shut itself down, refused to stay stopped, and seemed inconsistent. It all came down to one missing letter.
This was indeed a bug in previous versions, but this was already fixed in the 2026-04-11 release. Are you still seeing issues with the current version?
Hello.
We found a significant bug in the mod.
Here is Claude AI’s explanation after we provided it with the logs:
Our admin therefore ran:
This was indeed a bug in previous versions, but this was already fixed in the 2026-04-11 release. Are you still seeing issues with the current version?