Skip to content

CaYaDev Server Manager v0.3.0 — the map, off the main thread and staying put

Choose a tag to compare

@CaYatur CaYatur released this 05 Aug 22:50
· 3 commits to main since this release

Everything in this release is the map. Four separate reports, four separate causes.

Players sat next to where they actually were — on the web only

Not a placement bug. The public site and the map page round player positions for privacy and the desktop app does not, so the same player was drawn up to 32 blocks from the house they were standing in. That default was set when the public map was dots on an empty grid, where half a chunk out was invisible; against real terrain it is indistinguishable from a bug, which is how it was reported.

Exact positions are now the default. Rounding stays available for operators who want it, and the setting says what it costs instead of calling itself "Round to (blocks)".

If you already have a website configured, this does not reach you. round: 64 is saved in your site.json, and it is impossible to tell apart from a value somebody chose on purpose — so nothing was rewritten. Set Round to (blocks) to 0 in Website settings.

Loaded ground disappeared when you looked away

The client baked a 16x16 canvas per chunk. A viewport is up to 4096 chunks, so two screens of ground meant thousands of canvas objects — and it was that object overhead, not the pixels, that forced the cache to stay small enough to lose the ground behind you.

One canvas per region holds the same pixels in a thousandth of the objects.

before after
ground held before anything is dropped ~2 million blocks ~12.6 million blocks
drawImage calls per frame up to 4096 at most 9

That is also the answer to the web map getting slow once a lot was loaded: every redraw used to walk every held chunk and issue a draw call for each one. Areas you have loaded now stay for the session, and a region of nothing but unexplored ocean no longer takes a slot from ground you actually read.

The map read the world on the thread everything else uses

Parsing a region is about 1.4 seconds, and it was happening on the thread that answers the interface, serves the web panel and reads the server console. Slicing it up made that interruptible, not absent.

Regions are now parsed on worker threads — several at once, and the interface does not stop.

It waited until you looked before reading anything

Nothing was parsed until somebody opened the map, so the first look at a world was always the slow one: ~1.4 s a region against ~13 ms once cached, across four to nine regions.

MSMS now reads the world into its cache in the background, outward from spawn, when nothing else is waiting. It stands aside the moment you open the map, does nothing if you have turned the cache off, and stops when the cache is full rather than deleting the area around spawn to make room.

Together with v0.2.4 and v0.2.5

two releases ago now
one region, cold 14.0 s 1.4 s
four regions, as the map asks for them 38.3 s ~1.5 s, in parallel and off-thread
longest the interface can freeze 584 ms 0 ms — it is not on that thread
a region already cached 16 ms 13 ms

Your existing tile cache stays valid — the rendered output has not changed since v0.2.5.

Notes

  • Zoomed a long way out the map still draws only what it holds rather than requesting tens of thousands of chunks. It now holds a great deal more. Proper downsampled zoom levels remain a separate piece of work.
  • MSMS_NO_TILE_WORKERS=1 forces the old on-thread parsing if worker threads are a problem on your machine.

Verification. Every new check in this release was deliberately broken and watched to fail before being trusted — including the one that matters most here: a worker thread starts with an empty block-colour table, and a worker that parsed without it would have written wrong colours into your cache, where they would outlive the process. The worker refuses to parse without the table, its output is compared byte for byte against the main thread over every column of every chunk, and both halves fail the gate when removed. The packaged binary in this release was run through the smoke, and its worker threads were confirmed to start from inside the packaged archive rather than silently falling back.

Windows x64. The portable exe keeps all its data next to itself; the setup installs normally.