How Map (waypoints, world map and climate) was built

Raw game files read

No game asset feeds the waypoints or the world map: they come from the files you load (waypoint JSON / the translocator mod's Nf3tData.json, and the client's Maps/<id>.db)
worldgen/blockpatches/*.json (climate bands matched against the result)
worldgen/treengenproperties.json (tree/shrub climate bands)
blocktypes/plant/fruittreebranch.json (fruit tree climate bands)
No game asset feeds the generator itself: it is a port of the game's C# climate code (see below)

Processing

The map page is three parts on one plane. Waypoints (waypoints.js, waypointsPage.js, waypointMap.js) come only from what you give it: waypoints you add, a JSON export, or the translocator-locator mod's Nf3tData.json (the route search is Dijkstra over straight-line distances, with translocator links costing nothing). Nothing is stored on the server; the list lives in your browser's local storage. The explored world map (worldMap.js, worldMapPage.js) reads the game client's Maps/<savegame id>.db with sql.js (SQLite compiled to WebAssembly, loaded only when you choose a file). Its mappiece table has one row per 32×32-pixel tile, positioned by (tileZ << 27) | tileX, whose blob is a protobuf message with one ABGR varint per pixel; the tiles are drawn at one pixel per block (sampled and averaged when the explored area is larger than 4096 blocks), and laid behind the waypoints in absolute world coordinates. It is a port of the vintage-story-launcher's map preview and has been tested against tiles built by hand to that layout, not against a real save file. The climate part is described below.

This tool is different from the other pages: the climate numbers are not read from a game data file, because the game computes them in C# at world-generation time. apps/vs-wiki/site/assets/climate.js is a port of that code, written against the game's own source (vsessentialsmod Systems/WorldGen/Standard/ChunkGen/0.GenMaps/ and vsapi Common/Climate.cs, read from local reference clones that are not part of the build). The only game data it uses is the set of wild-patch, tree and fruit-tree climate bands the rest of the wiki already extracted, to say what grows at the computed climate.

What is ported

The seeded random generator (NoiseBase): a 64-bit linear congruential generator, reseeded for every 512-block noise cell. It needs 64-bit wraparound integer maths, done with BigInt.
The realistic climate (NoiseClimateRealistic): a north–south triangle-wave temperature gradient plus per-cell random variation in temperature, rainfall and geologic activity. The seed picks a position in the starting-climate range, which shifts the gradient so the middle of the map sits at the spawn temperature.
The cell blend (MapLayerClimate): the four surrounding cells combined with a smoothstep, including the 14-map-pixel offset between the block grid and the noise grid that comes from how regions are generated.
The altitude formulas (Climate.cs): temperature falls 1 stored unit per 1.5 blocks above sea level (y=110), and the rainfall height adjustment.
C# float rounding (Math.fround) and (int) truncation, where the original uses them.

What is not ported

The results are approximate.

The map wobble. After the stage above, the game warps the whole climate map with a six-octave simplex noise (MapLayerPerlinWobble), displacing it by up to about 29 map pixels (roughly 900 blocks). This is the main source of error for any given block.
Text seeds. The game converts a text seed to its integer seed inside VintagestoryLib.dll, which is closed source, so only numeric seeds are accepted. The open source contains two candidate string hashes, but neither is confirmed for world seeds.
Everything else that shapes what you actually see: forest and shrub maps, landforms and terrain height, and seasons. Plant and tree matching uses temperature and rainfall at the chosen height only, not fertility, forest density or terrain.
The X/Z inputs are blocks from the world center, assumed to match the in-game coordinate display.

How it was checked

No running game was available, so there is no comparison against real worlds. Instead test/climate.test.ts checks the port against an independent re-implementation of the same C# arithmetic (64-bit wraparound, signed shifts, float rounding) on several seeds, and checks properties such as the spawn temperature landing in the chosen starting-climate range. This catches arithmetic mistakes, not a misreading of the C#. Comparing a few readouts from a real save would be the best further validation.