Hello Gametoast,

I've recently been working on a tool which creates .TER files, but there are two parts of the header which I'm not sure how to calculate (I've been using this as a reference: http://www.ande.pytalhost.eu/ter_file_format.htm):

1) Visible Grid coordinates. The best I can come up with is that the first short indicates a positive value, and the second indicates a negative. These two values are summed, giving one of the offsets. This seems ok for smaller maps, but when they get larger, such as 1024 x 1024, my theory doesn't work any more.
2) Total Grid Size. No matter how large I create a map, the value is always 262144 (0x40000). Square rooting gives 512, but again I'm not sure if this helps or not.

Two extra points. Firstly, the SWBF2 .TER files seem to have an extra byte with value 0x07 just before the list of textures. The other is that the int at offset 0x4 has a value of 22 instead of 21. I appreciate these are probably just because I'm working with SWBF2 and the reference I'm using is for SWBF, but I figured the more information I can provide the better my chances of you being able to help.

Thanks in advance.

Visible Grid Coordinates (4 signed shorts = 8 bytes):
Example from dagobah: -64, -64, 64, 64
Will result in a rendered terrain of 128x128, x=0,0,0. I'm not exactly sure about if the negative is to the left or right/top or bottom.

I imagine this could be something like -128, -64, 128, 64, too. Haven't really touched ZE in a long time though. Maybe it doesn't have functionality for that.

Total Grid Size (1 unsigned long = 4 bytes):
I can't speak for how ZE saves terrain size but reading 0x00B0 in stock .ter files gives me numbers from 256 to 512 (dag1, end1, geo1), without any square rooting.

The Extra Byte:
Fiodis and me stumbled upon that before and I actually updated the .ter information with it but forgot to upload the updated file. No idea what the byte does though.

22 instead of 21:
Riley worked with SWBF1 .ter files so I guess it's the current version of the .ter file format.

Not sure if it's any help, but here you go.

That was great, thanks. My mistake with the total grid size was I was working out the decimal value from the hex by using two zeroes where there should have been one. *D'oh*
I looked at your example of Dagobah, and I agree that 0xc0 is -64 and 0x40 is 64, but what are the 0xff and 0x0 bytes for? Are they axis indicators for ZE or what?

Thanks again, I really appreciate it.

EDIT:
Sorry, forgot something. How do you go about calculating the total grid size for an arbitrary (assuming power of two) terrain size?

0xc0FF is -64, 0xc0 would be 192 (and a char/byte, not a short).
The Visible Grid Coordinates are stored as shorts, which means they take up 2 bytes.
Are you using XVI32? If you are, clicking on a cell will make the Data Inspector start from that cell/byte to read the types it displays. So if you're on cell 2 and looking at the long field in the Data Inspector it will read cells 2,3,4,5 to get that long.

The Total Grid Size is the terrain size, isn't it? That's how many height/color/texture/etc^2 values are stored in the .ter file.

I've realised my mistake again, haha. I was working out the hex value as a short for 0xc0ff, assuming big endian ordering, whereas it should be 0xffc0. Sorry, I completely forgot about byte ordering.
Again, you're correct - it is just the length squared for total grid size. And thanks for the tip about the Data Inspector, I had no idea it existed!

Thanks for all the help, I'll mark this thread as solved.