Analyzing and understanding map files...HELP NEEDED

[Rokko]

OK guys, this is something for the pros

I'm envisioning programming a tool to make life easier for map makers, considering how relatively cumbersome the editor itself is.

The idea is along the lines of the following:

The user paints a rectangle (in the editor) in Map A using one of standard overlays we already like Allied Objective #1 or Axis Setup Zone #1 or whatever (doesn't really matter I believe).

He then paints an equally sized rectangle in Map B.

The tool would then read all the data associated with tiles marked in A, including every information (tile type, elevation fix, brush, houses, fences, roads, flavour objects) and copy said data over and overwrite the information in the marked area in B.

So essentially it would be a copy and paste tool. Now I am definately not a seasoned programmer, but I am not completely clueless either and what I am planning sounds relatively easy (in theory).

Now before any of this gets started, I'll have to understand how map information is saved and where and that already is much less clear than I hoped it would be.

Main biggest problem at the moment is, that each time you save a map, the code changes (when watched in Hex Editor), wether you actually changed something or not. I could identify a file header which stays always the same (could contain information like date, time, etc, not sure).

I made a test map, 4000x4000m, completely flat with only (short) gras tiles and I could kinda identify the pattern for defining the 16,000,000 individual gras tiles which was like

01 AC 06 B

in Hex and probably stands for Gras, Elevation 20 or something like that.

But sometimes when I simply saved the exact same file and the pattern changed into

60 35 80 D

but mid-file, so the first part of block I assume defines the terrain tiles still had the first pattern and later changed into the second pattern, without anything in the editor itself except the file name. Also between the assumed header block and the assumed terrain tile block there was another block that never remained the same, also no patterns recognizable there.

Note I am not experienced in using Hex Editors so this really confuses the hell out of me. And that way I can't really analyze how changes in the editor affect changes in the code.

So now I kinda hope there is someone here with some programming skills how might be able to explain this to me.

Maybe I have also woken some interest and someone would like to support me in this.

[Mad Mike]

I already had a deeper look into this and believe it can not be done easily.

As you've already found out, the way the data is saved into a "btt" file changes every time.

My best guess is that the data is encrypted (with a fast and easy algorithm) which still makes it very hard to read the files. Why this has been done to the "normal" files and not just the "ema" files for H2H games, I can not really say.

Maybe you can get someone from BFC to comment on this.

Overall I would say that most likely you would be wasting your time without being able to achieve even the simple goal you described.

[Rokko]

Well bummer

But it's definately a plausible explaination for why the files change everytime you save. It's also kinda understandable considering Battlefront's policy of not letting anyone change any game files except for sounds and textures, although I don't think it is necessary here or at least I don't really see what needs to be protected in the .btt files.

I guess if I really wanted to get into this I could find out what the .exe does when you hit the "Save" button in the editor but I'm not gonna go down that road.

Still sad though, because I think it wouldn't take long at all to implement with only very few problems potentially coming up.

I think BF should do anything they can to make the lives of mapmakers's easier, though, considering how user-made maps and scenarios are really what keeps Combat Mission games alive.

[Pak40]

I think it would be a whole lot simpler to lobby BF for an inbuilt copy/paste tool. We already have lobbied for improvements to the editor and at least 3 of them were added to the 2.0 upgrade (map overlay, AI plan copy/paste, and a two-click wall & road placement).

My biggest issue with maps at the moment is the inability of battle damage to carry over during a campaign. With the Market Garden module coming up, campaign designers will have to make their own battle damage. I'm not sure how well received this is going to be with all of the static battlegrounds in the MG campaign.

[StoneAge]

Copy and paste would be the best thing out +1. Makes extending a map out past the border so much easier.

[The Steppenwulf]

I've already looked at this also having thought about the possibilities of running a MP operational game - such a concept hinges entirely on being able to process input and output information in an open format such as XML. This would then allow a campaign manager to build a map from tiles on the fly (as you are thinking) but more importantly dovetail the position/progress of units in CM on an external OP map and visa versa. It doesn't take a CM wargamer to realise where the potential for this would be going....

I did actually manage to grapple with and change some of the encrypted bytes in the files which the game sucessfully read, but I melted my brain in the process of trying to crack the algorithm. Unfortunately the first 160 bytes are the only consistent ones in the files and they represent only the scenario/campaign overview data. As Mad Mike says the rest of the information is encypted and it is the same across all the file types. I suggest the reason is simply for compression for ease of transfer, to prevent cheating which could potentially ruin MP play, or possibly even because the BF devs are quite aware (from CMx1 days) that file access is the route to developing an OP campaign and they covered their base on this with the CM2 version.

[JonS]

I suggest the reason is simply ... to prevent cheating which could potentially ruin MP play

I suspect this is a big part of it. And it's a very important consideration, I think.

As an aside, just before Mad Mike released hsi scenario organiser and campaign-un-packer, I was fiddling about with using single-scenario "campaigns" to do something-or-other which standalone campaigns can't do. I forget exactly what, although it had something to do with FOW. I might have been trying to do what used to in CMx1 be called "tournament bake" scenarios so that players couldn't go into the scenario and have a snoop around.

Anyway, I thought using campaigns would be the solution, then Mike released his tool. Which was a bit disappointing. Don't get me wrong - his tool is a nifty piece of work, and kinda useful (even if not really keeping in the spirit of campaigns ) but it did scupper what I was working on

[Mad Mike]

I suspect this is a big part of it. And it's a very important consideration, I think.

As an aside, just before Mad Mike released hsi scenario organiser and campaign-un-packer, I was fiddling about with using single-scenario "campaigns" to do something-or-other which standalone campaigns can't do. I forget exactly what, although it had something to do with FOW. I might have been trying to do what used to in CMx1 be called "tournament bake" scenarios so that players couldn't go into the scenario and have a snoop around.

Anyway, I thought using campaigns would be the solution, then Mike released his tool. Which was a bit disappointing. Don't get me wrong - his tool is a nifty piece of work, and kinda useful (even if not really keeping in the spirit of campaigns ) but it did scupper what I was working on

Jon, sorry to have ruined your work.

To be honest, I'm not quite sure how useful my tool is, since I wouldn't use it to cheat my way around a difficult scenario in a campaign (you could almost achieve the same result without the tool by just saving and cease-firing to see what awaits you anyway).

But it was quite a nice challenge which kept me occupied for a couple of hours (to figure out how it works, the programming took longer, but that's not really the fun part once you know how things work - then it becomes just work).