Posted June 9, 2019 Hey @Kavawuvi, as you know I don't mod but I just read over most of your dev history and just find this entire idea that you are creating this program to drastically reduce "clutter" of modding Halo CE Maps interesting. Like, I didn't realize that modders were able to modify a game or game engine to be more efficient. From what I understand, this new format is most beneficial in potential to those who have reached the upper limit of modification "pliability", as we can call it? Where users can no longer push increasing amounts of mods into the map file because of stability issues? And from your latest updates with AI, it seems to me like your work here would be very useful for single player scenarios. Share this post Link to post Share on other sites
Posted June 11, 2019 It's another update! AI encounters now default to BSP index 0xFFFF if they don't have any spawns. This should remove some of the "0 BSPs" you may see, particularly the one in The Silent Cartographer. I figured out a hidden value in the biped tag, the head node index. Before this, I always assumed the value was 12, but some bipeds (most notably elites and Captain Keyes) have it set to something different. This value affects aim assist as well as cutscenes, notably the cutscene where Captain Keyes says, "Let's give our old friends a warm welcome." in The Pillar of Autumn. Before, the camera would zoom in on his ear. Now it zooms in on his face as expected. On 6/9/2019 at 2:36 AM, blitzburns4 said: Hey @Kavawuvi, as you know I don't mod but I just read over most of your dev history and just find this entire idea that you are creating this program to drastically reduce "clutter" of modding Halo CE Maps interesting. Like, I didn't realize that modders were able to modify a game or game engine to be more efficient. From what I understand, this new format is most beneficial in potential to those who have reached the upper limit of modification "pliability", as we can call it? Where users can no longer push increasing amounts of mods into the map file because of stability issues? And from your latest updates with AI, it seems to me like your work here would be very useful for single player scenarios. The Invader tool is intended to be both faster and better than the stock tool.exe that comes with the Halo Editing Kit in regards to compiling cache files. I am working on having AI encounters work just as well as they do in tool.exe, but a lot of this stuff just isn't quite documented. This requires a lot of reverse engineering of the cache files regular tool.exe generates as well as a lot of trial and error in the base game in order to figure things out. Takka, Vaporeon and ST34MF0X like this Share this post Link to post Share on other sites
Posted June 13, 2019 Another update! This time it's a small one, but it could be very important to some people. What is new? I've added a new tool, invader-crc. This can be used to both calculate and modify the Halo-calculated CRC32 of a cache file. This mostly does the same thing the MEK does, but it is its own separate tool. Why use this? Having such a tool is very useful, as you could write a script that can take the CRC32 of a map (or a folder of maps) with this tool, deprotect and extract it using MEK, rebuild it using tool or invader-build, and then use this tool to write the CRC32 that you got before. This could be done in Python or Bash. Added to Halo Custom Edition is the CRC32 calculation that is performed on your maps. You may have noticed Halo Custom Edition, without mods, takes more time to start up, and this is because all of your maps are being CRC32'd. When joining a server, this value is compared against the server's value by using a challenge that can only be correctly answered if you have the right CRC32. This means that if you modify a map, there is a large chance that you will not be able to join servers unless you spoof the CRC32 value afterwards. ST34MF0X and Takka like this Share this post Link to post Share on other sites
Posted June 17, 2019 Here is a small update. I haven't gotten much done (I suppose I fixed an issue with invader-crc when you try to input an invalid CRC32?), but I have found that most of the remaining issues are mostly singleplayer issues or issues that primarily affect singleplayer maps and not any sort of stock multiplayer map. Here is a short list of remaining things to do before version 1.0 is released. Fix detail object collection tags Fix AI and AI encounters Fix the Pillar of Autumn cryo bay door Jason Jones singleplayer maps Generate a scenario tag reference array from scripts Fix some issues with tag indexing This list may expand and shrink as stuff is worked on or more issues are discovered. However, most multiplayer maps should work fine. ST34MF0X, VoidsShadow and Takka like this Share this post Link to post Share on other sites
Posted June 18, 2019 Here's another update! First off, I've Jason Jonesed singleplayer maps. It is possible that there may be more values that will need to be modified, but probably not. Here are the changes that tool.exe does that I know about: Strips cheat weapons and powerups from globals tags (I already did this a long time ago) Sets error angle values on the pistol to 0.2° - 0.4° (decreased from 0.2° - 2.0°) Sets minimum error on the pistol to 0.2° (increased from 0.0°) Sets elite energy shield damage modifier for pistol to 0.8x (decreased from 1.0x) Sets error angle values on the plasma rifle to 0.25° - 2.5° (decreased from 0.5° - 5.0°) Basically, the pistol gets significantly nerfed as it does 20% less damage to elite energy shields. The plasma rifle, on the other hand, gets buffed. Note that these values will be set regardless of what the original value was because this is to get the same output that tool.exe gives. If you do not want your pistol and plasma rifle tags to be modified, you will need to rename them. Next, I've also fixed bump map scaling with shader environment tags that were made exclusively using the Halo Editing Kit and not extracted with Refinery. Lastly, I've fixed a crashing bug for the water tags that came with the Halo Editing Kit. Takka and ST34MF0X like this Share this post Link to post Share on other sites
Posted June 20, 2019 Here is a small update: shader_transparent_generic tags are implemented. These tags do not work in the stock game and only properly work on the Xbox version of the game. However, Invader does build these tags now. You can now use scenario tags with uppercase names. However, the map will be automatically lowercased. Numeric counter limits are now unsigned. ST34MF0X likes this Share this post Link to post Share on other sites
Posted June 23, 2019 Here's an even smaller update: All instances of #pragma once were removed. Basically, I took a Python script and replaced all #pragma once instances into #ifndef/#define/#endif include guards. Here is an example header file, crc32.h (src/crc/crc32.h): #ifndef INVADER__CRC__CRC32_H #define INVADER__CRC__CRC32_H #include <stdint.h> #include <stdlib.h> uint32_t crc32(uint32_t crc, const void *buf, size_t size); #endif The reason for this is because #pragma once is not standards compliant despite being very widely supported, and I have found that some compilers handle it slightly differently from others. The new include guards, however, have well-defined behavior. I've removed a bunch of .hpp #includes from compiled_tags.cpp (src/tag/compiled_tag.cpp), instead opting for external linkage using a macro that uses an extern void function. For most functions for compiling individual tag classes, you'll only have to add these three lines of code into a switch block rather than also having to add an #include for every single compile function. For example: case TagClassInt::TAG_CLASS_BITMAP: // tag class int COMPILE_EXTERN_TAG_FN(compile_bitmap_tag); // replace compiled_bitmap_tag with the function name break; Just make sure your function is in the Invader::HEK namespace and uses the same function signature. For most tags, this will be the case. This does not affect any sort of functionality of Invader. Rather, it's just for maintainability. Therefore, no builds will be released today. You can get the latest build from my previous post. ST34MF0X likes this Share this post Link to post Share on other sites
Posted June 24, 2019 This isn't an update, but I figured it might be useful to discuss version 1.0 if it gets to be that. When I release Invader, you will have two options for obtaining builds: binary and source builds. Binary builds: I will be releasing 64-bit Windows and Linux builds, and they can be run as-is on most 64-bit x86 systems. NOTE: 32-bit is NOT supported. Source builds: You will need CMake and a C++ compiler that can support the C++17 standard. This is a better option for compatibility, and you might be able to get slightly more performance depending on compiler or the flags you use. You will be able to obtain binary builds directly from here, and source code releases will be obtainable from the GitHub Releases page. I expect that most people will choose binary builds. ST34MF0X and Takka like this Share this post Link to post Share on other sites
Posted July 3, 2019 It's been over a week since I last posted an update, but I figured I'll post one since there is something to post! I've been working on a new tool as part of Invader: invader-bitmap. This tool generates bitmap tags out of image files. Presently, its functionality is limited to 2D textures with 32-bit ARGB, no mipmap generation, and it only supports .tif and .png as input. .tga is planned. While it does not yet support generating mipmaps, you can make custom mipmaps. To do this, align your mipmaps on the left edge of the main image. Arrange them in order from largest (top) to smallest (bottom). So, if you have a 256x256 image, you will put the 128x128 image directly below it, 64x64 directly below that, etc. You do not need to go all the way to 1x1, but there cannot be any gaps between mipmaps. For example, a 256x128 mipmap must always come after a 512x256 image and nothing else. Here is an example of custom mipmaps being made: ST34MF0X and Takka like this Share this post Link to post Share on other sites
Posted July 4, 2019 Another update! Mipmaps are now automatically generated. These are generated based on the lowest resolution custom mipmap or the main image if you did not supply any custom mipmaps. Here are the algorithms currently used for mipmaps: Linear (--mipmap-scale linear) - This will interpolate the ARGB channels by averaging each 2x2 square. For most 2D textures, this will be the best option as it effectively provides a 4x antialiased image. This is the default option. Nearest neighbor (--mipmap-scale nearest) - This will pick one pixel from each 2x2 square and move it to the next image. This is fast, but the resulting image is pixelated and aliased. Nearest neighbor alpha (--mipmap-scale nearest-alpha) - Interpolate RGB linearly. Do not interpolate alpha. This is useful for when a precise value is required while having smooth gradients and colors. None (--mipmap-scale none) - Do not generate mipmaps. If you don't need mipmaps, this will save space, but for most bitmaps, this is a bad idea. Next, you can also specify a detail fade factor which will fade mipmaps to gray. This is used for detail maps where you don't want fine details to be extremely visible at oblique angles or far away. Takka, ShikuTeshi, Zatarita and 1 other like this Share this post Link to post Share on other sites