Welcome to Open Carnage

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


  • Content count

  • Joined

  • Last visited

Everything posted by Kavawuvi

  1. Thanks for replying. My problem is that servers that have sightjacking disabled seem to be more prone to cheaters. I can't count how many times I've joined a server where there was someone who was possibly cheating, but because the server blocked sightjacking, I couldn't be certain about it. This is what ultimately resulted in me choosing to not implement whatever HAC2 does or should do to check if sightjacking is blocked. It isn't like I'd be able to trivially do this if I actually wanted to, anyway, because HAC2 is closed source. I think having to play on a server with cheaters because you chose to block one of the most reliable means of detecting cheaters isn't fair for me, either. Sure, I could go to a different server, but the choice of servers with players on them is very limited, and many of them block sightjacking, which is why I made this decision. If you need a bug fixed with HAC2, I recommend talking to msalerno1965 about it. He's the one who currently develops for HAC2. I'm sure he can help you out.
  2. Someone on the Chimera discord asked if Chimera's spectate feature (equivalent to HAC2's sightjacker) would respect SAPP's scrim_mode command which disables sightjacker, and I thought this was an important question. Here was my response: tl;dr - No. Chimera will not prevent you from using any of its features when SAPP's scrim_mode is enabled.
  3. To answer your first question, here is what invader-bitmap does that tool.exe doesn't do: invader-bitmap can use png, bmp, and tga files in addition to tif/tiff invader-bitmap can let you create non-2D texture bitmaps as well as bitmaps with any available data format without you ever having to leave the command line interface invader-bitmap can let you overwrite various other bitmap settings like bump height and mipmap count without you ever having to leave the command line interface invader-bitmap can let you specify any data folder and any tags folder rather than using the current directory invader-bitmap can create bitmaps that exceed 16 MiB As for your other part of the comment, every single parameter used to generate a bitmap tag is stored in the bitmap tag. By doing this, you don't need to re-enter every single parameter every time you re-generate the bitmap tag. This is how tags fundamentally work, and deviating from this puts us in a situation where some settings get saved and some settings don't, negating the point of using tags in the first place. The main goal is that anything made with tool.exe that is re-made in invader-bitmap should function identically. If it doesn't, I consider this a bug that needs fixed. However, the opposite doesn't need to be true: something made with Invader does not necessarily have to work with tool.exe. For example, tool.exe will not process bitmaps that exceed 16 MiB. A 16 MiB limitation more-or-less limits you to these resolutions: With mipmaps: 4096x4096 - DXT1 4096x2048 - DXT3/DXT5 2048x2048 - 16-bit 2048x1024 - 32-bit Without mipmaps: 8192x4096 - DXT1 4096x4096 - DXT3/DXT5 4096x2048 - 16-bit 2048x2048 - 32-bit However, invader-bitmap doesn't have such arbitrary limits. You can make 4096x4096 32-bit bitmaps, and Invader won't have any issue with them provided they are otherwise valid.
  4. Yes. Using your own text editor whenever possible usually has better results. What I'd do is load SAPP once without any configuration to let it generate the text file. Then I'd use a program like Notepad++ or Visual Studio Code and open the file. These text editors will typically automatically detect the format of the text file as they will detect the BOM SAPP will put at the start of the text file. Make your changes, save, and upload. If you run into any problems using FTP, then try sending the file in binary mode.
  5. It wouldn't save in the tag, though. The tag's enums for sprite budget allow for only 32x32, 64x64, 128x128, 256x256, 512x512. Therefore you'd have to pass this value every time.
  6. If you're referring to this Besides future versions of Chimera as well as Dark Circlet, nothing supported it. Also, MosesofEgypt wasn't going to add a trivial way to switch between using Xbox P8 and Stubbs P8, thus there was no good way of testing the P8 bitmaps to make sure they worked as expected besides using the out-of-the-way bitmap extractor in the MEK. If you're referring to this I consider anything that negatively affects existing Bungie assets to be a bug, since it basically made it so it was impossible to recreate those bitmaps. If you're referring to this I felt there wasn't any need to have these settings as an image editor can do the job a lot better than Invader could, but anything that had it set via Guerilla or past versions of invader-bitmap would still work as expected. If you're referring to this Sorry, but I cannot rely on the sprite spacing value in the tag to be accurate as tool.exe only writes to it, not read it. Also, Guerilla doesn't let you edit it, either. Lastly, if you make a 2D texture in tool.exe and change it in Guerilla to be a sprite sheet and this value is still not set (0), it'll result in a sprite sheet with 0 spacing, causing bleeding. There wasn't any good way to get around this. If you're referring to this I think that modifying existing cache files should be avoided whenever possible, and this is forging a CRC would do. It is far better to forge the CRC when building the map. If you absolutely need to forge an existing map's CRC32 and invader-build isn't suitable to your purposes, then Refinery is better for this stuff.
  7. UCS-2 little endian BOM. Basically little endian UTF-16 with a BOM but it's fixed at 16-bit width where UTF-16 is variable-length if you're using any special characters. If you just use the basic ASCII characters, then they're basically the same.
  8. I made some changes since Invader 0.10.0. Normally I would've waited until October or so to post these, but they're breaking changes. Here's 0.12.0. Added invader-bitmap: Added --filter-blur (blur filter size); this will blur the bitmap using a filter invader-bitmap: Added --filter-sharpen (sharpen amount); this will sharpen the bitmap using a filter Changed invader-bitmap: Switched to the Xbox P8 palette. This palette is probably worse, but the original Halo Editing Kit as well as Mozzarilla support it, so it's easier to use. invader-bitmap: Now stores dithering and mipmapping settings in the tag Modified the project license terms to strictly GPL version 3 Fixed invader-bitmap: Fixed blurring and sharpening values in the tag not being retained tl;dr - P8 uses the Halo Xbox palette instead of the Stubbs palette now. Also, the "or later" clause has been removed from the license from Invader. Update: I removed --mipmap-blur and --mipmap-sharpen and replaced them with --filter-blur and --filter-sharpen, and they now affect the bitmap rather than the mipmaps. I acknowledge that this is broken, buggy behavior as this is not at all what the descriptions in Guerilla say, but Bungie's assets relied on this behavior. This also does mean that if you extract a bitmap and you intend to remake it using invader-bitmap or tool.exe, you should change these values to 0 before doing this, as this cannot be undone unless you have the source image.
  9. What a classic! I'll add another five tickets to the prize pot if anyone wants to take a crack at this within the next raffle period.
  10. I think this one is certainly doable. Double, but it would require directly modifying the infection gametype script or making a new one from scratch that supported multiple rounds.
  11. OK! Done.
  12. With invader-bitmap now supporting every bitmap format, I felt it was worth writing a small guide on the different bitmap formats. If you want a quick technical overview as well as some tips, I recommend looking at Shelly's spreadsheet, instead: https://docs.google.com/spreadsheets/d/18ZBzUGmH8F3bqB2-0dPa9nnOtVl_liT1cnNLZaHn92c/edit?usp=sharing Meet the Formats When making a .bitmap tag, there are a few types of bitmap formats you can choose in Guerilla/Mozzarilla: "compressed with color-key transparency" or "dxt1" in invader-bitmap "compressed with explicit alpha" or "dxt3" in invader-bitmap "compressed with interpolated alpha" or "dxt5" in invader-bitmap "16-bit color" or "16-bit" in invader-bitmap "32-bit color" or "32-bit" in invader-bitmap "monochrome" (same name in invader-bitmap) There is a seventh option, but it it is only available for height maps if "disable height map compression" is not checked. This is called "P8 bump" which I'll talk about in a bit. For now, I'm going to talk about the file size limits as well as the compressed and uncompressed formats you can select manually. File Size Limits There are limitations when it comes to file size: Stock, unpatched tool.exe, limits to 384 MiB, while also resulting in issues with loading the map in Halo once you reach 128 MiB. Invader or a patched tool.exe is required for maps that exceed these limits. Stock, unpatched tool.exe cannot process textures larger than 16 MiB. Invader or a patched tool.exe is required for maps that exceed this limit. Halo is limited to 2 GiB of virtual memory. Even if LAA patched, Halo will still be limited due to being a 32-bit process. The primary reason for choosing formats is for space considerations. If you use 32-bit color for every bitmap, you will get the best quality, but the file size may be larger. If you use DXT for every bitmap, you will get the best file sizes but worse quality bitmaps. Uncompressed formats These formats all use explicit alpha and RGB. By explicit, I mean that each pixel's red/green/blue/alpha values are individually defined in the texture rather than being inferred from a set of interpolated colors/alphas. 32-bit This format is a no compromise format. You get the best image quality, but you also get the largest images due to each pixel taking up 32 bits. As a result, many of the stock textures are not 32-bit, and the game looks much better when re-making them in 32-bit. To put it in perspective, a 2048x2048 bitmap without mipmaps is 16 MiB - the maximum size bitmap tool.exe supports. With mipmaps, it exceeds that at over 21 MiB. This is the default format for newly created bitmaps in invader-bitmap. Pros Best image quality Explicit alpha Explicit RGB Cons Highest file size Environment maps require a mod (i.e. Chimera 1.0) to fix a bug of Halo making explosions blue Subformats A8R8G8B8 - 32-bit with alpha - This is used if not all pixels have 100% alpha. X8R8G8B8 - 32-bit without alpha - This is used if all pixels have 100% alpha, thus the alpha channel is ignored. tool.exe will also choose this if all pixels have 0% alpha, so be careful if you use tool.exe for 32-bit color. 16-bit This format is half the size of 32-bit, but it also has less color depth. Having an alpha channel further reduces color depth, with 1-bit alpha reducing color depth significantly less than 4-bit alpha. So, as a result, you can get banding with gradients. This banding can be improved with dithering, however. Pros Half the size of 32-bit Explicit alpha Explicit RGB Cons Somewhat reduced color depth Banding in gradients Subformats R5G6B5 - 16-bit without alpha - This is used if not all pixels have 100% alpha. A1R5G5B5 - 16-bit with 1-bit alpha - This is used if all pixels are either 100% alpha or 0% alpha. The green channel has half the color depth vs. R5G6B5. A4R4G4B4 - 16-bit with 4-bit alpha - This is used if there are pixels that don't have 100% alpha or 0% alpha. All channels have half the color depth vs. A1R5G5B5, with green having a quarter of the color depth vs. R5G6B5. Monochrome This format can be either 8-bit or 16-bit. If only alpha is defined and each pixel has an intensity of 100%, or only intensity is defined and each pixel has an alpha of 100%, then it is 8-bit. Otherwise, if intensity and alpha are separately defined, it's 16-bit. This is perfect for things like HUDs and HUD icons, as it results in no loss in quality. By intensity, I mean red = green = blue = intensity, thus it is grayscale. Sadly, this format does not work with stock Halo PC, requiring a mod (i.e. Chimera). Pros No loss in image quality for grayscale input Half the size of 32-bit OR half the size of 16-bit Explicit alpha Explicit RGB Cons Does not work with Halo PC without a mod (i.e. Chimera 1.0) Subformats A8 - 8-bit alpha - This is used if all pixels have 100% intensity. Y8 - 8-bit intensity - This is used if all pixels have 100% alpha. Alpha equals 100%. A8Y8 - 8-bit alpha + 8-bit intensity - This is used if pixels have varying alpha AND intensity. Compressed formats The DXTn formats are compressed in 4x4 blocks. These 4x4 blocks each have two 16-bit (R5G6B5) colors chosen by the compressor, and these colors are interpolated at runtime. As a result, different implementations can have slightly different results, and there is some loss in quality. Note that all of these formats store color exactly the same. Having a better compressor can result in better quality bitmaps (or more accurately, less reduced quality bitmaps), but it will almost always have some sort of loss in quality - often times significant. DXT1 This format stores only color and no alpha, instead being color-keyed. As a result, it is the smallest format, at 64 bits per block (4 bits per pixel). Since these formats all store color the same, if you use DXT3 or DXT5 and you have no alpha channel, DXT1 will be used, instead, to save space. This is the default format for newly created bitmaps with tool.exe. Pros 1/4th the size of 16-bit Cons No alpha channel; alpha is color-keyed instead Can have significant loss in quality Can have banding between blocks Cannot go below 4x4 or have mipmaps less than 4x4 resolution Less color depth than 32-bit (not including the interpolated colors which depends on implementation) DXT3 This format stores color as well as explicitly storing alpha in 4-bits per pixel, thus making it 128 bits per block (8 bits per pixel). Since alpha is explicit, shapes are preserved, making it arguably better than DXT5 for things like HUD elements. Pros Half the size of 16-bit Explicit alpha Cons Can have RGB banding between blocks Banding in alpha gradients Cannot go below 4x4 or have mipmaps less than 4x4 resolution Less color depth than 32-bit (not including the interpolated colors which depends on implementation) DXT5 This format interpolates both color and alpha. It is also 128 bits per block (8 bits per pixel). Since alpha is interpolated, gradients won't suffer from banding within blocks, but they may have fuzzier outlines. Pros Half the size of 16-bit Cons Can have banding between blocks Cannot go below 4x4 or have mipmaps less than 4x4 resolution Less color depth than 32-bit (not including the interpolated colors which depends on implementation) P8 Rather than compressing in 4x4 blocks, the image is converted into a 256-color indexed bitmap suitable for height maps but not really anything else. tool.exe and invader-bitmap use different palettes, as invader-bitmap uses the more superior Stubbs palette. Pros Half the size of 16-bit Each pixel explicitly chooses a color from a palette Cons Does not work with Halo PC without a mod (i.e. Chimera 1.0) Significant banding in gradients Color palette depends on implementation What is the best format for me? If you are not concerned about size, 32-bit is the way to go. It provides the best quality, being noticeably better than any of the other formats. 16-bit provides a nice middle ground, especially if you use dithering. DXT1/3/5, on the other hand, are for if/when you want to keep file size down. If you use this format, it is recommended you use the best compressor possible so you have the least amount of quality reduced. The compressor invader-bitmap uses is better than tool.exe's compressor, but it isn't as good as Nvidia's compressor. If you want your map to work with stock Halo PC, then you obviously cannot use P8 or monochrome. This is a shame, because monochrome is, objectively, the best format for things like HUDs as it provides no quality loss, while, although P8 isn't perfect, it's fine for bumpmaps.
  13. Invader 0.10.0 is now out! invader-bitmap has been massively overhauled. with supports for sprites, 3D textures, cubemaps, interface bitmaps, height maps, as well as the ability to make P8 bitmaps. Detail maps and 2D textures are also better, too. Also, dithering has been improved and is now available for 16-bit and P8 bitmaps. You can read the entire changelog on GitHub: https://github.com/Kavawuvi/Invader/blob/master/CHANGELOG.md Here are all of the changes since 0.7.2: Added A changelog is now used to track changes invader-bitmap: Added --usage (default, bumpmap, and detail) and --bump-height parameters invader-bitmap: Added support for bitmaps with color plate data invader-bitmap: Added support for cubemaps, sprites, 3D textures, and interface bitmaps invader-bitmap: Added the ability to specify custom spacing for sprites invader-bitmap: Added the ability to specify bitmap type in the command-line invader-bitmap: Added p8-bump support based on Stubbs the Zombie's palette Changed invader-bitmap: Spacing now attempts to sort both vertical and horizontal to see if sprites will fit in a sprite sheet invader-bitmap: Changed how spacing is stored in the bitmap to effectively match how tool.exe calculates its spacing invader-bitmap: Double multiply sprites now simply replaces the pixel like tool.exe rather than alpha blend into gray invader-bitmap: Usage and the p8 compression flag are now preserved invader-bitmap: Height maps now generate bump maps similar to tool.exe invader-bitmap: --detail-fade replaces --mipmap-fade and is now only usable on detail maps. invader-bitmap: --detail-fade now approximately matches how tool.exe does fade to gray invader-bitmap: Dithering is now available for 16-bit and palettized bitmaps invader-bitmap: Dithering now takes an argument: `<channels>`. Channels are letters (i.e. `argb`). invader-bitmap: Sprite spacing now affects the maximum number of mipmaps you can have with sprites invader-bitmap: Non-divisible by 4 bitmaps are no longer compressed invader-bitmap: Registration point calculation has been changed to better match tool.exe's calculations invader-bitmap: Alpha is now ignored when checking if a pixel is blue, magenta, or cyan Fixed invader-build: Fixed an issue with certain sounds not being played correctly, such as the "Come on! We've got to get the hell out of here!" dialogue at the start of the game invader-string: Fixed cutting the last character of every string Removed invader-bitmap: Removed being able to specify negative mipmaps to remove mipmaps As always, you can get builds from https://invader.opencarnage.net/builds/nightly/download-latest.html and https://invader.opencarnage.net/builds/nightly/
  14. blue-gen is something I quickly whipped up on request, originally being a Linux alternative to halospritedoer written in C. By request, it has been released for Windows, as well. What it does is generate TIFF sprite sheets from BMP/PNG/TGA/TIFF images to be used as input for invader-bitmap OR tool.exe. By default, it uses blue and magenta for the color plate data, but if it detects that you are using either color for your bitmaps, it will choose a different color for the color plate. There are two programs: blue-gen and Blue Genstone. blue-gen is a command-line program that does all of the work (see the readme for the exact usage). Blue Genstone is a graphical user interface for blue-gen. You can use blue-gen by itself, but if you use Blue Genstone, ensure that blue-gen as well as any dependencies (e.g. DLL files) are the same folder. Here's the command-line program in action: I also made a GUI for it as a proof of concept: And here's the Windows version which has been slightly updated: Download (Windows 64-bit): blue-genstone-r2.7z Source code: https://github.com/Kavawuvi/blue-gen
  15. As of Invader 0.8.0, invader-bitmap can now make sprites, cubemaps, 3D textures, and interface bitmaps. I've updated the original post with this. We're a little over halfway there for a full open source HEK replacement.
  16. Good job! While I probably wouldn't use this on my own servers (I feel it is part of the core Halo experience even if it is technically a glitch/bug), I can see why people wouldn't want it. Being able to reload a weapon without holding it is pretty stupid.
  17. The map parser has moved to Invader. Check out Invader here: There are a few differences between the original plans of TiaraCE's map parser and Invader that are worth noting: Invader is licensed under the GNU General Public License version 3. Invader satisfies a larger set of use cases beyond simply parsing maps including compiling cache files. Invader does not parse Xbox maps. Invader does not target Visual C++ with Windows. Instead it uses MinGW. Invader does not require macOS compatibility. Invader does not use information from Sparky's plugins. Invader's tag definitions are more complete than either Sparky's plugins or Guerilla since Invader must build maps. Invader uses the C++17 standard, not C++11. Old post (for historical reasons):
  18. My efforts towards this map parser have gone towards Invader. I'll probably go update the original post to indicate this.
  19. Praise is nice as an ego boost, but honestly, all I want people to do is test my stuff. I do get bug reports from people every few days ago, but it's rarely on here. Also, while it is true that I don't upload builds anywhere else, I've provided a means for people to get the latest build (which is automatically uploaded every day or so) without having to compile it themselves. Therefore, it is unnecessary make a reply to this topic for new builds. Before I started using this system, I was able to track how many people downloaded a certain build, and I found that nearly every build I posted had 0 downloads. This meant that nobody was testing the builds I was posting. Has that suddenly changed for nightly builds? Maybe, but it's unlikely. Each of these updates takes time to write. I have to go through the past source commits as well as look at issues that were resolved. Then I have to use that aggregate information to write a forum post in a way that non-programmers will understand. I really don't want to commit so much time into writing so many posts, as it seems like they just go nowhere. I'm still going to post updates for those who are interested in the project, but they're going to be more condensed and much less frequent.
  20. I haven't posted a full update in a couple days, so I guess I'll do that. I've posted Invader 0.7.2. Here are the changes since 0.5.0: An issue with invader-bitmap was fixed. invader-string has been started. Currently it only does string_list and unicode_string_list tags. HUD message text tags are not implemented yet. Some more hidden values have been calculated for machines. This probably won't fix anything, but for the sake of accuracy, I did it. When building maps that potentially use indexed tags (loc.map), invader-build will now compare the string data rather than comparing file size to determine if it matches what is in loc.map. invader-build no longer allows you to go beyond the number of bitmaps/sounds/loc tags used in stock bitmaps.map, sounds.map, or loc.map when building multiplayer maps, nor will it allow you to go beyond the Invader-extended tag set when building singleplayer/ui maps. This is to discourage people from creating a situation where you would need different, custom resource maps for different maps in your maps folder. This is also to discourage people from creating multiplayer maps that require custom resource maps - something which could theoretically happen accidentally when using a map downloader. Due to the lack of interest in Invader/this topic on this site, I'm not going to be posting updates here as often. Sorry! Continue to check nightly builds and the GitHub repository for updates, though.
  22. I fixed a bug with invader-bitmap. It wasn't setting the pixel offset value correctly.
  23. That doesn't help me. You need to explain what a timer/"partner respawn's in" is, and you'll need to explain what you mean by it not being steady. I can't help if I don't know what you're talking about.