I'm not quite sure what you mean by "reverse endian compared to windows endian", but the game uses Little Endian without exception. As long as the endianness is known (which it is), there's no way we wouldn't be able to recognize the vertex data. The problem is, as said before, that the vertex data might be encoded (I point to the Quake md2 format again, where this is the case but people have long since figured out how to decode the vertex data there).And I just realized... these files are backwards! The BMP data was in reverse endian compared to a windows endian format, which means even if we found the vertex data, we might not be able to recognize it because it would be out of order!
The extraction of the bmp data is so easy because I figured out the header of the color table/the actual image data (and the hackstract creator before me). The process isn't really applicable to other data types (unless we figure out the header of the mesh data (wherever THAT might be)).This means if we could apply the process to extract the BMP data to the entire file, we may just get something that makes sense.
I remind you that the "bmp" files inside of the archive have nothing to do with bmp at all (bmp use RGB format instead of RGBA; the header is completely different, etc). If anything, it's closer to png.I've got a bad feeling that these .TMP's are partially compressed... which would mean the vertex data may not even be accessible at all until we pull out the .MAX's...
That means two things: The "max" doesn't have to be the raw max file of 3DS Max and that even if it were, the header is very likely to be different, so we'd have to figure it out (and if we did, there'd be no need for exporting).
Hell, I appreciate that you're even bothering with this stuff. You'll get better with time.I'm probably about as novice as it gets at reading hex info directly... (aside from not being able at all...)