Taking apart cmb Files?

[danscan]

So does anyone know how to take these files apart and put them back together again. I was looking at the cmb file in a hex editor and it still doesn't make sence like its encrypted.

I want to create a program that will make various battles based on a shell program that would similate campaigns. If you guys have any idea how they are put together or if someone else figured out an automated battle maker besides the quick battle maker.

Just wasting your time

Dan

[Cameroon]

Sorry man, the files are encrypted. The biggest reason is to prevent cheating, though there may be others. The files that get sent during PBeMs (as well as normal save games) are map files.

There's been much clamoring in the past for a way to feed a text-based (or similar) map into CM in order to create the battle. For the same reasons you listed (campaigns). I don't believe any such thing made it to CMBB. Maybe the new engine will get us this feature.

[SgtSweatHog]

Hey Dan,

I went down this road a few months backs and here is what I got from MadMatt

"Sorry but you can not manually assemble the files like that. We use a proprietary system for the structure and will NEVER give out info on it.

Madmatt"

What happened was I was working on a custom map and I had erased it. I managed to have a .cmb file from when I played it once so I figured I might have been able to extract the map file from the .cmb code but that proved to be no easy task. I assumed the map code and movement code are stored seperate but by the hell if I could figure it out. I made another request to BTS to see if they could extract the file and they said it was beyond their capibilities because they were using a third party encryption tool.

As for another method of generating battles, I'm not too sure but I thought someone had developed such a tool a while back but I could be wrong.

[L.Tankersley]

I've just thought of a really kludgy way to do this ("Automatically" generate CM maps that is, not extract maps from data files):

Use a macro generator/user interface tester/stimulator thingy. I know these exist, at least in some environments, but my mind is coming up dry on names just now. The idea is to run a script that will synthesize the proper mouse movement and button clicks to automate the manual procedure of building a CM map in the built-in editor. You would probably need to design your own map data format to store the map in, which would probably mean building your own editor as well. But once that was done, you could customize your own editor to do whatever manipulations you want (cut-and-paste, mirror image, all kinds of stuff). One thing you couldn't do would be convert existing CM maps to your format (other than manually). But you might be able to come up with a "macro record" feature to watch your manual user interface activity while you build a map from scratch, and reconstruct the map data that way.

Aesthetically unsatisfying, but I think it would get the job done...

[Redwolf]

The remote control idea is pretty much unworkable on CM.

CM does not use any standard Windows controls, not even scrollbars. Even telling where you are on the map is a major coding effort. And this is effort that includes lots of parsing of purely graphics output. PhD theses at MIT are done about that, if you include the 3D view.

I have done a remote control thingy of that kind, with nothing but pixels, including OCR functionality to read what the thing was trying to tell me, and automated restart of said (sad) application because it would crash after a few hours of continuous hammering with events, resembling 100 years of normal user input or so (lameass programmers with no backbone...). It was a pretty cool hack, but then, I had someone paying for that nonsense by the hour, and I blew a lot of hours, including sportive things like doing the OCR in a bourne shell script.

Ah, and I had a legal paper signed by a lawyer that what I was ordered to do was actually legal in the country I did it in

[ July 29, 2002, 05:07 PM: Message edited by: redwolf ]

[Redwolf]

[double post]

[ July 29, 2002, 05:07 PM: Message edited by: redwolf ]

[L.Tankersley]

Hmmm, I'm not so sure. The Win32 SendInput function lets you synthesize a series of keystrokes, mouse moves and button presses and inject them into the input data stream. Raw input doesn't care about user interface graphics, it's just "move the mouse to (127, 388) and generate a left click." The bounds of the various "controls" can be found by brute force. (Hey, I said it was a kludge.)

Does CM run under Win2k? If so I'll try a small proof-of-concept tomorrow. I think it just may be a SMOP (small matter of programming).

[Sailor Malan]

Dont do it. I know it is a nice idea, and your motives are pure

However, if anyone ever managed to unscramble the save game, it will be like pandora's box - you'll never get the demon back in again. Can you imagine? No faith in PBEM, suspicions of 'things' changing, or god like 'lucky guesses'. I worry that someone might one day make a serious attempt at it.

If you really want a campaign system, talk to BTS about it, although I wouldn't hold your breath - they are good and receptive and all, but it isn't in their development route IIRC. Better to face it, CM is CM, not all things to all men...

Just my paranoid 2p worth.

[L.Tankersley]

I'm not talking about hacking the CM file format. I'm talking about inventing a NEW, open format capturing the same kind of data (elevation & terrain types) and building some kind of independent editor to manipulate this open format. The second part is building a program that will use the CM editor itself to build the CM map files from the open file format version.

Think of it this way: today, you could do something like this manually (if you were crazy, that is). You would get a big piece of graph paper and use one square of the paper to represent one tile of a CM map. Then you'd write in the elevation value in each square along with the terrain type. Once the design was finished, to build the CM map you would have to laboriously go square-by-square through your paper sheet and select the proper elevation and terrain type for each tile.

But computers are good at repetitive, laborious stuff like this. So what I propose is that, instead of you having to physically move the mouse around and click on each tile to set the elevation and terrain until your poor little fingers are worn away to nubs, a computer utility will synthesize the mouse and keyboard events that you would otherwise be generating with your mouse and keyboard. Once it's done, you hit save or whatever and you have a CM-compatible version of your map. All map editing is done in the open source file format, and CM itself is not modified at all (so BTS shouldn't have any problem with it).

[rune]

And you are doing that why? Since maps from one battle can be imported into another, including damage. Is that not what you are tryig to do?

Rune

[Treeburst155]

If you geniuses manage to do this, don't forget to write a cheat detector program of some sort to scan PBEM files for inconsistencies.

Treeburst155 out.

[Redwolf]

Originally posted by L.Tankersley:

Hmmm, I'm not so sure. The Win32 SendInput function lets you synthesize a series of keystrokes, mouse moves and button presses and inject them into the input data stream. Raw input doesn't care about user interface graphics, it's just "move the mouse to (127, 388) and generate a left click." The bounds of the various "controls" can be found by brute force. (Hey, I said it was a kludge.)

That's all fine, but reading the screen to actually come up with useful input at the right moment is difficult.

Note to others: this is only for remote-controlling the editor, kinda doing like a human does but faster. None of it has to do with reading PBEM files.

[L.Tankersley]

I was thinking more along the lines of, you set up the stimulator to execute your map script, press "GO" and then you have say 30 seconds to switch back into CM map editor mode. Then you just walk away for a while and when you come back your map is made. I wasn't planning on reading ANYTHING from the screen - all the "hot spots" can be hard-coded. (Probably will require different sets of hotspots for different screen resolutions, or the easy way out is to require the user to run the program in 800x600 or something similar).

[L.Tankersley]

Originally posted by rune:

And you are doing that why? Since maps from one battle can be imported into another, including damage. Is that not what you are tryig to do?

This is the first I've heard of this feature. So you can save the state of the map at the END of a CM:BB scenario and import it again at the start of another?

But no, that's not it, or not ALL of it. In a campaign setting, you might have an area of operations say 10km x 10km. As battles are fought, you want to play them on different subregions of this area. Right now, CM's map editor provides no facility to do this. You can't build a map big enough for the whole area, and you can't cut-and-paste, trim, or otherwise edit the map other than tile-by-tile. You can't even shift an existing map north-south or east-west to reuse portions of it while generating a new portion. THAT would be a very useful feature in some arenas.

[Caesar]

I am in the middle of a campaign manager type program and this is based around a remote control tool. I have built mine to use a kind of file defined record to control each action. This way different actions and resolutions just require a different file that contains the offsets etc. I have wrapped the whole lot in a series of COM objects (including the creation of the files) so that modification and upgrading is easier. The end result is that I can have my own map editor, storing the map in my own format and can then generate a battle. I am working on the map generator now. When I finish this part then anyone who is interested is welcome to it. As I say, I only want it to use as a campaign controller.

[Redwolf]

NOTE! To all the guys who heat up their Flaks without completely reading other people's postings:

This is only for generating terrain maps without hand-clicking them. Not about PBEM files or reading the native CM file format.

Thanks for your attention.

Originally posted by L.Tankersley:

I was thinking more along the lines of, you set up the stimulator to execute your map script, press "GO" and then you have say 30 seconds to switch back into CM map editor mode. Then you just walk away for a while and when you come back your map is made. I wasn't planning on reading ANYTHING from the screen - all the "hot spots" can be hard-coded.

Ah, sorry for misunderstanding you. So what you want to do is you have any kind of machine-readble description of the map and you want to turn that into a CMBO map.

That's certainly doable, the complications would come in once you have to dive into the 3D part of the editor, for example to set units or flags. Also, the easy part would be one-way only, not taking a CM map and turnign it into whatever else format you have as a map description you want to work with.

Speaking of it, flags are a bummer.

(Probably will require different sets of hotspots for different screen resolutions, or the easy way out is to require the user to run the program in 800x600 or something similar).

Just hardcode for 640x480, the remote stuff does not need high resolution and it only slows down.

I have (own and can give you) a framework to control one or more Windows boxes in their own Window on a X11 display, scripting it with a wrapper for xsendevent and capturing the screen for looking at the screen with normal X11 programs. The stuff I own is not the fancy one I did for my job and only has keyboard input, but mouse would be easy to add if you are familiar with Xlib programming

[WWB]

Not much of a programmer here, but am a map maker. This would be way cool, although I see a few issues:

1) I would set it for 800x600. CMBB requires that as a minimium.

2) What advantage would you have over a the included random map generator? It does have its issues, but does a very fine job overall except for cities, etc.

WWB

[L.Tankersley]

My Xlib programming experience is about 8-9 years old. Ironically enough, some of what I did involved event synthesis. But I think I'll just try the Win32 api tomorrow and see if it works.

I'm not shooting to be able to place flags or units or anything; I figure that can still be done manually. In the problem I'm trying to solve, I think the biggest time-sink by far is building (and rebuilding) the map.

WWB, we have a campaign that is played on CM maps based on historical 1:50k maps of the area. Imagine a battle that is played out on a 2km x 2km section of this map, lovingly crafted by some mapmaker or other. Now, later in the campaign (possibly the next campaign turn) a battle is fought about 1km west of the location of the first battle. Ideally you would want the eastern portion of the new battle map to be identical to the western portion of the old map. But to do that today, you have to manually recreate that half of the map, you can't just open the old map and modify it. [Well, there are one or two cases in which you can, depending on the way the CM map editor shifts stuff when you change the map size. But there's no generally applicable way to do it.]

This scheme would potentially also let you do things like opening a map (in the new format) and do things like cut-copy-paste, rotation, adjust all elevations up or down a certain amount, change woods to brush, all sorts of things that the CM editor doesn't support right now. If you wanted to take a stab at your own algorithm for automatic map creation, you could try that, too.

[WWB]

Originally posted by L.Tankersley:

My Xlib programming experience is about 8-9 years old. Ironically enough, some of what I did involved event synthesis. But I think I'll just try the Win32 api tomorrow and see if it works.

I'm not shooting to be able to place flags or units or anything; I figure that can still be done manually. In the problem I'm trying to solve, I think the biggest time-sink by far is building (and rebuilding) the map.

WWB, we have a campaign that is played on CM maps based on historical 1:50k maps of the area. Imagine a battle that is played out on a 2km x 2km section of this map, lovingly crafted by some mapmaker or other. Now, later in the campaign (possibly the next campaign turn) a battle is fought about 1km west of the location of the first battle. Ideally you would want the eastern portion of the new battle map to be identical to the western portion of the old map. But to do that today, you have to manually recreate that half of the map, you can't just open the old map and modify it. [Well, there are one or two cases in which you can, depending on the way the CM map editor shifts stuff when you change the map size. But there's no generally applicable way to do it.]

This scheme would potentially also let you do things like opening a map (in the new format) and do things like cut-copy-paste, rotation, adjust all elevations up or down a certain amount, change woods to brush, all sorts of things that the CM editor doesn't support right now. If you wanted to take a stab at your own algorithm for automatic map creation, you could try that, too.

Got ya there. I would kill for for cut and paste etc. I would not want to do an autogeneration algorithim. From what I gather the current one is about as good as is possible. While you all are at it, see if it is possible to change maps from battle to operations. That would also be a killer feature IMHO.

You can bump entire map elevations, but you cannot limit it to an area. Shifting maps has some issues with moving labels and flags, but it is pretty easy otherwise.

[Bjering]

Originally posted by redwolf:

That's all fine, but reading the screen to actually come up with useful input at the right moment is difficult.

I jump in here just to say you don't need to be well versed in computer vision to get this info, you hook into the gfx pipeline before it gets rendered on the screen. It is quite possible to develop your own wrapper graphics API objects, these would just pass on API calls to the real implementation while also letting you know what textures are put on what polygons etc. This is how all those wall-hack/auto-aim cheats that got me to stop playing FPS online works. CMBO is great at preventing that kind of cheating though, it don't leave FOW and LOS calculations to the graphics library.

The nice thing about the "macro" approach is that it does not in any way give the program access to more information then a human player.

Almost any modifications to the game experience could of course in itself be considered cheating by "purists". For instance as it a design decision that a complete OOB would go against the spirit of the game automating that task could be considered cheating? As I am on this rant, how about gridded terrain mods?

[Olle Petersson]

Don't you guys just miss the obvious?

If you do all the manual input of making a map and record it, what do you get?

You get a) a record/macro of map making, and a finished map.

If you run that macro, what do you get?

You get an exact copy of the map produced before!

I admitt that it's not that cool, but making a straight copy of a map file isn't that big a deal...

(Reminds me of this NZ guy who wanted to have cool beer in his shed. Any normal person would buy a cheap refrigerator, this guy did a more macho thing and built a jet engine powered beer cooler :cool: from scratch. Full story!)

Cheers

Olle

[Bjering]

Originally posted by Olle Petersson:

Don't you guys just miss the obvious?

What is discussed here isn't the simple record/playback of events you describe. Rather you record primitive actions like what needs to be done to raise the elevation on coordinate x:4 y:5 one step etc. These small steps can then be combined by a software that for instance could generate a CM map from a bigger map automatically. It could also do all sort of stuff to support 3rd party campaign tools etc, all this without opening CM to cheaters or take away development time from Battlefront. So no... its not just a horribly complex way of copying you map files.

[L.Tankersley]

Originally posted by wwb_99:

Got ya there. I would kill for for cut and paste etc. ... While you all are at it, see if it is possible to change maps from battle to operations. That would also be a killer feature IMHO.

Remember, this won't be able to do anything on preexisting CM maps. But if you build a map in the new editor, you could then "play it back" into the CM editor as either a battle or operation map.

You can bump entire map elevations, but you cannot limit it to an area. Shifting maps has some issues with moving labels and flags, but it is pretty easy otherwise.

One thing I just thought of that I think would be nice (based on my somewhat limited mapmaking experience) is better support for hills and crest lines. I'm thinking, you would set a "crest line elevation" in the editor and then just draw out a path. The editor would then assign the crest elevation to the tiles you drag through, and assign successively lower elevations to surrounding tiles until you met another terrain feature. Obviously you would want to do some manual cleanup after, but it would help address one of the things that I find quite tedious about mapmaking. If you want to start thinking about an editor wish list in the deep queue, assuming things go well I'll see what I can do. No promises.

One big downside of the scheme is you can't simply switch into the 3d view to see what your map looks like in CM. Although if the playback process turns out to be fast enough that might not be a big problem.

[Redwolf]

Originally posted by Bjering:

</font><blockquote>quote:</font><hr />Originally posted by redwolf:

That's all fine, but reading the screen to actually come up with useful input at the right moment is difficult.

I jump in here just to say you don't need to be well versed in computer vision to get this info, you hook into the gfx pipeline before it gets rendered on the screen. It is quite possible to develop your own wrapper graphics API objects, these would just pass on API calls to the real implementation while also letting you know what textures are put on what polygons etc. This is how all those wall-hack/auto-aim cheats that got me to stop playing FPS online works. CMBO is great at preventing that kind of cheating though, it don't leave FOW and LOS calculations to the graphics library.

</font>

[Bjering]

Originally posted by redwolf:

</font><blockquote>quote:</font><hr />Originally posted by Bjering:

</font><blockquote>quote:</font><hr />Originally posted by redwolf:

That's all fine, but reading the screen to actually come up with useful input at the right moment is difficult.

I jump in here just to say you don't need to be well versed in computer vision to get this info, you hook into the gfx pipeline before it gets rendered on the screen. It is quite possible to develop your own wrapper graphics API objects, these would just pass on API calls to the real implementation while also letting you know what textures are put on what polygons etc. This is how all those wall-hack/auto-aim cheats that got me to stop playing FPS online works. CMBO is great at preventing that kind of cheating though, it don't leave FOW and LOS calculations to the graphics library.

</font>