Welcome to Open Carnage

A resource for Halo Custom Edition and MCC modding, with unique means of rewarding content creation and support. Have a wander to see why we're worth the time! - EST. 2012

Search the Community: Showing results for tags 'H1 Tutorial'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


    • Site Bulletins
    • Member Introductions
    • Halo MCC: General
    • Halo MCC: Development
    • Halo CE: General
    • Halo CE: Development
    • Chimera
    • SAPP: General
    • SAPP: Scripts
    • SAPP: Script Requests
    • Halo PC: General
    • Halo PC: Development
    • General Gaming
    • Tech Chatter
    • Off-Topic


There are no results to display.

Outstanding Mapper

Found 3 results

  1. edited for completeness Preface in order to see the contents of the file, you're going to have to decompress the file. I used CEAFlate for this: I believe the file is compressed using the zlib library. The endianess of the file is little. The s3dpak format .S3dpak is an archive style format, similar to a zip, or rar file; however, it is specialized for use in the saber3d engine. The header The header consists of only 4 bytes, and It tells us how many child files are in the parent. After that we have (What I call) the glossary which contains all the the files, and where to find them. Similar to what we’re used to in a book. The glossary The glossary consists of entry points for data. Each entry consists of: 4 bytes: offset 4 bytes: size 4 bytes: string length String (string length bytes): name 4 bytes: type of data stored 8 bytes: pad The offset is simply the pointer to the beginning of the data segment in the file. In combination With the size variable, we can know where the data is located, and how much data to look for. The string length is important, because the strings are NOT null terminate. This means we read the string length, and then directly after we read that many bytes to get the name of the data segment. This alone is enough to extract the data from the file; although, in order to put new data in we need to tell the engine how to interpret the data. This is done with “type”. The type is an enumeration linking a number, to a data type. The values are as follows: 0 : "Scene Data", 1 : "Data", 2 : "Single Player Lines", 3 : "Shader (.fx, .psh, .vsh)", 5 : "Textures Info", 8 : "Sound Data", 10 : "Memory", 11 : "Skull data?", 12 : "Template", 14 : "String List", 16 : "Game Logic (.lg)", 17 : "Breakable glass", 18 : "effects (.gfx)", 22 : "(.grs)", 25 : "rain", 26 : "(.cdt)", 27 : "(.sm)", 29 : "(.vis)" Some numbers aren’t used in CEA. Looking through all the s3dpaks provided with CEA these are the only ones seen throughout. Currently the definitions of these files are unknown to me. I will work towards figuring them out, but for now it goes beyond the scope of this specification.
  2. I honestly don't feel this needs to be made; however, for sake of completeness: The fmeta format: The fmeta file format simply links dependent files together. It is as follows: 4 bytes : child count 4 byte : padding string (256 bytes) : name 8 bytes : padding 4 bytes : type (-1 for s3dpak, 1 for .map) 4 bytes : decompressed size (if file is a .map) the decompressed size is -1 (ffff ffff) if it's a s3dpak I guess I should also point out it's a fixed size file coming in at a whopping 18 kb
  3. OK, so I'm running into some stress dealing with importing ipak/imeta into SuP. I decided to take a break, and write this up. IPAK/IMETA First of all. Why are they included together? ipak, and imeta are BASICALLY the same thing, the only difference is the ipak contains the actual texture data. Preface To start, just like with s3dpak, you need to decompress the data with ceaflate. The file format is little endian, and this data is close to complete; however, not 100% The Header The header for is very simple, just 8 bytes. 4 bytes : Child count 4 bytes : padding The Imeta The data present in the Imeta is in both the ipak, and the imeta. I'm assuming the reason for this is so the game doesn't have to load every texture in the ipak, and instead can grab only what it needs. This will make more sense in a min. This makes modding the file a little more difficult, as you need to edit two different files. Think of the ipak as a giant gallery of paintings, and the imeta as the directory. You have a directory for each floor (the imeta for each level) but you can also have an over view of everything in the entire building (the ipak's imeta) The format is as follows: string (256 bytes): texture name with no extension 8 bytes : padding 4 bytes : constant = 1 4 bytes : width 4 bytes : height 4 bytes : constant = 1 4 bytes : mipmap count 4 bytes : face count (only 1 face, or 6 faces for cubemaps) 4 bytes : type (see below) 8 bytes : pad 4 bytes : size 4 bytes : pad 4 bytes : size 4 bytes : offset 4 bytes : pad 4 bytes : size 4 bytes : pad Why the size is there three times, I dunno. From what I've seen poking around, I haven't noticed any variation. This engine seems to be rather redundant in many different ways. The offsets must start at : 0x00290008. meaning there is only enough space for 8192 (0x2000) imetas in an ipak (with 8 bytes of padding). the "type" is a hex enumerated representation of the dxt format used. 0x0a : "AI88" - No block compression. 0x30 : "AI88" (for whatever reason "part plasma" uses this, and that's basically it) 0x46 : "AXT1/OXT1" - BC1 0x49 : "XT3" - BC2 0x4c : "XT5" - BC3 0x4f : "XT5A" - BC4 0x52 : "DXN" - BC5 0x5a : "ARGB8888/XRGB8888" - No block compression The Ipak The Ipak data starts at offset 0x00290008 as stated above. Each entry has it's own header, and the data contained in these blocks are simply just .dds textures stripped of their header. The header is as follows: signature : f0 00 ff ff ff ff 54 43 49 50 02 01 ff ff ff ff 4 bytes : Image Width 4 bytes : image height 4 bytes : unknown (usually 1, there are 5 exceptions, in all cases it's a power of two) 4 bytes : face count singature2 : f2 00 ff ff ff ff (4 bytes unknown) f9 00 ff ff ff ff 4 bytes : mip map count start of data: ff 00 ff ff ff ff .... .... footer : 01 00 ff ff ff ff There are a few unknowns in here I'm working to figure out, but for the most part the things labeled "signature" are fairly consistent (except the 4 bytes of unknown in the middle) Most of this is pretty self explanatory. (You can reconstruct the .dds header using the known information using : https://docs.microsoft.com/en-us/windows/win32/direct3ddds/dds-header) The Ipak also has padding tacked onto the end of each file. It's literally just 2,097,151 (0x1fffff) bytes of null data.