worldMap

Files containing the minimap images / world map. One file is one tile of one zoom level of one cube face, and the set of tiles that belongs to a zone is listed in the worldDir.

Tiles are named {cubemapId}_{zoomLvl}_{entryId}_opt.worldMap, with the zoom level padded to two digits and the entry id to ten. When the .worldDir has isDataEmbedded set, the exact same bytes live inside the .worldDir instead of in a file of their own.

010 Editor Templates

• worldMap.bt - the container
• worldMap.payload.bt - run this on the inflated payload

Implementations

• Reader has been implemented in FauFau: WorldMap.cs - header and inflate only

Format

Little endian.

Header

Field	Type	Notes
magic	char[4]	GTNO
version	int32[3]
entryId	uint32	Third part of the file name
zoomLvl	uint32	Second part of the file name
corners	float[9]	Three vectors, the same ones the worldDir tile record carries
lodSubsectionId	uint32
unknown	uint8
dataLength	uint32	Payload length including the three header fields that follow
payloadExtractedSize	uint32	Inflated size
payloadCompressedSize	uint32	Deflated size, including the 2 byte zlib header
zlibHeader	byte[2]	zlib deflate header
payload	byte[]	payloadCompressedSize - 2 bytes of deflate stream

An older version of this page named entryId and zoomLvl "last" and "second" (after the parts of the file name they correspond to) and had the lodSubsectionId as a magic 25601. They are the same fields.

Inflated payload

The payload is a flat chunk stream that runs to the end of the buffer. Every chunk is:

Field	Type
id	uint32
length	uint32
data	byte[length]

Known ids:

Id	Contents
10	Texture data
11	Texture data
21	uint32 count then count 24 byte records of half floats and shorts. Looks like vertices
31	uint32 total, uint32 splitAt, one padding byte, then two runs of ushort v1, v2, v3 faces, the first splitAt / 3 long and the second (total - splitAt) / 3 long
41	uint32 count, one padding byte, then count / 2 records of ushort offset, ushort count, where each count is a number of triples of shorts
50	Not decoded
61	uint32 count then count 13 byte records, followed by uint32 n and n shorts

The chunk ids are stable across the files looked at, but the interpretation of 21, 31, 41 and 61 comes from reading the shapes in a hex editor rather than from the client, so treat the labels as a starting point. Nothing here has been rendered back to a picture yet, which is the obvious way to confirm them.

Chunks 10 and 11 are the actual map imagery, and are the interesting ones for anyone wanting to extract the world map.