MCG TILES extracted addon - Modding MechCommander

Visit EveryThingBattleTech forums for more modding information.

More information about MechCommander *.PAK files and how to extract them:

TheGameEngine.Org

Mechcommander Gold open PAK files

Mechcommander data files are compressed using a customized PAK format. This tutorial is based off of CMunsta’s command line extraction tool. Some PAK files have been fully extracted in the MCGExtracted GitHub project. You can read more about the project in the Mechcommander Gold extracted post.

1. Download the PAK file extraction tool pakextract.exe
   Download link 1 <– Cmunsta
   Download link 2 <– GitHub mirror
2. Place your pakextract.exe file into the directory containing the .PAK file.
3. Open up cmd and navigate to the directory containing the .PAK and pakextract.exe
4. Extract the file at the index in the .PAK file you would like to. Data in .PAK files is ordered by indices which you’ll have to look up if you want to extract a specific file. For example if you’d like to extract the data for the Atlas mech, into a file called atlas.txt you would execute:
   pakextract.exe OBJECT2.PAK 51 atlas.txt

Once again, if you need the fully extracted source for a specific PAK file, some PAK files have been fully extracted in the MCGExtracted GitHub project. There are also scripts you can run yourself located in the extraction_tools directory of the MCGExtracted project. For more information about extracting specific PAK files see the sections below.

OBJECT2.PAK
There are 1189 indices in the OBJECT2.PAK file. Mech data is located at the indices listed in this spreadsheet.

IronArthur on NGNG forums 2015:

Hi,

I´ trying to figure the Mechcommander Tile format and i´m hitting a wall decoding the file.

Damn Fasa/Microprose for using so many obscure file formats. With some file analyzers (Trid) the tiles gets identified as Luceva Bitmap CEL (Adobe animator file: flc/flic/cel), that makes sense becasuse they were used for a lot of games in the 90s. But it´s not. the format it´s totally different.

So right now i´m decoding the file structure by hand and imagination.

Tiles on Tiles.pak, tiles90.pak, gtiles.pak and gtiles90.pak use the same file structure. Except some files on the bottom of each pak file that start with DNAH/1212239428/44 4h 41 48 that have some totally different structure.

Code:

Offset Size Description
------ ---- -------------------------------------
0 4/DWORD i thing it´s a hash or some type format, they are relatively consecutive from each file to the next
4 DWORD * n Table of offsets to the data in the file. n = (("FirstOffset" - 8) / 4) + 1
** *** data

Example, Tiles.PAK> 4014:

Code:

Name Value start size
DWORD hash 1866465335 0h 4h
int lstOfsset[0] 268 4h 4h
int lstOfsset[1] 271 8h 4h
....
int lstOfsset[64] 4252 104h 4h
int lstOfsset[65] 4255 108h 4h //End of file
Data:
ubyte offset[3] 10Ch(268) 3h
+ubyte [0] 55 10Ch 1h
+ubyte [1] 43 10Dh 1h
+ubyte [2] 43 10Eh 1h

It´s very strange or a wrong deduction from my side becasuse the data doesn´t make any sense. each data entry gets more bytes until the middle of the file then start decreasing number of bytes.

I don´t know if some is able to help me. Probably Cmunsta but i doubt he has time to look into it.

Any ideas

cMunsta:

If I remember correctly, there is some code for decoding the tiles in the MechCommander2 source (at least I think that was what it was for).

From what I remember of the code, each scanline of the tile image starts with a pixel offset to say where the data starts followed by the data itself.

As to the increasing/decreasing data density, with the above in mind, this actually makes sense when you consider that the tiles are really just 2D diamond shaped bitmaps.

IronArthur:

I´ll try to look into MC2 code, i know that lzdecomp comes from there. I even tried to decompile MCG exe but it´s pure c++ code with just data copy to "obscure" memory structs.

My problem it´s i don´t know if it´s rgb data or what.

Map structure i think i will not be very complicated to extract, except for the *.dat file.

Edit: wow there is a lot of reused code from MCG to MC2.... i found the code for Palette/FadeTables and i´ve been trying to decode that for weeks

Even with code it´s hard to know how they decode some formats. On MC2 seems that terrain textures are TGA file and i´m pretty sure on MCG they aren´t.

They even have some render file inherited from MCG (SHP and shapes) but it´s ASM code and i think it´s a little different format than MCG-SHP but i´ll look into that too.

I´m going to download the original Microsoft Source Code because right now i´m looking into Omnitech code and it´s modified, and i want the original.

Digging Time!!

Code:

long VFX_nTile_draw (PANE* pane, void *tile, LONG hotX, LONG hotY, MemoryPtr fadeTable)
{
//-----------------------------------------
// Format of tile shape data is NEW!!
// Byte -- Hot Spot X.
// Byte -- Hot Spot Y.
// Byte -- NumScanLines. (height)
// Byte -- NumScanColumns. (width)
// Word -- One word for each scanline indicating offset into main data for that scanline.
// Bytes -- Main Shape data. Each scanline pointed to by above table.
// The main difference between .fsx and .gsx files are in the main data.
// Because there is no end scanline marker, the length of each Blt can be
// determined and a MUCH faster rep movsd can be used to Blt the data.
//------------------------------------------------------

//-------------------------------------------------------

Not bad for the first day of digging. But most of the VFX_Code are done in ASM

Not bad for quick code:

Tiles.PAK 4700,4040,4863

Well i have basic Map drawing ready:

Achiless Map

I´ve more troubles that it should because i was thinking that the maps were staggered isometric, but they are a typical diamond shaped isometric but the game only shows a rectangle.

Btw my Tile code i posted before was wrong and i wasn´t working with non-isometric tiles. Thats the reason the second tile i´ve posted was an hexagon. I wasn´t using the offset of each scanline

Rigth now the tiles for Achilles map look like this:

I can´t draw the overlay tiles because i don´t have a clue of the format so right now i´ve passed to Map Object placing. 95% done cause i´ve a little displacement of the exact spot for each building/trees/turrets.

Status summary of Mapdata format

Code:

Achilles.bdg
Achilles.dat
Achilles.elv -> Map TileIDs with elevation, overlay tiles
Achilles.fit -> general description
Achilles.gmm
Achilles.log.tga->image for briefing
Achilles.obj -> pak file for each block of the map with ObjectId
Achilles.pre -> TileIdList but they are not every tile of the map. Don´t know what for
Achilles.tga -> Minimap

Another update. I figured out what´s the format for overlay files, it´s strange because they could have used the same format from tile files (it´s very similar format), but they use a mix from shape files and Tile files. MC2 sources comments it´s been very helpfull again.

Right now i draw map tiles, overlay tiles with bugs (some are drawed very strange), and objects with positioning bugs.

Pink Color should be transparent/shadow

Time for screenshots:

Positioning bugs for objects, it´s a square

The bridge it´s an overlay, something it´s wrong in my drawing code

I´ve finished with the overlays. it´s been hard, i have even read asm/Assembly code from MC2 to understand how they draw them because they have some compresion on gaps between color "strings" on each line.
They use some arbitrary number to know if they have to jump or read colors ( >128 : number of colors to read, <128 : number of jumps to make).

Rigth know i draw everything for the map: tiles & overlays & objects/buildings:

As you can see i still have some bug for the objects location, but i know what it is. Its a mix between the pivot of the objects (i have to bound them with some values for in the descriptor fit file) and displacement for the elevation of the terrain. Not very difficult.

Heffay:

This is really impressive work, and I wish I had stopped by sooner! I've been making my own C# program to read Cryengine files and can commiserate on the challenges of sorting out closed source info.

Github.com

It's actually working really well for MWO files, and a bunch of Star Citizen ones. Just trying to tweak up a few more features still.

The best online resource for asking these kinds of questions is the Xentax forum. There is free registration this summer, so if you haven't gone over there yet to make an account, now is the time.

Xentax.com

The forums are full of people looking at doing exactly what you've been doing for a number of games.

As far as recreating Mechcommander... I'm interested. I've cut my teeth on C# programming now and probably could help out.

IronArthur:

@cmunsta : if you didn´t post your originals file format guides on your web i wouldn´t even start looking to MCG code. Also you helped me a lot with your advices with palettes and tile/overlay info. So thanks for everything.

About the question of recreating MCG just as it is or makin an expanded version... i don´t know what´s better but i must say MCG code is one of the most over-complicated and messy codes/systems i´ve ever seen. I vote for recreating MCG but outside the limitations of original formats and tranform them to modern ones like fit->xml, pak/shp->spritesheets or whatever.

@Heffay: thanks for the info on that forum. I´ve already registered just in case, later i´m going to dig to see if i find something interesting. At first i had the same idea of making and extractor of mcg files and maybe just convert them to usable formats, but i didn´t think to convert every resource at once was worth it and thats the reason i made the code on Unity to use on demand even with Unity limitations. Also packing sprites on Atlas/Spritesheets outside Unity it´s not easily done.

Right now, i´m cleaning the code (just the code for map placing, not vehicles/mech code) to push and alpha code to a github so people can start looking at it.

Also i was trying to port LZDecompression code from ASM code to C# so we can use x64 versions (LZDecomp it´s a DLL for x86 only), but right now my head it´s hurting after porting 2-4 versions of LZW decompression algorithm from C/java/ASM and not even one approaches the results from the current DLL. I´ve tried to follow MC2 LZDecomp ASM code that has comments and clean code, and even it seems to do a similar code like the one from Rosettacode.org , but i can´t understand how initializes the dictionary and how gets the code for the initial file with variable bits.

BTW, i´ve a problem to publish my code, i´ve taken/inspired/stolen my fit file reading code from MCGTools. @SeanLang I think you programmed that??

cMunsta:

Something to worry about is that we may not be able to use any graphics/audio assets from the orginal MCG or MC2 since they are copyrighted by Microsoft/FASA interactive. Well at least not without permission but that is a whole different kettle of fish.

@IronArthur
Unless you are trying to read out the data directly from the original compressed files, there is little reason to bother with your own LZW compression. If making your own file formats, why not use an existing C# compression library? SharpCompress (Sharpcompress.codeplex.com) can do RAR, 7Zip, Zip, Tar, GZip and BZip2.

KeeKat:

As the saying goes "It's easier to ask forgiveness than it is to get permission"

It may be quicker just to recreate the UI and use the original assets but it will have that zoomed way out look to it on modern monitors so it doesn't seem worth it. The better option would be to recreate all the sprites in the game using mwo assets. The rendering is pretty straight forward set up the camera/lights and render script, its the extracting from mwo and animating that will take time.

The most important thing is to decide on the scope of the project, people are not going to sign a blank cheque for their time.

I took some mwo assets and made some tiles for a quick test:

I.imgur.com
I.imgur.com

IronArthur:

In fact i need to use it for reading original compressed files. Right now i read it with the DLL (ASM) from MC2 source code or the MCGTools dll one. They are both limited to x86 version. Unity has some options for compressing the processed files so that's not a problem.

About legality of the possible project, we have pass experiences in favor (Daggerfall for Unity, MWO liberal use of the MechModels) and against of using original resources (MWLivingLegends).

And keep in mind that a new BT/MC game is incoming from Harebrained, even it's a Turn-based one.

BTW, I'm going to be tottally against doing new sprites for any game, except for a single non-turnable object. Doing a 3D object and using them just like that or exporting them to a spritesheet, it's waay more easier on the long run.

HeffaY:

Making sprite sheets from the MWO models and Blender is pretty easy. Just render the animation as a series of .png files, load them into GIMP and you're basically done.

I'm trying to make it even easier by being able to export the MWO animation files with my new program, but that's probably 3 months out. Once I get that done though... every MWO mech and animation will be easily converted to a sprite sheet in a day or two.

If I can't get the animation files to work, they can still be manually created the old fashioned way. A lot more work; have to do all the animations for each mech by hand. Not fun, but basically chump work that can be taught fairly easily.

I.imgur.com

That's the twerking urbie I made. I had the animation already rendered out as a series of png files. I just loaded them up into GIMP with a sprite sheet plug-in, and it did this in no time at all.

I know Unity handles sprite sheets pretty well. If I can get the animations out of the .caf files, every mech and animation can be converted over fairly quickly. Sprite sheets don't have to be big renders either. I think these are 500x500, but for game assets depending on how much you want to zoom in, you can probably get away with even smaller ones.

IronArthur:

With 3d you gain modularity and customisation. If you model a new Gauss in 3d you just glue it to the mech, in sprite you have to position for each orientation, on each arm, on each frame animation. On an isometric game for complex characters the works is huge.

I could show you the amount of sprites that were created for MCG for each mech, and I still thinking poor artist..

(c) by RizZen 2020 - Security modding information backup