haven cache files ?

[mvgulik]

Anyone that can tell me a bit more about the haven cache files ?

Types found:
- map-grid - Think his might be the normal map files, although the minor variable size of the decode data seems a bit odd to me.
- map-gi - 25 bytes of data. Same number of gi-files vs grid-files suggest there related, not sure how though. ... Thinking color index, or something to that effect.(naa, don't make sense after some more thinking))
- map-zgrid - Zoomed-out map images for sure. ...
- map-seq - Also zlib'ed, but with some major size variation. Low file-case count.
- map-index - Only 1 found. ... ?

- allused - low file count (2 found) ... ?
-- (back to one, presuming some delayed cache clean-up resulting in 2 counts)

- res-file - This one I know, the general haven-res file, slightly modified that is.

[borka]

-allused seems to be a list of used res files in cache for the session when logging off

prolly the most valuable information would be where and how markers get stored

[mvgulik]

-allused seems to be a list of used res files in cache for the session when logging off

Compared the res-names in allused to the existing cached res-files names, so see if allused went to zero (ie:all cases found in both sets). it did not, so its seems at least not directly related to currently saved cached res-files.

Definitely will need to start making backups of allused so I can see how it changes over time/game-usage to get some additional ideas.
(Detail: Saved at closing the client (after user logoff with client)

prolly the most valuable information would be where and how markers get stored

They might not be stored (even temporarily) in the local game cache. ... will see if I can check if they are (or might). (Boshaw: map-index)

(spelling:2)
...

Please ignore the Shubla post below (if its still there)(and any additional shubla posts here), he is hereby not invited to contribute to this thread.

[boshaw]

This information can all be found in MapFile. Everything is redraw on the fly iirc. If you do change these formats in your own custom client consider updating HashDirCache.findbase() and storing all cache files locally in a different folder to prevent breaking other clients for yourself.

- map-grid - Think his might be the normal map files, although the minor variable size of the decode data seems a bit odd to me.

Grid contains the actual grid data in order to redraw the grid.

Code: Select all

u8		- version
i64		- grid id
i64 	- grid seed ? iirc
u8		- # of tilesets used to make this grid
for each tileset:
	string	- tileset res name
	u16		- tileset res version
	u8		- tileset res prio
u8[]	- tile data cmaps.x * cmaps.y size

Pretty sure that was the default format. Notice it's missing z info which is why default client maps don't have ridges

- map-gi - 25 bytes of data. Same number of gi-files vs grid-files suggest there related, not sure how though. ... Thinking color index, or something to that effect.(naa, don't make sense after some more thinking))

This is grid information. Specifically the grid id, the segment id the grid belongs to and the coordinate offset within that segment that the grid is. Along with a version number of (1) in default at least.

Code: Select all

u8 			- version [1]
i64 		- grid id
i64 		- seg id
i32, i32 	- offset coord

- map-zgrid - Zoomed-out map images for sure. ...

Same as map-grid but with additional information stored like what zoom-level this is for, and the offset.

- map-seq - Also zlib'ed, but with some major size variation. Low file-case count.

Holds all the information about a segment. Version, ID, # of grids, each Grid ID

Code: Select all

u8		- version
i64 	- seg id
i32 	- # of grids
for each grid:
	i64 - grid id

- map-index - Only 1 found. ... ?

Holds all known segment ids, all known marker data, and the version of the index. Changing the format of this will break other clients

Code: Select all

u8 		- version
i32 	- # of segs
for each seg:
	i64 - seg id
i32 	- # of markers
for each marker
	The marker save format... either a PMarker or SMarker iirc for default

PMarker

Code: Select all

u8              - version
i64             - seg id
i32, i32        - location offset
string          - marker name
u8              - marker type ('p' for PMarker)
u8,u8,u8,u8     - RGBA color of marker

SMarker

Code: Select all

u8              - version
i64             - seg id
i32, i32        - location offset
string          - marker name
u8              - marker type ('s' for SMarker)
i64             - Object ID (Global ID, not randomized)
string          - marker res name
u16             - marker res version

[Astarisk]

Hah, Boshaw just beat my post by a minute. I can verify what he says there x]. Especially breaking the client bit as I almost lost all my markers messing with it (forgot to make a copy of the file) and had to make a python utility to restore it all.

[borka]

ty boshaw (again and again) and Astarisk

[mvgulik]

Thank you Boshaw & Astarisk for feedback.

Have been eyeballing the client source, but translating it in my case is a bit of a slow process. Provided info should definitely help me out with that.

No custom client plans are involved at this end. Just got a bit side tracked into the cached & Map files, while using it to harvest more res-names.

[mvgulik]

Just a little update/correction.

For map-grid

Code: Select all

i64    - grid seed ? iirc

is actually an epoch timecode(UTC, in milliseconds) (byteorder='little'). (equals related cache-file creation/modified local-time, ergo: probably directly (re)generated map-part)

For map-zgrid this timecode don't matches related cache-file dates and is probably telling when that map-part was last updated (assuming: on the server). Ergo: potential last map-changing activity.

Current code ref points: (code+point might shift+change over time) - map-grid - map-zgrid