Map Format

[nine2]

I want to know that as well. bet it is for custom behavior like lava

[Krapougnak]

What else do you know about maps?

Well some tidbits but don't rise your hopes I'm not a great map maker like some of you. But ask if I can answer I will.

terrain type layer

Im at the office so I can't launch the editor now. Do you mean the window with a lot of different terrain types and colors you can use to paint the map in (like out of memory: Dirt05, Dirt07, Rocky01 etc... ) ?
If it is the case those are very useful, it is the finishing touch of a map.

If you launch and play an official map you will see that the units when they walk make little "dirt puffs" and that these "dirt puffs" change depending on the terrain type. That is what terrain type are for. OK it is an pain in the a** to paint (roughly) all the map again but it is well worth it otherwise the map looks dull, lifeless and artificial when units walk on it.

I hope I understood correctly your "terrain type" question, without the editor it is difficult to guess, if I remember I'll check back home.

[Lionhardt]

Aha! Thank you.


Edit: After trying out quite some of the brushes I have observed 80 % of them do not show an effect ingame. Why is that? Or am I missing something? I for example can't find a single evergreen themed dust /mud brush that works ingame.

[Krapougnak]

Yeah I have noticed that too and frankly I don't know, some word from the experts is needed here.

If memory serves though there should be at least one brush for the evergreen layer as in Seton's Clutch and other evergreen official maps the units do make "dirt puffs".

[Lionhardt]

Looks like it's the one with code 82 for sandy areas on setons.

[Krapougnak]

On Setons if memory serves the brush used allows the release of small green particles besides dirt for each unit step, so it is suited for evergreen settings and there is a mix of 2 terrain type brushes (one green and one brown ?)used in this map.

Maybe if we take a look at every official map we could see if a lot of terrain type brushes were used or not. Maybe only 20% were in the end meant to be used after all ?

[Duck_42]

Regarding v60 of the SCMAP file format...

As best I can tell, the only difference is the addition of a section that places textures in the sky background (i.e. stars, planets, moons, etc) and a section that adds some sort of atmosphere texture. You can only see these textures with free cam on and the camera positioned correctly. I think they were put there to make 3D screenshots and vids look better (i.e. POV and close up shots looking out across the map).

The location of that data in the SCMAP file is what causes problems for Hazard's code. It's right after the TerrainType data and before the prop information. Hazard's map loading code has no logic for handling that, and it tries to load it as prop information (which fails and crashes). Unfortunately, the length of this data section appears to be variable, so a minimal understanding of it will be required to properly handle it (or use it, if someone feels like figuring out how).

Sample from SCMP_037...

v60.png (57.81 KiB) Viewed 2605 times

From the top, my best guess so far is...
(00 00 00 43): A float value set to half the map width (or maybe the height).
(00 00 00 00): A spacer I guess. Not really sure. Seems to always be four zero bytes though.
(00 00 00 43): A float value set to half the map height (or maybe the width).

-The meaning of the next 52 bytes is anyone's guess.
-Next, we've got a null terminated string containing the path to the texture.
-That's followed by another null terminated string containing the path to another texture.
-Next, we've got a 32 bit integer containing the number of items in the subsequent data structure (whatever that is). There are 14 in this example. The items in the structure appear to be 40 bytes in length. I suspect these are some sort of values for positioning parts of the texture in the sky.
-So, 14x40=560 bytes, so moving 560 bytes down, we find some sort of header for the cloud texture (cirrus).
It seems to always start with (00 00 00 66), and it's 19 bytes long.
-The header is followed by another null terminated string containing the path to the cloud texture.
-That is followed by 89 bytes of something, and ends with 00 00 00 00 (which isn't shown in the picture).

After that, it's back to props (if there are any in the map).

[Duck_42]

...it appears there are also four additional bytes in between the wave ramps and the layers (stratum). The "Unknown5" block (as HazardX referred to it) is 28 bytes in v60 instead of 24 bytes as in v56.

[nine2]

Very nice ... you are 1 month ahead of me as always. I was thinking it might be useful to compare vanilla setons with FA setons - similar maps but upgraded version ... but perhaps not.

Obviously it would be nice to know what all that stuff is but if we can't, perhaps we could just scan to the .dss string, then the 00 00 00 00, and just skip that stuff and read the rest of the file. I don't mind if we can't programatically change whatever this new stuff is ... but I still want to be able to read the other parts of v60 maps (writing not so important either)

Or, we could do the same method temporarily to load a bunch of v60 maps now, extract the unknown bit and have the extractions all sitting next to each other - might be easier to reverse engineer that way.

Have you tried taking a v60 map, changing the version in a hex editor, removing the weird bit and seeing if it runs in the game/map editor/hazard code? That would confirm that you have found all of the differences

[Duck_42]

Have you tried taking a v60 map, changing the version in a hex editor, removing the weird bit and seeing if it runs in the game/map editor/hazard code? That would confirm that you have found all of the differences

Nope. However, I did try taking one of my v56 maps and making into a v60. It works fine in FA, but the mini map still doesn't show the cartographic view. There must be something other than map version affecting that. That makes me wonder if it's possible to get the cartographic view working in v56. I'm going to experiment some more and see what I can figure out.