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


Everything posted by Zatarita

  1. Tex Mod is the second public release proof of concept tool from SeT. The process is still slightly complicated; however, due to how much I've seen people wanting custom textures. I decided to rush the build. BACK THINGS UP, USE AT YOUR OWN RISK. The program is still incomplete, things will get easier with time. I also can't guarantee it will work as intended every time. As of now this is a slightly more advanced example. Some things still required hex editing, though minimal. Let's go over how to use it: EDIT: Update has enabled "load from dds" and fixed some minor bugs. making a lot of this null. You can now just load the ipak, bind the imeta, and overwrite the original texture if you desire. Note** overwriting a texture means you'll need to rebuilt every imeta that uses that texture. Since the file size might change. This will be addressed in the next update open the ipak that holds the texture (alphabetical split at "p") bind the imeta for the level find the texture you wish to replace. Click "load from DDS" (Click save to dds for a reference texture to edit) load custom texture build the imeta (since there may be more mip maps and such, or changes in dimensions) Save the changes Our final result. Sorry for the rushed tutorial. I had like 30 mins to make these screenshots, build the project, upload, and fix post. for custom template textures follow original tutorial: THERE IS STILL A LOT OF WORK NEEDED TO GET THIS WORKING RIGHT. Please please post bugs, this has been a long time coming, and a few months of work. I want to get this working perfectly. There are a few ui bugs here and there that need to be fixed, but I wont have much time to dedicate to it this week coming. Hopefully this should give people some time to play with it, and I can get an idea what direction to take things before I dump too much work into "my way" and have to move back on some progress. The final source hasn't been pushed to the github repo yet. tex_mod.rar
  2. UPDATE: Fixed load from dds. May still be slightly buggy. (see original post for updated example. Thank you s3 for letting me use your golden gun) This should maintain bump maps and such for the texture that otherwise wouldn't be referenced correctly with a new texture name. Fixed crash on canceling save/load Fixed export function to actually let you designate a location and name. Fixed autofilling file name known bugs: Old data still wont clear when you load new data. For some reason it wont clear the list.
  3. I don't think I understand. It's possible they convert the dds textures to easier to use formats, but these textures are uncompressed. If you add the right header to the file you get texture, no extra tweaking needed. As far as compression goes, they already have the formatting applied. It's not just raw rbga channels like a bitmap (except argb/xrgb.)
  4. What do you mean by uncompressed? The Texture its self is just a headless dds. If you're talking about block compression it does support argb8888 which doesn't have block compression. The ipak is compressed with zlib, so you COULD compress with 0 compression level. Which would basically look uncompressed with some bloat
  5. It'll get easier once I figure out what's wrong with overwriting textures. It's just tough now cause we need to create a new texture and link it to the template. Once I fix over writing it should be just load, import, save Imeta, save ipak. As far as newer textures, I only see support for: Dxt1/3/5, argb/xrgb8888 (meaning light maps need to be covered from 16 bit), ati1/ati2, and ai88(greyscale)
  6. SMI Beta In an ode to the old days of PMI, I introduce SMI. Saber model injector. This program will handle extracting contents from s3dpaks, and reimporting them. SMI is SuPs big brother with a degree. It can recursively extract tags, and it can also handle reimporting them as well. This makes injecting templates from other s3dpaks significantly easier. After watching S3's tutorial it gave me a few ideas on how to make modding easier for the end user. S3 gave me permission to use his test map that he used in his tutorial to demonstrate it's strengths. Taking a look at this scene, it doesn't seem like much is going on; however, in classic there are a few objects present. (ignore the white boxes, it's supposed to be rain, we wont be fixing that texture in this example) There are objects present in classic, that aren't present in anniversary. This is because anniversary is missing the templates for this level. We're going to fix that with SMI. first we're going to open the s3dpaks we need to edit/extract from. The example above needs a wraith, a sniper, a c gun turret, and the longsword. For these templates, I'm going to load b30 (the map we're working with), a10, and b40. I'm going to expand a10, and select the fighterbomber (longsword) template I'm going to click extract recursive from the edit menu, and navigate to a directory I have named "Extracts" Once I select the folder, a subdirectory will be made with the name of the extracted templates. I'll repeat the same process with the sniper rifle, sniper rifle projectile, wraith, and c gun turret. now going back to SMI, I'm going to ensure the scope is set to the map that I want to edit: and I'm going to click "Inject Recursive" and select each directory in my extracts I wish to import: As you can see the templates are now a part of the s3dpak. Next we need to build the imeta so the templates textures will carry over(only for aniversary. I will make a script to simplify classic soon) To do this we go to Edit>Build Imeta(or hit F2) Save the imeta, and then we'll save the s3dpak with the standard file>Save As (I haven't implemented save. It'll be in final release) And that's it! SMI will handle compression, decompression, updating the Imeta, updating the SceneData, and the s3dpak. Our final result: significantly faster, easier, and more accessible to new modders c: this is a beta version, and any bugs will be squashed! please post them below. Currently, the source can be found in the SeT GitHub, under "tools" Bug fix update(10/9): Bug fix update(10/18): SMI.zip
  7. Some progress has also been made on importing textures to IPAKs. "Tex mod" is another proof of concept program for SeT that will be replaced. It's implementation is almost complete; however, there are still bugs needing squashed. Keep your eyes peeled. I'm going to try and stream line this due to popular demand. Hopefully I'll have it done by the end of next week. But I tend to set due dates too soon, so let's say the end of the month of I hit too many speed bumps
  8. So, things have been a bit quiet from my front this past month, but I figured I’d post an update to some of the progress that’s been getting made. When I say “team” I currently mean myself; however, I am looking for people to join. If you’re interested shoot me a dm onto the updates! SeT had a major revision. I refactored everything to utilize polymorphism a bit more. Hopefully to keep things a bit more organized. There have been 2 major updates to SeT. One is SEK. Which is a saber editing kit. It’s a hek style set of tools that will be used to modify saber files. this is going to replace SuP. Planned tools are: S-edit - a guerillaesque program used to edit the files inside the saber paks. s-tool - a tool-esque program used to compile new files. P-arc: this will let us pack All the mod files into one file (.s3dpak, .ipak, .imeta, .fmeta, .map). It also lets us send only the modded files, greatly reducing file size. File size comparison (desert hog mod): my hopes is this will simplify modding cea, and make it more user friendly. besides planned programs, my hopes is to create an export/importer with templates to blender. Coordinates, texture coordinates, and faces have been mapped out for cea. This means I can extract most of the model data; however, this is only for “simple” meshes. I have not found rigging data. Research is still being done. I’m going to attempt to manually build a model into a template to test building soon. lastly, While the primary focus is for h1, I have been poking around with h2a as well. I managed to extract the contents of the h2a pck files. I have a lot of templates from there as well. I figured out some of the model data for them as well; however, I wasn’t able to figure out texture coordinates, or rigging information for that either. is your interested in helping out, I could really use a hand. I only have ~2 days a week that I can dedicate to this.
  9. More progress made! Fixed a compression bug, implemented h2a decompression, and compression (still needs to be tested) also added the beginnings of a tool "SMI" an ode to the nightmare fuel days of PMI with HMT. it's for injecting templates into different s3dpaks. The functionality has been added to recursively extract templates, and their coresponding Imeta entries. Making injecting templates as simple as extract, import. It also adds the templates, and the textures to the SceneData. Automating the process almost entirely. Currently SMI only has extracting programmed in; however, it shouldn't be too difficult to finish. This is more of a "proof of concept" than anything. The tool is designed to hold people over until the full release of SeK.
  10. See next post for v 0.2.0 information Sabre unPacker is a program that will extract the contents from a s3dpak file (and with future updates hopefully other sabre files) Icon is still being developed. Currently it's in beta version. If there are any features you want to see added, just put them in the comments. To use the program simply open a *compressed* s3dpak file ceaflate will decompress the file and add it to the TMP directory. Select the files you wish to extract, and select a location for them to go. profit. I hope this is a good step towards helping research the engine a bit more. future plans are to repack, and add the ability to read ipak Big thanks to Kavawuvi for letting me use ceaflate. Source License: GNU GPL v3 SuP 0.2.0.rar
  11. Another update! SeT got updated (and is now in desperate need of some house keeping.) sadly progress has been slow. I had an infected tooth and only really had the chance to work on this like 4/5 days this month. Still looking for help c: added: Bugs (probably) DirectX support Importing from dds (still kinda broken; however, it has been pushed) dds definitions for the used types Converter for 16 bit argb to 32 bit A basic beginning to a texture tool Compression (which needs to be threaded) imagine is a test of importing custom dds textures.
  12. 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
  13. 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.
  14. 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:
  15. 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
  16. 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 : depth 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 : depth 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.
  17. 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
  18. 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.
  19. It'll be his 10,000th post! Don't let me down Tucker, this is means to celebrate! Post memes
  20. What if the good thing IS being a doctor
  22. 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
  23. 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-
  24. Is this irony .-.