Forged Alliance Forever

Re: Map Format

2014-06-14T10:13:50+02:00

I still want to read v60 so that we can analyze the maps that come with FA, but agree it's not worth it probably

Statistics: Posted by nine2 — 14 Jun 2014, 10:13

Re: Map Format

2014-06-14T10:12:26+02:00

Running your console app from the zip you provided, I get this on my 64 bit machine:
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'SCMAP Reader Writer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
at Minimap_Fix_Tool.Program.Main(String[] args)

Statistics: Posted by nine2 — 14 Jun 2014, 10:12

Re: Map Format

2014-06-14T07:24:32+02:00

By the way partytime, I've already pushed an updated version of the map generator (with the mini map color handling) up to Bitbucket. I've separated the map load/save code so it builds into a standalone DLL (which can be used for other projects).

I see no reason to even bother with the v60 map format. We have no map editors that can read them, and in my opinion, the aesthetic improvements in v60 do not justify the effort that would be required.

Statistics: Posted by Duck_42 — 14 Jun 2014, 07:24

Re: Map Format

2014-06-14T07:17:06+02:00

The first one (usually 18 00 00 00).

Statistics: Posted by Duck_42 — 14 Jun 2014, 07:17

Re: Map Format

2014-06-14T06:12:38+02:00

Well done. This time you only beat me by a few minutes ... just came here to post what i've worked out what all the colours are and how we can write a console app.

Which field was the contour interval ?

Statistics: Posted by nine2 — 14 Jun 2014, 06:12

Re: Map Format

2014-06-14T06:07:30+02:00

Minimap Fix
http://www.faforever.com/forums/viewtopic.php?uid=773&f=53&t=7618&start=0

Statistics: Posted by Duck_42 — 14 Jun 2014, 06:07

Re: Map Format

2014-06-14T03:15:19+02:00

This is what I need to get strategic preview working in game!

Statistics: Posted by nine2 — 14 Jun 2014, 03:15

Re: Map Format

2014-06-13T21:44:43+02:00

I found the problem with the cartographic view in v56. The "Unknown5" byte array is, in fact, an array of color data for the mini map. The map editor sets that array to all zeroes, which is why the mini map is black.

In v60 they changed the way the data is stored, so I can't just copy and paste that block from a v60 map. So, I'm now trying to figure out how the colors are stored and which colors are displayed where on the minimap. More to follow...

Statistics: Posted by Duck_42 — 13 Jun 2014, 21:44

Re: Map Format

2014-06-13T17:48:17+02:00

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.

Statistics: Posted by Duck_42 — 13 Jun 2014, 17:48

Re: Map Format

2014-06-13T06:42:20+02:00

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

Statistics: Posted by nine2 — 13 Jun 2014, 06:42

Re: Map Format

2014-06-13T06:39:01+02:00

...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.

Statistics: Posted by Duck_42 — 13 Jun 2014, 06:39

Re: Map Format

2014-06-13T06:06:29+02:00

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

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).

Statistics: Posted by Duck_42 — 13 Jun 2014, 06:06

Re: Map Format

2014-03-10T16:27:40+02:00

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 ?

Statistics: Posted by Krapougnak — 10 Mar 2014, 16:27

Re: Map Format

2014-03-10T15:15:03+02:00

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

Statistics: Posted by Lionhardt — 10 Mar 2014, 15:15

Re: Map Format

2014-03-10T14:42:10+02:00

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".

Statistics: Posted by Krapougnak — 10 Mar 2014, 14:42