12-08-2001 01:35									#1
	Format of the AC map files. Enter the AD-FREE zone

I was recently enamoured with the idea of importing real-life (or even imagined, like built with Terragen or Wilbur type programs on a 256 8-bit grayscale bitmap) terrains into my favorite iteration of the civ genre.

The maputility program I found yesterday for download from this sight gives good results except for one glaring drawback (well, its a glaring drawback in my book anyway) -- the oceans are all shallow ocean shelf squares ... there is a distinct lack of depth in the resulting maps.

I've read else where in this neck of the forum that people's excuse for not putting much effort into learning the smac map file format is that it can be customized so much in the txt files ... but I've not arrived at my ideal of perfection thru that means and it doesn't solve the beautiful-import problems.

This thread is intended to be a hook in the pond to collect any and all knowledge about the smac map file format that is out there and share what I found last night if nobody knows it already and shares it before I check back here tomorrow.

Hopefully my 8 hr marathon of hacking the file format last night with my own feeble tools was an excercize in repetition and you all already have the file mapped out and can point me to my latest holy grail. If not, I intend this thread to be here to fix this gaping hole in the public body of knowledge I percieve thru this forum.

I'll be back after I get home from the office and consolidate my current knowledge into something presentable.

--purplemooseman

Last edited by purplemooseman on 12-08-2001 at 01:46

	17-08-2001 01:54									#2
	Got spare money?

I am suprised I didn't find any dead smelly fish here I left the hook dangling so long. Got involved in a game.
---------

Here is what I know --

Map data is organized in an arry that is (x/2) by y big where x and y are the map size in game coords. And you convert game coords to an index into the array by gamecoords.x = 2(array.x) + (array.y mod 2) and gamecoords.y = array.y. Also the mapdata is always stored at hex offset $ab3. Each tile is encoded by 44 bytes, the first two of which seem to be related to height. -- source for that is from the author of that 'ace utility' or whatever it is called that allows one to scatter resources on a small ac map. I'll grab his name when I can.

The rest I cobbled together. The footer comes after the mapdata and varies in length in direct relation to the size of the mapdata array or else you get errors when you open the map (but you can by-pass them if you load it from cheat mode, go figure.)

The first byte in a tile record encodes the type of terrain, and the second byte does encode the height/depth. I set the rest to zero and the only untoward thing that happens is that the first time you load the map the game draws the map flat, so I suppose some of the other bytes encode height data related to the sloping and relative height of each tile. But when you force the game to recalculate, it adds that just fine itself ...

The range for the first byte is roughly as follows :
0..96 : ocean, going from trench to coastal
96.. about 117: land, varies in moisture. Beyond this is a short bit of where the game draws the tiles black and displays 'no' for the terrain then it repeats the moisture levels.

The range for the second byte is roughly as follows:
0..60 : Deepest dept to shallowest depth
61 .. 130: lowest height to highest height.

In the header the X and the Y for the mapdata start at offset $f and are 32-bit words or longints. That x is the width of the map according to the game coords if I remember straight. Further down, at offset $23 is a longint or word that holds (X*Y) div 2.

The rest of the header seems to encode the names of landmarks, where the saved file lives and a few other things I cannot pin-point -- I just extracted a header from planet.mp and alter the bytes that I know change and use the rest and it seems to be ok.

I cobbled together a program to convert height data in a square 8-bit grayscale image of arbitrary size to a square map of arbitrary size and put it in a mp file, where less then 128 is ocean and above is land and the results look good enough for me. I've yet to figure out the intracies of pods, resources, rivers, rockyness and xenofungus.

Anybody here know anything?

-- purplemooseman

	25-03-2002 03:48									#3
	Re: Format of the AC map files. Lose 30 kilos (of popups)

quote: Originally posted by purplemooseman ...snip... The maputility program I found yesterday for download from this sight gives good results except for one glaring drawback (well, its a glaring drawback in my book anyway) -- the oceans are all shallow ocean shelf squares ... there is a distinct lack of depth in the resulting maps. ...snip... --purplemooseman

I, too, like the results from MapUtility, but it limits the output map size to no more than 128x128. For my SP games with a heavily edited alpha.txt, I use 256x208.
I am very familiar with SMAC's map editor, but need (well, want ) to get more exact with each space's elevation. Later I'll get involved with rainfall and such.
Is there any way to do this? I'm not afraid of long boring lists of numbers, so a hex editor or some such program would suit me fine. I'm hoping, though, someone will see this thread and point me in the direction of a coroner's view of the SMAC .mp format and how I can hard-code the beginning elevations.