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


  • Content count

  • Joined

  • Last visited

  • Raffle Tickets



About Zatarita

Extra Information

  • Gender
  • Location
  • Occupation
  • Contributed
    $20 (US) to Open Carnage

Contact Methods

  • Discord

Recent Profile Visitors

3,548 profile views
  1. Found out today that there are more types for the Xbox version. So it's not compete complete. Will update with Xbox specifics later this week
  2. SeT Saber editing Toolkit is a set of python scripts dedicated towards editing saber files. While i was working on SuP, i realized that the path I was going down would limit the abilities I have to work with the data. I decided I would migrate to a more generalized toolkit, and use this as a backbone to program a more versatile set of tools. I intend to write a full SEK for editing saber files once I have fully mapped out the structures. hopefully, this may be useful to others who would like to create their own modding tools as well. It will be an ongoing project until everything is mapped out. The github has a readme that explains how to use it. Basically it allows programmatic access to the contents of saber files saving others the stress of having to reinvent the wheel every time they want to make a modding program. https://github.com/Zatarita/SeT Currently I have s3dpak, ipak, fmeta, imeta, TexturesInfo, and SceneData defined; however, ipak, and imeta are partially implimented. I am willing to accept any help if you wish to contribute to the project. join the discord for smaller updates. major updates will be brought to this post. You don't have to be a programmer to help! Anyone willing to poke around with a hex editor can be a big help c:
  3. 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
  4. Interesting, I actually haven't looked into the blam side of things yet; however, I'll look into it see what I can figure out. That could explain the other "size" variables
  5. I don't know what you mean, I haven't noticed any discrepancies. I ran into an issue originally with SuP, and I found out the issue was rawtex. It didn't extract mipmap, and face data so it would be cut off.
  6. 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.
  7. What if the good thing IS being a doctor
  9. Let's add a section for modding "Sweet Baby Girl Summer Fun 2 - Sunny Makeover" CMOOONNNNNN DON'T TEASE ;-; He's making us work for it, WE NEED TO SH*TPOST HARDER
  10. You're right! We should talk to an administrator about that If that happens, I'll be a heritic, and expect to have my armor stripped -Pokemon battle theme plays in the distance-
  11. It'll be his 10,000th post! Don't let me down Tucker, this is means to celebrate! Post memes
  12. Is this irony .-.
  13. ipak, Imeta, and fmeta file formats coming soon
  14. H2A-inflate is a quick python script I threw together to decompress halo 2 anniversary .pck files cli style interface (time to embrace my inner kava): h2a-inflate <file> <output> Quick and simple; source might be available if I can compress back in the future. This might also mean I can add h2a support into SuP at some point c: for batch files, I recommend copying the compressed files out of the directory, and creating a text document named "inflate.bat" copy this into it. Make sure h2a-inflate is in the same directory as the compressed file. mkdir inflated FOR %%i IN (*.pck) DO h2a-inflate "%%i" "inflated\%%~ni.pck" h2a-inflate.rar