Heatmap off by default
It is an analysis overlay, not what a map is for. A red block over the one
player online is the first thing anyone sees, on all three surfaces. Off
everywhere; the toggle stays.
Jump to a player
The player list under the map is already there and inert. With more than one
person online, finding them means panning around and reading the coordinate
readout. Clicking a name should centre the view on that player — on all three
surfaces, since they now share an engine.
Structures on the map
Villages, dungeons, fortresses, temples, mineshafts. Every chunk's NBT already
carries structures.starts, and the tile parser already has that NBT in hand —
so this is nearly free at parse time and needs no second pass over the world.
- Filterable by type, and off by default: it is a spoiler for the
players and clutter for everyone else.
- The admin surfaces may switch it on themselves. The public map may not:
publishing where every village and dungeon is turns the site into a treasure
map of a private world, so it takes an operator setting, off by default —
the same shape as publishing the terrain.
Entities (mobs, item frames) live in a separate entities/ region set and are a
bigger read; they are not in this issue.
How much of the world to load
An operator asked whether the map should show only what the server has already
generated, or keep pulling more in as you pan.
Worth being exact, because the honest answer shapes the setting: MSMS never
generates world chunks. It reads region files the server has already written.
Generating terrain to fill a map view would grow the world on disk and stall the
server doing it — a map should not be able to do that to a world.
What it can do is decide how far ahead of the viewport to read:
- Only what is on screen (default) — least work, a small wait when panning.
- Load ahead — also read a ring of chunks around the viewport, so panning is
already drawn. More parsing, same world.
Pregenerating terrain deliberately is a real and separate feature.
Heatmap off by default
It is an analysis overlay, not what a map is for. A red block over the one
player online is the first thing anyone sees, on all three surfaces. Off
everywhere; the toggle stays.
Jump to a player
The player list under the map is already there and inert. With more than one
person online, finding them means panning around and reading the coordinate
readout. Clicking a name should centre the view on that player — on all three
surfaces, since they now share an engine.
Structures on the map
Villages, dungeons, fortresses, temples, mineshafts. Every chunk's NBT already
carries
structures.starts, and the tile parser already has that NBT in hand —so this is nearly free at parse time and needs no second pass over the world.
players and clutter for everyone else.
publishing where every village and dungeon is turns the site into a treasure
map of a private world, so it takes an operator setting, off by default —
the same shape as publishing the terrain.
Entities (mobs, item frames) live in a separate
entities/region set and are abigger read; they are not in this issue.
How much of the world to load
An operator asked whether the map should show only what the server has already
generated, or keep pulling more in as you pan.
Worth being exact, because the honest answer shapes the setting: MSMS never
generates world chunks. It reads region files the server has already written.
Generating terrain to fill a map view would grow the world on disk and stall the
server doing it — a map should not be able to do that to a world.
What it can do is decide how far ahead of the viewport to read:
already drawn. More parsing, same world.
Pregenerating terrain deliberately is a real and separate feature.