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


Forums

  • OPENCARNAGE.NET (OC)
    • Site Matters
    • Member Introductions
  • HALO: SOFTWARE EXTENSIONS (SE)
    • Chimera: General
    • SAPP: General
  • HALO: CUSTOM EDITION (CE)
    • Halo CE: General
    • Halo CE: Development
  • HALO: COMBAT EVOLVED (PC)
    • Halo PC: General
    • Halo PC: Development
  • HALO: MASTER CHIEF COLLECTION (MCC)
    • Halo MCC: General
    • Halo MCC: Development
  • BROAD STROKES (BS)
    • General Gaming
    • Tech Chatter
    • Off-Topic

Outstanding Mapper

Found 13 results

  1. Introduction Hello! My name is Zatarita! Today, we look at Texture files found inside of S3dpaks. On the Xbox release of CEA. The S3dpak is the primary file type used for storing game asset data. This means for the Xbox version the S3dpaks had to contain the textures used by the assets in scene. There are a few different files that work together to allow the engine to load and index textures when needed. For example TexturesMips64, and TexturesInfo. For more information on these the appendix. Depending on when you read this, there may be dedicated pages explaining them and how they work together. By the time you are done reading this tutorial. You should feel confident in your ability to navigate through a texture file. I will also show you a few techniques to extract the textures manually from the file; given you ever find your self with the need to do so. One thing to keep in mind is there are two different flavors of Texture. The ones in the pac_stream.s3dpak are different from the ones inside of the level s3dpaks. I'm assuming it was done this was so that s3dpak could stream the texture pre-formatted right into memory without any other processing. These streamed textures use the same format number as the non-streamed variants ( 0x6 ) inside the s3dpaks. So there is no easy way to tell which texture type you have without inspecting the data. These style textures are not going to be covered as I sadly don't have enough time at the moment, and requires a more nuanced explanation. I will cover these textures in their own post to give them the needed attention they require. DISCLAIMER I will periodically review this post to add updated information as new discoveries are made; however, all information present here is correct to my current understanding. Some things may be proven incorrect. Texture The Texture file utilizes a common system used by a lot of different saber files. Each 'structure' of data is assigned a sentinel value. Following this sentinel value is the end of block pointer. This end of block pointer points to the start of the next sentinel value. Everything in-between is data that belongs to the structure of data. The "structure" can be anything, sometimes even just one property of the data. For example, we can see in the picture above the sentinel "0F 00" in blue with the end of block value "0A 00 00 00" following it in pink. The value "0F 00" in this context denotes that the data is a signature. In green we can see the value of the data "TCIP" which denotes that the superseding data should be interpreted as texture data. Following this we have "02 01" and another end of block value. With an understanding of the sentinel system; I can explain the data in relationship to that system. It will make more sense. F0 00 - Signature ("TCIP") 02 01 - Dimensions Width, Height, Depth, Faces (0x400, 0x400, 0x1, 0x1) F2 00 - Format (0xC) F9 00 - Mipmap Count (0x1) FF 00 - Pixel Data ( ... ) 01 00 - End Of Data ( ) Additional Reading Format Formatting follows a similar system to the other files like TexturesInfo, TexturesMips64, and the Ipak. I have laid out on a table the supported textures for the Saber engine. Out of all of the options, only a handful are used by MCC, and they are highlighted in green. This table can be used to reference which format number is which dds format. As seen above in pink, the format of that texture is 0xC. Which corresponds to the value OXT1 on the table. For more information on the table see TexturesInfo in appendix. Extraction Now we get to the fun part. We're going to use the information we extracted from the data above to extract a DDS file from the Texture. For this we're going to need a few prerequisites. RawTex will help us generate us a DDS header for our data. Also, In order for rawtex to show us a preview it requires texconv to be installed in the same directory as rawtex. Once we've done this we can open rawtex, and drag a texture into the window. Briefly I will go over the UI. On the top left there is a textbox labeled 0xOFFSET which is how we tell rawtex where to find the pixel data. On the column to the left, and row on the top, there are height and width selection options, Plus text boxes where you can manually type it in. Also, on the column on the left, we have a few options for format. Following this is the "Try and Convert" button. There are a few other things; however, for our purposes this should be enough. The best way to figure it out is to play around with it. It's one of my go-to "Reverse Engineers Toolkit" items. Moving on, we're going to extract a texture using the above information. I grabbed a random texture and dragged it into a newly opened rawtex window. When we do that, we see this beautiful creation. We have to update the information to the correct properties using the data from the hex. The important data is the height, width, and format. For my case the data is 256, 256, OXT1. Once the correct values are inputted. We are shown the texture, and a .png copy of the texture is saved to the same directory as the original file once you click "Try and Convert". Conclusion The xbox version of the game utilizes s3dpaks as it's primary format for storing data. Because of this, they need to be able to support textures which can be utilized by assets on scene. They manage this with the "Textures" format. There are a few variants to the Texture format, and in this tutorial I introduced you to the non-streamed variant. In this brief spec I attempted to present to you enough information about the format to be able to navigate it's contents with some level of confidence. Thank you again for stopping in. PS Currently I'm unsure if there is a tool out there that can extract from Xbox s3dpaks; however, in the s3dpak specification I go over how you can manually extract data if needed. It's not too complicated. Appendix s3dpak TexturesInfo ipak / imeta
  2. Introduction Hello! My name is Zatarita. I'm sure you've seen me around. I may have made one, or two, posts in this subforum. I had some free time today, so I felt I would delve a bit into some of the sub-files inside of s3dpaks. For those who are unaware. S3dpaks are archive style files that contain game files inside of them. The TexturesInfo file ( if you want to call it a file ( its definitely easier to consider it a file... ) ) is one of these sub-files. For more information on S3dpaks see my write up in the appendix. DISCLAIMER I will periodically review this post to add updated information as new discoveries are made; however, all information present here is correct to my current understanding. Some things may be proven incorrect. All that aside, I'm fairly confident in my findings; I have developed working mod tools using this understanding. The TexturesInfo data is fairly straight forward, and I'm certain the information here is complete. TexturesInfo Starting off it might be important to understand what the TexturesInfo data actually does. It's functionality it drastically different for the pc version to the xbox version. In fact, the PC version doesn't even use it at all as far as I can tell. You can just delete it from the s3dpak and move on with your day no problem; however, for the Xbox it's a different story. One of the major differences between PC s3dpaks and Xbox s3dpaks is that the Xbox variant contains the textures needed for the level and all the objects contained with-in. Meaning that each level has it's own copy of each texture. This is rather inefficient which is why, I'm sure, they switched to the Ipak/Imeta system used by PC. Fig 1. TexturesInfo Entry list (Left) And the corresponding textures inside the s3dpak ( right ) The TexturesInfo is the glossary containing the meta data about the textures contained within the s3dpak. These textures are also files inside the s3dpak. The TexturesInfo files the tells the s3dpak the name, format, dimensions, face count, and mip map count of each of its entries. This again is rather redundant as the texture entry inside of the s3dpak also contains all this information except for the name of the texture. You can see an example s3dpak below with the TexturesInfo data exposed. Notice the file count at the top is significantly different between versions as well. This reflects the presence of textures in the s3dpak ( as well as other file types not present in the pc version, see appendix ) The PC version just contains default values in everything, but still has the texture name present. Fig 2. Xbox (Left) Compared to PC (Right) TexturesInfo. Format The texture format is a DDS format type. In fact the textures are all just dds textures with the header replaced with a saber specific one. There are a handful of supported formats with the saber engine. In fact the list is quite long. Most of them are completely unused by the halo engine. Some of them may be wrong; however, for the means of MCC; all the ones supported by the engine are represented accurately. Also do note that H2A is in the table as well. This is to reuse the table at a later time. You can ignore that column all-together. One special note about the table is OXT1/AXT1. These are both DXT1 textures; however, it is believed that the "O" and the "A" stands for Opaque and Alpha respectively. We're not quite sure why they split them up. I believe it's an optimization thing rather than a system limitation; because, regardless of system I still see the split between the two. Something to keep in mind though, as they are both technically just DXT1 blocked compressed textures as far as DDS is concerned. The Raw Data The raw data for the textures info is pretty straight forward. One interesting note about this compared to other Saber formats is there is no child count present. Since the string length can vary in length, there actually is no way to access the children randomly. This must be processed as a stream of data. The TexturesInfo follows the string length followed by string text pattern see in other Saber format. Following the string name is the signature "TCIP" which is pict backwards. This is seen again in the h2a pict format ( see appendix ). After the signature, in order ( all 32 bit unsigned integers ) is width ( Purple ), height ( Cyan ), depth ( Green ), face count ( Yellow ), mipmap count ( Browm ), format ( Orange; see above, first item = 0 ) Fig 4. Textures Info ( Left ) Mapped to colors ( Right ) Conclusion Inside the s3dpaks are many different file types. The TexturesInfo is one of those format types. It contains high level metadata about the textures that the s3dpak house. It is important to note the the textures info file is xbox only, on pc there is only placeholder data present. Many formats are available for the Saber engine; although, only a handful are supported for MCC. It may be important to manually edit this file for modding Xbox files, along with importing the textures that correspond to the entry you're importing. In future updates I will add a reference to SceneData, and s3dpak Texture and TexturesMip64 entries once the pages are made for the formats. Thank you all so much for reading c: and I hope you learned something. If anything seems unclear, do feel free to drop a comment and I will gladly reply when possible. Appendix S3dpaks: H2A Pict format
  3. Introduction Hello! My name is Zatarita. I'm the current dev for SeK. I felt I should share some of the information I have acquired while researching the engine. Pieces of this information was acquired through reverse engineering the files, combing through a disassembly, and even other games saber has produced around the same time. The S3dpak file is an archive file similar to a .zip, .rar, or .tar.gz ( for the linux bros ). Currently, not everything is known about the files contained within the s3dpaks, but the structure of the s3dpak as a whole has been mapped out completely. ( for this generation's saber engine at least ). I will periodically review this post to add updated information as new discoveries are made; however, all information present here is correct to my current understanding. Some things may be proven incorrect. All that aside, I'm fairly confident in my findings; I have developed working mod tools using this understanding. I hope to present to you enough information to confidently navigate a s3dpak from the lowest level. By the end, you should theoretically understand how to manually extract data from an s3dpak given you had the need. The S3dpak As previously stated the s3dpak is an archive format. This means it's a file that contains other files. Some s3dpaks are general purpose, as they aren't linked to any specific level, and others are level specific. There is one primary difference between s3dpak and other archive formats. That is s3dpaks are specialized for use inside the Saber engine. It only takes specific "file types" if you will. These are assets required for the level; level geometry, models, sounds, textures, etc. This is called the format of the data. There are only a handful of available options, and some of them are just remnants of the saber engine; completely unused by Halo. The s3dpaks are compressed using CEA compression. ( For more information on compression formats see appendix a. ) This means in order to see the contents the file needs to be decompressed. There are a number of tools available to decompress the files.( see appendix a ) Once decompressed, if we open up the file in a hex editor we get our first glimpse into a s3dpak. The byte order of all saber files, including the s3dpak, is little endian. ( Byte Ordering ) The Header Fig 1a. Overview File Fig 1. Overview Data The header is the beginning section of a file. It typically presents a high level view into a file similar to a glossary does in a book. For the s3dpak; it breaks the file into entries and raw data. Where each entry contains file metadata, or information about the file, and a pointer to where to find the data in the raw data. At the beginning of any s3dpak there is an entry count telling us how many entries are contained within this file. Following this is a list of entries. Everything else in the file is raw data used by the entries. Referencing the graph above we can get an idea of how the header helps guide you through the file and gives you an idea of what you're looking at. The text in yellow is metadata about the entry. Things like what the filename is and what format the data is. Using the entry's offset and size, we can get data from the file. Fig 2a. Header Hex Fig 2b. s3dpak hex map That's rather abstract, so let's try taking a look at the actual data. On the left we have the raw data for a10.s3dpak. On the right we have the same data mapped to colors. Some colors may be hard to see; however, I used those colors on unimportant data as you will see. The first four bytes of a s3dpak will always be how many entries are in the file. The first four bytes in this case are 07 04 00 00; although, Since the file is little endian we reverse the order and get 00 00 04 07. After we drop the leading zeros we get 0x407. This is how many children are present in the file. If this was confusing please see the appendix for an explanation on byte ordering, as endianness will be important for this section. Following that we're going to load each entry left to right top to bottom. Green (4 bytes) = Offset to the start of the raw data = 0xa68c Cyan (4 bytes) = Size of the raw data = 0x18624 Yellow (4 bytes) = Number of characters in the name of the filename = 0xC (TexturesInfo) Purple(n bytes) = Characters that make up the file name. This is easier to see in the string view of the hex editor. Underlined in the same color. = "TexturesInfo" Blue(8 bytes) = unused padding. Using this information we could very easily extract data from an s3dpak. A few hex editors offer the option to select a block of data. You can just plug and chug the data from the header to select the entire entry. Using the previous example with HxD. I'll start by going to "edit > select block" It will pull up a tool that allows me to select a range. In this case I just plugin in the starting offset 0xA68C, the Size 0x18624, and click ok. ( Do note that HxD does not require the 0x ) It will select the range of data for me, which I can copy and paste into a new document. Upon doing so you have manually extracted data from the s3dpak! Fig 3. Manual extraction Format Now that we've gotten the raw data from the file, how are we supposed to interpret what we're looking at? This is where the format comes in. Format determines how the engine attempts to interpret the data when it loads. Is this data a texture, or is it a model? This is an important distinction. Currently all of these formats haven't been completely mapped out; however, as it stands here is what I know. Fig 4. Supported formats by build. Not all s3dpaks are equal. Xbox has some features that the pc version lacks. With that comes an exciting chance to make a table, and who can turn that offer away. Above I have shown a table of formats, and their compatibility across platform. In the xbox version of the game the s3dpak is the primary storage file, compared to pc's imeta/ipak system. This means that a lot more functionality needs to be packed in on the xbox version to offer more flexibility. Another thing to note is "multiplayer". The multiplayer section only applies to pc. It appears as though all maps have a bare minimum requirement by the saber engine, and while the saber engine isn't used for multiplayer, these files are still needed to work. I believe most of these files are practically identical from level to level bar a few exceptions anyway. just generic placeholders. A few of these formats have been worked out, some are pretty basic, some are still being researched. Here is what is known now. Any item with a hyperlink will be a link to a post about it if it exists. ( this will be updated with time ) [0] SceneData - A high level list of items present in the s3dpak. This document is primarily plain text [1] Data - To be updated at a later time. [2] CacheBlock - To be updated at a later time. [3] Shader - Primarily plaintext shader source. On xbox it is typically compressed using zlib. [4] ShaderCache - To be updated at a later time. [5] TexturesInfo - High level information about the textures contained inside the s3dpak. Isn't xbox only; however, is unused in pc. [6] Textures - Texture data similar to an ipak entry. Contains dds textures. [7] TexturesMips64 - Also texture data similar to ipak entry. Not sure why this one is special. [8] SoundData - To be updated at a later time. [9] Sounds - Unused by any Halo game. Remnant of Saber engine [10] WaveBanks_mem - To be updated at a later time. [11] WaveBanks_strm_file - To be updated at a later time. [12] Templates - Proprietary 3d model format for use in Saber games. [13] VoiceSplines - Unused by any Halo game. Remnant of Saber engine [14] Strings - Wide char text file for misc strings used in the game. [15] Ragdolls - Unused by any Halo game. Remnant of Saber engine. [16] Scene - Level geometry with merged level specific templates. Similar to Blam scenario [17] Hkx - PC only ( not sure if enforced on xbox ) breakable glass definition. Typically paired with a template of the same name [18] Gfx - Flash file, can be decompiled with a Flash Decompiler. it is compressed on xbox using the same method as Shader. [19] TexturesDistanceFile - To be updated at a later time [20] CheckPointTexFile - (Unused by any Halo game.) [21] LoadingScreenGfx - Unused by any Halo game. [22] SceneGrs - * assumption * Scene grass detail object definitions and locations. [23] SceneScr - Unused by any Halo game. Remnant of Saber engine. [24] SceneAnimBin - Unused by any Halo game. Remnant of Saber engine. [25] SceneRain - Defines precipitation ( not just rain ) for a level [26] SceneCDT - To be updated at a later time. [27] SceneSM - To be updated at a later time. [28] SceneSLO - Unused by any Halo game. Remnant of Saber engine. [29] SceneVis - To be updated at a later time. [30] AnimStream - To be updated at a later time. [31] AnimBank - Unused by any Halo game. Remnant of Saber engine. The appendix Compression Formats
  4. Halo MCC introduced compression to some of the game files. All of these formats are generally the same concept, but applied in different ways. In this topic, we're going to discuss the different forms of compression found in a few of the MCC halo versions. Primarily halo cea, and h2a pc. Compression on h1a standalone release for the 360 is different. Each of the compression algorithms use zlib compression. Generally the file gets broken up into certain size chunks, each chunk gets compressed and laid out sequentially. An offset to the beginning of each chunk is stored in the header along with chunk count. Each algorithm uses a variation of this technique, and I will cover the three main ones. H1A compression - Used in halo 1 anniversary files (*.map, *.s3dpak, *.ipak) * NOTE: due to a recent update, map files are no longer compressed * H2A compression - Used with halo 2 anniversary non-map files (*.pck) H2Am compression - Used with halo 2 anniversary map files (*.map) I have developed a tool for decompressing both generations of files with a quick right click shortcut. H1A Compression H2A Compression H2Am Compression EDIT: Some software uses a variation on the compression algorithms. MCC does not verify the first chunk offsets, This means we could leave the superfluous 0's out of the header. For example Invader only writes the offsets in the header needed for the file. Meaning the chunks start right after the last offset. This can reduce the header size significantly. This is not required for understanding; however, you may come across this variant in your hex adventures. When writing algorithms, I feel it is good practice to continue this way.
  5. If you wish your custom/modified Halo CE/PC campaign map to be able to use localized subtitles in MCC: All .sound tags you want to have subtitles needs to be in the "sound\dialog\" tag folder (or its subfolders) [#invader-refactor can be helpful for moving sound tags from existing maps] Only audio played via script (sound_impulse_start) or AI_Conversations system are eligible for subtitles. Subtitles themselves are referenced in the initial_textures.s3dpak, located in "[MCC]\halo1\prebuild\paks" Each sound tag is referenced individually by its path in the tags folder ex: sound\\dialog\\x50\\sgt01 The subtitles are separated from the tag reference by some spacing (Tab 3x), and the subtitle text itself is contained within quotation marks. If you wish to have "quotes" appear in the subtitles, the will need a \ before them. Some other special characters may also need this. "Watch your mouth, Son! This \"stuff\" is your history. It should remind you grunts what we're fighting to protect!" Using SuP you can extract/import the "strings_english" (or "strings_your language") file, and you can edit it with any text editing program (I advise Notepad++). SuP: Invader:
  6. To play Halo: The Master Chief Collection on Steam, with mods, you must disable Easy Anti-Cheat (EAC) or simply 'anticheat'. If you don't do this, you can get VAC banned on Steam which may lead to consequences like being unable to play multiplayer or worse. Option 1: Desktop shortcut. Here's how to get a desktop shortcut with the official icon. First get the original game shortcut which can be placed automatically as you install the game, or manually add it later by doing the following: Find Halo: The Master Chief Collection in your Steam games library list and right click it. Select Manage. Inside the Manage sub-menu, click Add desktop shortcut. Once you have a normal Halo MCC desktop shortcut, do the following: Copy and paste the shortcut Steam made for you, then rename it 'MCC NonAC' or whatever you like. Edit the properties of the shortcut. In the URL field, replace steam://rungameid/976730 with steam://launch/976730/option1. To finish, select OK. Be careful not to accidentally run the original if you have installed mods. Or just don't have the original at all. Option 2: Through the Steam games library. I personally find this method to be annoyingly repetitious but if you have lots of games, this can be a way to keep your desktop clean. Navigate to Halo: The Master Chief Collection in your Steam games library. Launch the game using the big green PLAY button. (Shown in the picture as blue CANCEL since I already clicked it.) Two windows will appear, one is a prompt. In the prompt, select the option that says "Play Halo: MCC Anti-Cheat Disabled (Mods and Limited ..." Press PLAY and enjoy your mods worry-free!
  7. Hello! I've been trying to work on my editing style, So I do appreciate your patience while I find my method. any feedback is greatly appreciated! In these sets of video I go through the process to create the fence thingy from foundry, and how you can use the same steps to create your own scenery objects. These aren't perfect tutorials; however, I try to do this without diving too deep into the tag system. I plan on creating videos for each tag type, so as to not overwhelm I tried to simplify as much as possible. Video 1 Video 2 Video 3
  8. We go over how the saber files manage textures, and how to add textures to a level when the dependencies are missing links: tex_mod:
  9. This one's a doozy. Let's begin. CEA supports loading Custom Edition maps. However, on further inspection, it does not actually properly support Custom Edition maps, and asking employees from 343 Industries for assistance does not seem to be particularly helpful. At best I’ve been told to “wait for modding support” and at worst, I’ve been… uh… not told anything and just completely ignored. I have my own reservations regarding how this is being done with little to no community interaction and mostly in secret, but that’s not relevant here. We’ve done some of our own research by way of taking custom maps and seeing what happens. We did this to see if we could get the Refined set of maps to look correct on CEA, so here are the results. Getting the maps to even load CEA requires the base maps to be compressed using a chunked zlib format. CEA requires the file size in the map’s respect .fmeta to be correct. CEA requires the map to replace a stock map (note that setting the file name in the map file, itself, is not required - merely renaming and setting the fmeta file is sufficient) CEA also requires Custom Edition’s bitmaps.map, sounds.map, and loc.map to be copied into the maps folder (NOT compressed) Invader supports building MCC maps. When built with invader-build -g mcc-custom, the maps are generated compressed and a matching .fmeta file Bitmap format support CEA does not support 16-bit bitmaps. This is the default setting for lightmaps and is what tool.exe generates. These textures will instead show up as black. CEA does not support P8 bump textures. Custom Edition does not either, but while Custom Edition simply doesn’t render the bitmap, CEA instead crashes. This is worth mentioning because the stock Infinity that came with Halo PC actually has a P8 texture despite being made for an engine that does not support it. Workarounds: Use invader-bitmap to regenerate the bitmap as 32-bit if you have source data OR you are using a tag that wasn’t extracted by a tag extractor and/or modified by last-resort. You may get a quality improvement in this case! Use last-resort to convert the bitmap to 32-bit if you are using extracted or modified tags and you do not have source data. There won’t be any changes in quality, but it’s better than nothing. HUD scaling and positioning CEA has effectively increased the resolution of the HUD from 640x480, but it does so in a way where it tries to be backwards compatible with 640x480 HUD placement Since CEA scales HUDs differently, most elements have to be modified for them to look correct. Also, some HUD elements may be placed differently, since CEA has a widescreen “fix” of its own that tries to turn a 4:3 HUD into 7:3, 16:9, 16:10, etc. Workarounds: You may need to rescale your HUDs by a factor of 2, disable high resolution scaling, etc. to get the HUD elements to be sized correctly You may also need to reposition HUD elements in some cases. CEA may potentially break things like the sniper ticks and numbers which may require further adjustment HUD colors CEA has repurposed the green channel in HUD elements to control things like intensity and alpha, thus they had to make the meters show up as monochrome. Because elements are monochrome, multi-colored elements (e.g. Refined’s Xbox-style heat meters) are not possible in MCC. Also, some colors may appear to be more washed out with lower alpha if the green channel is too high. The empty color may look wrong, too, since this green channel seems to determine the opacity of that (even though empty has an alpha channel?) Workarounds: Monochrome elements: Set the green channel to 0. This will result in your HUD bitmaps appearing to be magenta in your image editor, but they will show up as monochrome in-game. Lower green may result in the empty color not appearing, while higher green may make the colors washed out with lower alpha, so you may need to fiddle with the green channel if you aren’t happy with the result. Colored elements: Create separate HUD elements and bitmaps for each color and use the HUD interface tag to set the color. This may sound like it’ll be complete hell to implement and that it’ll probably also look bad, and that’s because it will. Jackal shields CEA changes the jackal shields to match the Jackal’s rank to attempt to imitate Xbox behavior. This may end up resulting in your own custom shields looking incorrect. Workarounds: Change the tag path of the bitmap (or shader?)? This needs testing. Refined never had this issue, but the issue exists nonetheless since it’s something the stock CEA game does do. Anniversary models In singleplayer, CEA has a separate ‘anniversary’ renderer that replaces all the assets with assets inspired by Halo 3 + Halo Reach (or as we sometimes call Halo Threach or 3ch). This obviously does away with most of the visuals assets used by the base engine besides HUDs. Custom assets may not appear correctly or at all in the new renderer. Level geometry may not look correct assuming it even appears. Workarounds: Doing anything with the CEA anniversary renderer is outside of the scope of Refined, so we have not bothered looking into any potential workarounds. We just recommend not using anniversary graphics while using custom assets… or even stock assets since they also have issues. Wait until some sort of editing tools are released for manipulating Saber3D stuff. We don’t care. Custom sounds CEA replaced the sound system and uses a proprietary engine, FMOD. Custom sounds (or higher quality sounds) will not play or will use the older (or anniversary) sounds from the FSBs. Sound environments don’t work correctly. Reverberation does not work correctly, sounds are not muffled, and distance attenuation is very basic. Workarounds: Halo PC Anticheat MCC uses anticheat which requires that files match a checksum in order to load successfully. Loading these maps while anticheat is enabled will fail. These maps cannot be played on matchmaking (and possibly not on whatever custom games browser 343 Industries is working on) due to it requiring anticheat to be enabled. Workarounds: Disable anticheat and only play singleplayer or with friends. Remind yourself that CEA’s matchmaking is in a broken state even if its many issues can be (and have been) easily fixed, and then cry yourself to sleep each night as nobody does anything about it. See this post for information on disabling anticheat: Conclusion At the time of writing this, it is currently impossible to make the Refined experience on MCC up to par with Refined on Halo PC (both the retail version and even the more broken Custom Edition), and this may be the same for most custom maps. And really, support for MCC in its current state is experimental at best with the latest builds of Refined. It is highly recommended to play the maps on Halo PC as released by Gearbox for the best overall experience unless you want to play co-op. To summarize: The HUD colors will always look slightly washed out due to the shader being different. The Xbox heat meter gradients are infeasible to implement, and even if they were easy to do, they wouldn’t look correct, nor would the rest of the HUD. The sound system is in a pretty broken state. Using custom higher quality or uncompressed sounds is not possible without reverse engineering and replacing the FSBs (FMOD sound bank, not front-side bus), thus it will only be as good as the audio that came with MCC, assuming the sounds did come with it. MCC also has a number of issues on its own ranging from annoyances (banshee engine/contrail audio tied to frame rate, cutscenes locked to 30 FPS and looking even worse with an unlocked camera) to game breaking issues (input issues). Therefore, even if MCC perfectly supported these maps, it would still be an inferior experience, with the only notable redeeming qualities being a fixed water shader and co-op. And, of course, it is also not possible to play the (Semi-)Refined multiplayer maps on matchmaking (and possibly their custom games browser) due to anticheat, thus you will be restricted to custom games with friends. Halo PC does not have this issue (or any of the other issues listed above), and you can play the fixed maps on servers running the original maps. And, to quote myself from another Discord when asked about Refined vs. Halo PC: Considering porting maps is not a simple process and the results are always going to be inferior to the original, one must ask the question if it's even worth doing at this point.
  10. This is part two in an ongoing series explaining how to mod halo cea. See part one here: In this tutorial we will go over our modding tools and learn how to use them by making a small mod. commands: invader-bludgeon --all -T invalid-indices -T invalid-enums -T out-of-range invader-refactor -M no-move -c model gbxmodel invader-strip --all invader-build -g mcc-retail -c -n levels/test/bloodgulch/bloodgulch links: Reclaimers Library: https://c20.reclaimers.net/ tutorial competition: https://opencarnage.net/index.php?/topic/8261-oc-tutorial-contest/
  11. MCC modding - Setting up your modding environment. In this video we look into setting ourselves up for modding halo ce anniversary. We gather the tools we need, and extract the files we'll use in future videos to build new more exciting maps. Command prompt macro: for /f %f in ('dir /b maps') do invader-extract -p "maps/inplace1.ipak" maps/%~nf.map Links: winRAR: https://www.win-rar.com/download.html... HEK: http://hce.halomaps.org/index.cfm?fid... halo ce: http://hce.halomaps.org/index.cfm?fid... mcc bundle: https://mega.nz/file/QzYxGSTY#cxmH05G... ahobo: http://hce.halomaps.org/index.cfm?fid... Halo reclaimers: https://discord.gg/Ht5yWvx *NOTE* I do not condone piracy in any way. halo custom edition will not run without a key. this does not bypass the security in any way.
  12. 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 4 bytes : padding 4 bytes : type (0 for s3dpak, 1 for .map) 8 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 IT SHOULD BE NOTED As of season 6 it appears as though the fmeta is no longer utilized by the engine to determine file dependencies. In 2 years we'll look back at this and go "oh yea, that was a thing." Time is fickle
  13. 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.