python mudlib using telnetlib3
Property parsing had 4 classes of bug, all producing wrong addresses
for object property data:
1. Off-by-one in shortname skip: addr += 2*len missed the length byte
itself, causing property table scan to start 1 byte too early.
Affected get_prop_addr_len and get_next_property.
2. V3 property number slices bf[4:0] extracted 4 bits not 5.
Property numbers 16-31 were read as 0-15.
3. V3 property size slices bf[7:5] extracted 2 bits not 3.
Properties larger than 4 bytes got wrong sizes.
4. V5 property number/size slices bf[5:0] extracted 5 bits not 6.
Also fixed get_property_length reading size from the wrong byte in
V5 two-byte headers (was reading first byte which has property
number, instead of second byte which has size).
Root cause for all slice bugs: BitField uses Python [start:stop)
semantics but code was written as [high:low] inclusive notation.
Same class of bug as the write_global fix in commit
|
||
|---|---|---|
| .claude | ||
| content | ||
| docs | ||
| scripts | ||
| src/mudlib | ||
| tests | ||
| worlds/earth | ||
| .dockerignore | ||
| .gitignore | ||
| compose.yml | ||
| demo_terrain.py | ||
| Dockerfile | ||
| DREAMBOOK.md | ||
| justfile | ||
| mud.tin | ||
| pyproject.toml | ||
| README.md | ||
| uv.lock | ||
mudlib
A telnet MUD engine. No client needed — just telnet and you're in.
Built on telnetlib3, Python 3.12+, managed with uv.
Quickstart
uv sync
just run
Then connect: telnet localhost 6789
Commands
just check # lint + typecheck + test
just run # start the server
just debug # start with debug logging
just render # generate world map HTML
What's in here
src/mudlib/— the engine (commands, world, combat, rendering, storage)tests/— pytest testsworlds/— world definitions (yaml/toml)docs/— internal knowledge baseDREAMBOOK.md— vision and wild ideas
How it works
The world is a toroidal 2D grid of terrain tiles, not discrete rooms. Players see a viewport centered on their position. Terrain types have mechanics — shallow water slows you, mountains block you, forests hide you.
Combat is timing-based with telegraphed moves and cooldown management, not turn-based.
The server runs a tick-based async game loop alongside the telnet server. SQLite handles persistence. Session mode stacks filter what reaches the player depending on context (exploring, fighting, composing, solving puzzles).