Post tutorial Report RSS MechCommander 1 / Gold - Modding introduction

Hello dear MechCommanders, since all available MechCommander modding knowledge is nearly gone i decided to share my modding knowledge and security backups for MechCommanders. Modding MechCommander is a hard competition and can be a hard journey. But atleast it is fun seeing your results working ingame like a charme after you figured out how it works! May those words enlight some more game modders in the future!

Posted by on - Basic Client Side Coding

MechCommander 1 / Gold - Modding Banner


The State of

MechCommander 2020


Well when i came back to MechCommander 2016 i found the game in very bad conditions. Good thing was, that a modding community on NoGutsNoGalaxy focused (around 2013/14) on MechCommander for some time. Although the MechCommander extracted source code was released (partitionally complete) on GitHub - mostly done alone by IronArthur and Scrivener07 in 2012.

2017 i started to mod MechCommander Gold myself. The backbone for my modded content was a clean Original MechCommander Gold Expansion Version v1.8. Most things i needed to start modding MechCommander wayback i found on NoGutsNoGalaxy.net webpage - which got purged during 2019. Not only my modded MechCommander content & information - but although any other helpful modding information and software got lost that day. But it doesn't matter. I have backups of most of the lost content. When we talk about MechCommander the game itself - it's several standalone version builts - this already happened yet. I have reuploaded all the player's content here on ModDB - including all MechCommander game knowledge articles and mirrored this information to MechCommander Gold - Darkest Hours - new hoster: EveryThingBattleTech.com ! In the EveryThingBT-forums you have access to all valuable MechCommander Ingame information you might search for. Although here on ModDB you can find this information - plus ALL available MechCommander downloads & content for the game.

2020 now we have the best modding conditions for MechCommander, that ever existed. On the base of the modding knowledge above i have created another standalone for MechCommander called Darkest Hours (v4.2). MCG Darkest Hours combines all previous common standalone versions into one built containing two Extra Large XXL campaigns overriding the Original and Expansion campaigns from the game. Instead of 42 missions total from the original game - you can play 131 campaign missions total! In addition there are several optional updates & patches available for Darkest Hours and the biggest solo-mission map pack - that ever existed. The Fullversion of Darkest Hours exists since 2018 on modDb and was downloaded about five thousand times yet. The Original version on modDB since about 2015 has not much more downloads anymore. So the game itself evolved in an awesome way! The modding knowledge is still a problem - cause at the moment i think i'm one of the last guys on earth knowing how to do this stuff - beside some rare other persons who know more about this old gem.

When you are just a player - interested in playing retro RTS isometric 2.5D games - you can stop reading this article at that point. See the links above and find your gaming content! You have the ability to choose from several standalone versions containing multiple solo player campaigns for MechCommander and different modded game content. All this stuff was released for you and for both - poor and rich!

Have fun, that's an order!

MechCommander - Ingame footage


Modding MechCommander

Recovered Informations &

Modding Knowledge


Extraction of MC gamefiles

Oseparovic on GitHub: If you'd like to extract the files yourself, several utility scripts have been written by scrivener07 (which I shamelessly tweaked) for this purpose. The scripts are located in the extraction_tools directory. To extract a source file, simply place the source file in the extraction tools folder and run the corresponding script and enjoy! The necessary Cmunsta extraction tools are already in place so there's no need to do anything else.

MechCommander file extensions / types

You can do your own file type discovery. Many files still don't have an extension because their type cannot be determined. A lot of the research here was done with TrID Readable/Extractable formats marked in bold

  • FST - compression format extractable with cMunsta's extraction tools. Contains file names.
  • PAK - compression format extractable with cMunsta's extraction tools. Only has indices stored so filenames and extensions are hard to determine. Furthermore it seems it compresses into an indextable so when you extract you'll get compressed files along with a bunch of empty files where no file was compressed into.
  • TGA - image format viewable with free software like irfanview
  • SHP - some kind of spritemap/animation set. You can view/edit/create them with the IconsTool. Here's an example of what a SHP file looks like when opened with this program: Imgur.com
  • FIT - FIT data. All of these appear to be plaintext and contain descriptive variables like mech names and tonnage and rotations etc
  • FNT - Font file
  • ABI - advanced business language plaintext code file
  • INF - unknown but plain text
  • HSP - unknown
  • JMP - unknown
  • OUT - Mac OS X Mach-O 32bit Intel executable
  • HSP - Mac OS X Mach-O 32bit Intel executable
  • ABL - advanced business language plaintext code file macro script. Mission related. Opens with notepad.
  • ELV - MCEditor elevation files
  • DAT - binary file. Purpose unknown
  • BDG - binary file with building locations and offsets
  • GMM - binary file with movement and zone definitions
  • PRE - Preferences - plaintext files - binary file that has initial TileIDs to preload
  • OBJ - binary file with misc object locations and offsets
  • FLIC - unknown

Sample

palettex

Breakdown

Here's a list of the project structure and what you can find and where:

  • ART.FST - lots of GUI elements. Mostly focused on the main menu and the in game menus. Also contains all pilot thumbnails. These are all .tga files which are a just a type of image format. You can use sometimes like irfanview to open them
  • MISC.FST - lots of misc files. Notable is compbas.csv which contains what appears to be a full breakdown of components including stats hardpoint compatibility and ammo types
  • MISSION.FST - lots of information about the campaign. txt files contain some of the briefings. FIT files contain all kinds of info including default variants found in the campaign (AKA) inner sphere store. These are named PM1*****.FIT. files ending in 100,300,400 represent different variants of the same mech. Clan mechs start with PM2 and have many different variants representing various custom mechs you run into during the campaign. Also contains mechwarriors and vehicles with formats PMW and PV respectively.
  • SHAPES.FST - various shape data in the form of shp, and inf files
  • TERRAIN.FST - mission briefing images etc
  • data/art/ART.PAK - lots of gifs likely for animatable buttons? Also flic and undetermined files. Unlike an FST a PAK file doesn't contain filenames just indexes.
  • data/objects/OBJECT2.PAK - a huge amount of plaintext fit files including mech data. Directory of files can be found here: Docs.google.com
  • data/sprites/CURSORS.PAK - unknown files. Likely cursor animation and sprite assets but file types cannot be determined
  • data/sprites/SHAPES.PAK - unknown files. TrID came up with no file types. Lots of empty files too because it's a PAK
  • data/sprites/SPRITES.PAK - plaintext fit info for a ton of objects. It looks like this mostly for buildings like gates and perimiter alarms. If you sort by filesize the first 20 or so files are all massive fit files for the various mechs and all the animation sets including framerate and states

Mission / Map Breakdown

A Mission/Map on MCG has 2 parts:

Mission: Directory: DATA/Missions. it has 2 files, MCX0101.ABL & MCX0101.FIT, the first one it´s a macro script file that has all the "special" stuff that has to happen on that mission. The fit file it´s the text definition with all the variables of the Mission, and one of the variables it´s the name of the terrain file "st TerrainFileName = "MX0101"".

Map: Directory DATA/Terrain. The Map definition itself: Size, TerrainTiles, Building, enemies...... it has 10 files:

  • MX0101.fit : Text file Size of the map and what type of Tiles to look, regular or expansion
  • MX0101.elv : Binary file with the has the : height, TileID, OverlayID and some extra stuff
  • MX0101.bdg : Binary file with the buildings location and offsets.
  • MX0101.obj : Binary file with Misc Objects location and offsets.
  • MX0101.dat : Binary File. i don´t know what it is. It has some height value a some other value for each Tile
  • MX0101.tga Image file for briefings
  • MX0101.log.tga Image file small size
  • MX0101.pre: Binary file that has the Initial TileIDs to preload
  • MX0101.map : Text file
  • MX0101.gmm: Binary file. This it´s a really complex file. Mostly stuff for Movement on the map and Definition of Zones & "Doors". It´s similar of the one used on MC2 but it has differences Github.com

Problems & Issues before

any Modding Process

can be executed!


So wayback in 2016 this site left me back with mixed feelings. They released the extracted source but the files itself - i mean how they where left by it's creators - where a mess. While analyzing the source code you can obviously see how much pressure the development team might have had. On many places the code looks like typed in - in a rush. Many files have no clear naming conventions - or some files simply have any file names - they are just existing as the code that where typed in and compressed later. Refiguring out how this all works was a nightmare to do. But even here it was a big advantage using the knowledge and modding content i found above. Now i show you the tools which are used in my whole modding process - to make it easier or faster - or just doing things with automatic processes that would have last years when you would type in any code single handed on your own.

So here is a list showing...

...all things that are needed to start modding MechCommander:

... Modding Knowledge you must read before understanding:

*.FST & *.DPK
Notes

FST and DPK file format:
------------------------

Notes:
- Data in the FST is in compressed form (typically), the compression used is a Lempel-Ziv variant
(looks to me like an LZW). I'm not sure if this is in fact the case. Sort of redundant now as
the compressor and decompressor code ripped out of the game executable is working fine.
(see lzcompress_asm.c and lzdecomp_asm.c respectively).

- DPK files use the exact same format as FST file. In short, a DPK *is* an FST file.

- In a DPK file, I have yet to see any compressed data, while in the FST, it most definately is compressed, but it doesn't have to be.

- To store uncompressed data in a FST (or DPK), simply set the uncompressed and compressed size to the same values and copy the uncompressed data into the correct location in the FST/DPK.

- An FST (and hence also a DPK) file can be seen as a sort of virtual drive with a single directory in it.

- In both the FST and DPK files, the path to the file (relative to the game root directory) is stored with the filename in the TOC. This means that we could technically extract all files from the FST, delete the FST, and still run the missions as long as all the files extracted were in the correct locations. This seems to be born out from when we create DPK packages and extract the FST on another player's computer. I haven't tried this with the full mission campaign file though.

- The MCExtractor tool normally used to extract files from a DPK actually looks for a single *.FST file and a single .SOL file within the DPK. If this is not the case, MCExtractor will refuse to work with the DPK. Further, MCExtractor does not appear to be able to handle compression, this would then seem to be the reason why DPKs are never compressed. These factors should be kept in mind if attempting to create your own DPK creator using the information in this document.


Offset Size Description
------ ---- -------------------------------------
000000 DWORD Number of entries in the TOC

000004 262 * n TOC Entries start here (262 bytes per entry)

xxxx xxxx Data for the FST/DPK (Starts immediately after TOC)

TOC Entries (262 bytes):
000000 DWORD Offset into file where data is
000004 DWORD Size in bytes of the stored data
000008 DWORD Size in bytes of uncompressed data
00000C 250 bytes String (zero filled). File and path this entry represents.


Files in an FST and DPK file
----------------------------

For solo mission DPK files, there are only two files. First is the .SOL file for the misson, and then the actual FST file.

For solo missions, the following files are put in the FST file:

The names listed below assume the mission is called "name". Likely we only need one campaign file, the others are individualized for each map. The campaign name (likely) needs to be the named after the FST & SOL files, but the rest can be anything at all as they are referenced from within the campaign file. (order of files within the FST/DPK doesn't appear to be important).

data\missions\name_VAR.ABI
data\missions\name_STR.ABI
data\missions\name.TXT
data\missions\name_MP.ABI
data\missions\name_INIT.ABI
data\missions\name_LOP.ABI
data\missions\name.ABL
data\missions\campaignname.FIT
data\terrain\name.BDG
data\terrain\name.DAT
data\terrain\name.ELV
data\terrain\name.FIT
data\terrain\name.GMM
data\terrain\name.OBJ
data\terrain\name.PRE
data\terrain\name.TGA
data\terrain\name.LOG.TGA
data\missions\Warriors\nameParams.fit

When using the editor to create a DPK file (which also creates the FST for inclusion in the DPK), it internally renames all the names except for the file "campaignXX.fit" whose name remains intact and takes on the same name as the FST file itself. e.g. if you made a mission map called TEST, then the FST file the editor creates will be called TEST.FST, the SOL file will be called TEST.SOL and the campaignXX.fit file will be called campaignTEST.FIT. All the other files are referenced from within the campaignTEST.FIT file or one of the other files and so these files are automatically changed to some UUID number instead of TEST. This is why we get strange long filenames in the FSTs. But a simple test I made shows that the UUID names are not required whatsoever. if we simply packed all the needed loose files the editor creates for the mission (as noted above) into an FST file, and used the appropriate SOL file, the mission will run just fine.


This ive got from cMunstas notices of a simple txt file between all of his MCG Tools and Tutorials.

He also mentions the importance / role of dpk files in his campaign building guides.

MC file format notes by cMunsta:

CMunsta's MechCommander Gold File Format Notes (revision 2) [Make sure word wrap is on. You may need to also widen the window]

The following is just a bunch of notes I kept (and fixed up a bit) while working out how to get access to the MechCommander files. I was doing this mostly so I could try to figure out how to get a user made campaign going (the little info available that I could find is both woefully old and sketchy at best). While making these notes, I created a few simple tools so that I could gain access to these files. Therefore, the notes presented here should at least give enough information to recreate the tools (or preferably better ones) except in the case of the compressor and decompressor. For these routines, I went and found the appropriate code in the game executable itself and hacked-out versions of these routines so that I could use them in the creation of my tools (or any other tool for that matter). Anyway, for those that could use this type of information, I hope this is usefull for you. -CMunsta

Revision History:

  • Added info on PAK files
  • Added extra comments about DPK files. Rev 1 - Initial release

Format of PKK, SAV, MPK and SOL files:

  • The first DWORD is a "checksum" (not a very good one) created by simply summing all the bytes in the rest of the file (i.e. not including the checksum). I'm not sure if this is a unsigned or signed value, but probably won't matter for the uses the PKK, SAV, MPK and SOL files are up for. They don't have many files in them, and most are compressed as well.
  • PKK, SAV, MPK, and SOL files all use the same format, but do not contain the same files. The MPK seems to be the only one that does not have compressed files.
  • No filenames are stored in these files (MPK, SOL, SAV, PKK), but all of them are .FIT files except for the second entry in the MPK file as far as I can tell (still only text though).
  • In the case of the MPK file, the second entry seems to simply be text data, probably used in the description of the mission (haven't bothered to check).

Offset Size Description ------ ---- -----------------------------------------

  • 000000 DWORD Simplistic checksum (see notes above)
  • 000004 DWORD ("DataStartOffset") Offset where file data actually starts
  • 000008 DWORD * n Table of offsets to the data in the file.
  1. If an entry starts with 0x40 in its high byte (e.g. 0x40000969 or in a hex editor: 69 09 00 40) then the data is compressed and the real offset must be ANDed with 0xBFFFFFFF (~0x40000000). For our example, the real offset would then become 0x00000969.
  2. The number of entries in the offset table can be calculated like this: n = ("DataStartOffset" - 8) / 4
  • xxxx xx Start of data -If the file data is in compressed form, the first DWORD of the data is the uncompressed size of the file. the rest of the data can be run through the LZDecomp routine.

Format of PAK files:

  • PAK files are very similar to PKK files and the like, though not identical.
  • Instead of a checksum (as found in PKK files), there is an identifier DWORD at the start of the file.
  • Like PKK files, there are no filenames in these things
  • Files inside a PAK file do not appear to be compressed.
  • Some of the types of files found in PAK files include o Wave files (.WAV) o GIF and TGA images or Binary data files o Other PAK files (yes, you can embed a PAK file inside another PAK file).

------ Offset Size Description ------ ------ --------------------------------

  • 000000 DWORD "Identifier" 0xFEEDFACE (someone had a sense of humour) All PAK files have this ID
  • 000004 DWORD "DataStartOffset" The offset from the start of the file where data actually starts
  • 000008 DWORD*n Table of Contents
    n = (DataStartOffset-8) / 4

Each entry in the TOC is a single DWORD in size, which contains the offset where the data for this entry starts. A value of 0xE0 in the high byte of an entry indicates that the entry does not exist or has been deleted.

.TGA and .LOG.TGA files:

  • The .TGA and .LOG.TGA both use the same image, but are mapped to two different palettes for use in game. Since the .TGA color palette is different from the .LOG.TGA palette, they cannot be used interchangably. I suspect that the .TGA file (since it is used during gameplay) will have a different palette depending on the tileset (Cermak / PortArthur) used as well. I haven't tested this however.
  • The .LOG.TGA is used for the map in the briefing/deployment room while the .TGA is used for the map during gameplay. Note that my first attempt to edit the TGAs, though they got displayed, showed up inverted in game, even though they weren't inverted when I originally loaded them in photoshop (photoshop 5.5, used the default settings). So either photoshop isn't saving the .TGA the way the MCX likes them (possible), or I didn't click an appropriate option somewhere (even more likely). I simply inverted the image vertically before saving in photoshop and everything was good in game.

I hope this way more people are enlighted & may get attracted to give it a try. MechCommander is worth keeping it alive and caring for. And the result of your work may do more fun than the original - when you did right!

Read further Modding notes & information


Have fun Modding MechCommander, that's an order - regards RizZen!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: