BMPToArray was written by me to produce pixels for only one material. Theoretically, you could have a pixel to represent every colour and every material, which would end up being 256x256 MOPixels (unless you want to go through and manually find every material that's used). You could get a program to generate all 65536 pixels, but that would be a pretty massive file, and yeah, in the end it would be extremely laggy to not only detect but recreate said pixels. As well, how would the server determine whose data is giving the right representation of terrain?

average vote on each pixel. totally feasible

Surely you only need to get the material from the pixel and the colour from the bitmap based on the offset though? Each of the texture files is only like 128x128, so yes reading them would be a little bit of a ♥♥♥♥ you to your load time but you could get the offset pixel needed to keep the pattern going pretty easily and then apply that to what you receive as a block of material index. You wouldn't be able to do much with gibs and the like though, or bunker module concrete or metal :/

Yeah, that's mostly what I was thinking of. Dirt would be easy to do, but most of the map is bunker modules and gibs, so unless you removed that, it would be weird-looking. That and the ever-present lag problem, of course. Good point about the averaging, though, that actually might work.

another thing would be to do a scan of what isn't there that should be and subtract holes from that. gibs rarely block terrain, so the lack of corpses wouldn't matter much, and the amount of terrain you take away compared to the amount you'd need to put down is usually a lot less.

What if the other person doesn't have enough gibs on-screen, though?

They're quite unlikely to much that much up, surely, assuming we aren't playing with the old scrap metal materials It's better than the current clientside-only solution, in any case.