I've been spending a lot of time decoding the various chunks found in TS1 houses that have yet to be documented. I'll use this thread for my sharing my efforts with decoding these chunks, and keep my SimAntics thread strictly about SimAntics. Currently I'm able to load objm, objt, arry and simi chunks, but there are still a lot of unknown fields, especially in the objm and simi chunks. Here's a rundown of what I know so far: objm - This is a field encoded chunk contains a table mapping object IDs from Arry's to fields found in objt. There's also a lot of data after the table which I'm not able to read yet. I'm guessing it contains the object states. It's also compressed using the same field encoding found in other chunks, but I'm not sure what sizes are used here. objt - Contains a list of object GUIDs, object names, and 5 other fields I don't know the purpose of yet. This chunk contains unique objects found on the lot, so no object will ever appear twice here. arry - As the name would suggest, these are arrays, containing info about where on the lot objects, floors, pools, etc. are stored. There seems to be at least 4 different formats used to store the data, and some chunks define more than just a single array. I've only been able to decode Arry(3) (objects) and Arry(9) (pools) so far. simi - This is by far the least researched chunk I have, but I have found that this chunk defines the lot size and the lot price. It seems like it also contains info about the in-game time, and when the chunk was modified. Unlike objm, this chunk is more or less of a fixed size. Putting all of these together, I'm currently able to make a map like this of Sim Lane 2: (The map is mirrored, but that's just because of the way I've been storing the decoded data internally.) Coordinates in the Arry chunks are always encoded using 2 bytes, in one of the following formats: 1000 yyyy yyxx xxxx (Arry(9)) 100y yyyy yxxx xxxf (Arry(3)) Where x and y are the xy coordinates, and f is a flag with an unknown purpose. The first entry in the arry defines the absolute position, and all entries afterwards are relative to this initial position. As you can see, each axis is encoded using only 6 bits, which places the hard limit of 64x64 tiles lots. Interestingly, I haven't encountered any position defined in 16th tile-widths yet. My guess is that it's only found in the SimAntics data for objects. When a relative x coordinate overflows 6 bits, the y coordinate will be incremented by 1. You'll often see entries using 63,0 as their position, which is their way of incrementing y by 1 and x by 0. The x coordinate is incremented by 1 for every entry in the arry, which explains why they use this overflow trick when they only want to increment the y coordinate. Arry(9) has been a massive headache for me, because I couldn't for the life of me figure out when an array ended. Unlike Arry(3) which only contains one big array, Arry(9) may contain multiple arrays, but it uses a very strange end of array marker. Basically, an array in Arry(9) is terminated when the current position resolves to 0,0. Given that Arrys use relative positions most of the time, this means that the end of array marker is never the same twice. Confusing, huh? Anyway, I'll eventually share some code here for parsing these chunks as I finish decoding them.