Continuing the discussion from Hax 4 $$:
it’s not difficult just long and annoying
if you’re looking to edit an existing tileset, then you take the “tile config” data and copy all of it. Not sure how you’d know it’s all of it, but them’s the breaks (I guess), probably look for the start of the next block. Then, decompress LZ77. Data is as follows, in this order (assuming a 256-tile set):
256 * 8 graphics bytes for each tile [see below]
256 * 1 terrain byte for each tile
From the “object set” specified, each pair of graphics bytes corresponds to the top left, top right, bottom left and bottom right (in that order) 8x8 tiles that make up the overall 16x16 tile. If you’re editing an existing tileset, don’t bother with this (unless you’re doing fancy graphics hacking), I believe I have the exact bit layout in my notes somewhere (it’s standard TSA map data).
The last 256 bytes are all the terrain values. If you’d want to just change the terrain “acts-like” properties (i think i called it “terrain type” internally), you’d just edit these, then recompress the entire mess and reinsert.
What makes this so annoying for custom sets is pretty much just sitting there by hand and listing out what all of the terrain values are, lol. You can use grit to generate the graphics data for you.
I have the rudimentary notes here, but please be aware that as of right now (2016-06-28) they are somewhat wrong (specifically, at the time I didn’t know about the graphics data). I’ll see if I can’t find the chat log in which @BwdYeti and I discussed this