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

Kavawuvi

Administrator
  • Content count

    4,507
  • Joined

  • Last visited

Everything posted by Kavawuvi

  1. I've updated the nightly build of Invader with some fixes to the definitions courtesy of @Vaporeon as well as some readme changes.
  2. Invader is a work-in-progress, open source, cross-platform toolkit for creating Halo: Combat Evolved maps. There are a number of tools that come with Invader: invader-archive - CLI program for creating archives of all of the tags required to build cache files invader-bitmap - CLI program for generating bitmap tags invader-bludgeon - CLI program for backhanding uncooperative tags invader-build - CLI program for building cache files from scenario tags invader-compress - CLI program for compressing cache files invader-convert - CLI program for converting between different tag types - highly useful for Xbox map porting invader-dependency - CLI program for listing the dependencies of a given tag OR the tags that depend on a given tag invader-edit-qt - GUI program for editing tags invader-extract - CLI program for extracting tags from a map invader-font - CLI program for generating font tags invader-index - CLI program for generating a list of all of the tags in a cache file or resource map (useful for invader-bitmap) invader-info - CLI program for getting metadata of a cache file invader-model - CLI program for creating gbxmodel/model tags invader-recover - CLI program for recovering source data from tags invader-refactor - CLI program for renaming tags (or directories of tags) without breaking references invader-resource - CLI program for generating resource map files (i.e. bitmaps.map, sounds.map, loc.map) invader-sound - CLI program for generating sound tags Six Shooter (Windows only) - GUI frontend for Invader ... and (hopefully) more programs to come! You may be wondering, why am I taking time to replace the Halo Editing Kit, something that supposedly already works fine? I'm glad you asked (or I asked?)! The Halo Editing Kit... ...is closed source. This means that you cannot make changes to it or add functionality without resorting to modifying the .exe file directly. Also, information has been obfuscated away through compilation. Invader is open source. ...is unsupported. Since it's closed source, you cannot rely on the developers to issue any updates to fix problems with the program. If they never update it, then it is the final version you get. An ideal program should never need updated, but the HEK is very far from ideal. Because Invader is open source, anyone may fork and support Invader at any time. ...is limited. Since it's closed source, you have to modify the .exe file directly in order to make changes to it. If you don't, you're limited to building 384 MiB cache files. Also, singleplayer maps are tied to the resource maps you built them with, thus users must have the same exact bitmaps.map and sounds.map you used to ensure the correct assets are displayed/played. Invader does away with most of Halo's arbitrary limits, even the 384 MiB cache file size limit (it's 4 GiB now!). ...was made for older PCs. As robust as Windows's backwards compatibility may be, even it has limitations, especially with Win32 GUI programs like Guerilla and Sapien. Invader runs natively on 64-bit x86-based PCs. ...is slow. This is due to thousands of unnecessary checks as well as the program, itself, not being compiled with optimizations. Building all stock multiplayer maps with tool.exe takes over 4x as long as Invader. ...only works on Windows. Not everyone uses Windows, and Wine compatibility on Linux is, at best, a mixed bag especially in regards to the GUI-based applications Sapien and Guerilla. Invader natively runs on both Windows and Linux without having to worry about Wine. tl;dr: You can't guarantee the Halo Editing Kit will continue to work indefinitely, and it doesn't meet all of our needs anymore. Invader is here to fix that. I recommend reading this post for more information on why it is important that the Halo Editing Kit should be replaced: Site: https://invader.opencarnage.net/ Source code: https://github.com/SnowyMouse/invader Builds: https://invader.opencarnage.net/builds/nightly/download-latest.html Original version of this post (for posterity):
  3. I'm currently in the process of redoing Invader's C++ code generator. This should make Invader compile considerably faster and make it easier to maintain. I'm also working on a script compiler and a few other things to help with MCC support. I'm hoping this will be useful! Unfortunately, the amount of time I have to work on this stuff might be significantly reduced soon as I might be finally finding myself in a programming job sometime soon! I should be able to continue working on stuff on my free time, but as I do a lot of programming by myself, updates to Invader and Chimera will be a bit slower. Sorry, I gotta eat.
  4. Sheesh. If you're going to nip it in the butt, at least take me out to dinner, first. Anyway, I think the wrong one was the first version I heard, but I later looked it up and found out the right version.
  5. This song... um... is an experience. (I love it)
  6. I'm working on a new map format that is intended to solve a few problems: Halo's tag space limit is only 23 MiB Halo is fragmented into different versions, with what seems like around 25% of the player base on the retail Halo PC version and the rest on Custom Edition Halo has some tag data features locked away that requires mods to fix, namely PCM audio and 32-bit environment textures Halo has an issue where indexed tags count towards the limit, resulting in potential crashing when using non-English loc.map files from certain languages of the game if you are close to the tag space limit when building for English The new format we're coming up with should aim to alleviate these issues. These are the following features being devised: Extended tag space (23 MiB ---> 48 MiB or 64 MiB depending on what we can get Halo to load successfully without an LAA patch through further testing) In all honestly, unless you have an excessively large BSP, it's unlikely that most maps will exceed 48 MiB of tag space All clients that load these maps support PCM audio and 32-bit environment map textures, giving you the option for the best quality textures and audio All clients that load these maps will also support indexed tags properly without it counting against the tag space limit Maps will work on both demo and full version (including both the retail Halo PC release and Custom Edition), with two separate "blobs" for each Each tag "blob" shares raw data and model data, so only BSPs and tag data have to be different between blobs This means tag data will be twice as large, but zstandard should mostly alleviate this issue If loaded on Custom Edition, ting volume and stun values are automatically fixed All stock multiplayer maps are indexed and CRC32'd, ensuring they will work over the Internet if joining a server provided that all tags are present and accounted for As for enabling this, you will need to ensure you have Custom Edition resource maps present. If you are on Halo Custom Edition, you already have that. If you are on the retail version of the game or the demo version, refer to this topic: I wanted to put this here before I started releasing tools that actually let you build these maps. I don't imagine I'll actually receive very much input about this, but I figured it was worth a try. It's worth noting that it isn't difficult to implement these things. Other mods are welcome to implement these changes, and if I do finish this, I'll document as much as I can about it.
  7. MCC is 50% off again until July 8th. You can buy CEA by itself for $4.99 - https://store.steampowered.com/app/1064221/Halo_Combat_Evolved_Anniversary/
  8. The only thing that surprised me was that they released a complete set of tags. The original HEK was intended to be multiplayer only as they only released enough tags to build multiplayer maps, where this is clearly intended to be used for any kind of map. Standalone is nice as it is a debug build of the game, thus you may find more useful error reporting in some cases. The HEK did not have this (except through Sapien), so this may be useful. Unfortunately, the audio is totally hosed, so it's not a complete way to test your map.
  9. A lot of work with Invader has been done over the past month. Support for the upcoming MCC: CEA format Changes to invader-model (it only uses the legacy method - not the new method I added in the previous post) Support for global_scripts extraction Improvements to usability, such as Find/Save As in invader-edit-qt auto-expanding all directories to the tag's current directory Fixes and more fixes Check the changelog here: https://github.com/SnowyMouse/invader/blob/master/CHANGELOG.md
  10. I'm not sure if the tools they'll give us will be that much better than the tools we have right now... if at all. We're already able to make custom maps that target CEA specifically via Invader. This, to me, just means CEA is now actually supporting custom maps. Which is really all we needed in the end, of course. I suppose if they give us a means to play with the Saber3D stuff, that may actually be pretty cool for campaign stuff. We don’t know much though.
  11. I like science fiction! My favorites for that are The Expanse (2015-), Battlestar Galactica (2004-2009), and Star Trek: Deep Space Nine (1993-1999). The Expanse is currently ongoing, and it's probably the finest examples of science fiction drama I have ever seen. And that's saying something, because Battlestar Galactica was REALLY well written - certainly just as good in quality. Star Trek: Deep Space Nine has a well developed universe and a pretty good overall plot (which really isn't surprising since Ronald D. Moore, one of Deep Space Nine's main writers, later created the 2004 Battlestar Galactica TV series). It was also quite dark. However, unlike BSG and The Expanse, despite its writing being the best of Star Trek, there were less stakes for most of the main characters in Star Trek: Deep Space Nine, so it kinda fell short as a drama. This is common in Star Trek, though we do lose main characters in this series (though they die in the most anti-climactic way). Basically, in Star Trek, if a main character is mortally wounded, you can count on them pulling some sort of bullshit out of a hat to make them survive despite impossible odds... unless the writers specifically want to kill them off in which case they just die. This has been the case in every Star Trek series. Here's an example of what I mean. Conversely, Battlestar Galactica doesn't consider any character to be invincible unless they're a Cylon within range of a resurrection ship - something well established and consistent in the universe, and this fact only helps the antagonists of the show, thus the main characters are even more vulnerable. The Expanse does not even try to raise the dead, taking an even more realistic approach. So realistic that it happily drives home the fact that literally anyone can die in the show, including several main characters. In fact, the stakes are so high that people who did not actually die in the books - the source material - actually died in the show. The writers are utterly ruthless, and I love it.
  12. This is a REALLY good cover. Wow.
  13. After giving the Huion H610 V2 a rather poor score of 2/5 after I found it was horrible to use as a left handed person after it died a painful death, things were bleak. Would I be able to draw ever again? Well, after I bought the Wacom Intuos M CTL6100WL for the low, low price of $200 (ouch), it was time to put this to the test. This tablet comes with a pen that's wirelessly powered, and this tablet has a small sleeve on the top to hold the pen when not in use. However, unlike the Huion H610, it only has four buttons, not eight. Except, also unlike the Huion H610, the buttons are on the top, not on the left side. That means I can use the tablet without rotating it! It also has the USB port on the top instead of the side - far away from my hand. Lastly, it supports Bluetooth connectivity, but you can use the USB cable for devices that do not support Bluetooth, as it doubles as a data cable. Size-wise, it's a bit smaller, but really, it's still fine for a 2560x1440 display. Is it a good drawing tablet? Heck yes. Let's begin. Setup - 5/5 The software for the tablet was easy to set up on Windows. Linux, on the other hand, natively supported it without any additional installation. Just plug it in, and most Linux distributions (even Arch Linux) will support it provided they have a recent version of Linux. Configuring it is also pretty easy. On Windows, you can use the software to configure which button does what. On Linux, you can use xsetwacom to configure things. Usability - 5/5 It works and using it is great whether you are left or right handed. Because the buttons are on the top, you can use your non-dominant hand to press those while using your dominant hand for drawing. Left handed users will get the same exact experience as right handed users. Good for me! Durability - 3/5 This thing is pretty durable. Except there is one thing that really bothers me: the paper surface. Continuous usage of the tablet will wear this away very quickly, and it will wear away the nib on your pen, resulting in a smooth surface (or part of it being smooth and the unused part not being papery). Also, the nibs on the pen wear away when used on the papery surface, where once it's smooth, they don't wear away nearly as much. It comes with three spare nibs for what it's worth, but you're going to be using two or three of the nibs before the surface is so smooth that it no longer wears down the last nib. This isn't a huge problem, but I'd much rather the tablet just be smooth rather than having it eventually wear away to a smooth surface, as it'd provide some consistency here. Value - 4/5 For $200, there are tablets with more buttons. There are also bigger tablets. And there are tablets that do not have the aforementioned problem with the surface. The Huion H610 I had before was all of these, and it's only $60. Overall - 4/5 Overall, this is a good tablet. This tablet is extremely easy to use on Linux (and Windows of course!), and it provides a good, overall experience. It's not flawless, however! Were it not for the issue I had with the surface being inconsistent with usage (and my pen nibs being worn away within weeks -.-), this would be very much a 5/5 review. But the Huion H610 was also well on its way to being a 4/5 or 5/5, were it not for the fact that I am left-handed and my experience was awful (and, of course, that it died one year later). The Wacom Intuos M CTL6100WL, however, is still very much alive and works fine, especially for left-handed artists or otherwise left handed people who just enjoy drawing (like myself)! Pros: Ambidextrous button placement Decently sized drawing area Easy to set up on Linux Works well with drawing software like Krita Wireless Bluetooth support Cons: The drawing surface changes over time Pen nibs wear away pretty quickly (until the drawing surface is smooth)
  14. I've written a list of offsets that I use for my own applications and scripts that may be useful for others. This is considerably more information than what was available in the Eschaton era and should be enough to write a basic parser. However, it does not include any tag data, so you will need to refer to Eschaton plugins for this information. This includes information on both cache files and resource maps for both the retail version of the game and Custom Edition and a small amount of information for the Xbox version of the game. More information may be added in a future date. Source code: https://gist.github.com/SnowyMouse/39168bddd597549038a35d78aee39513 Download (PDF): halo-map-structure-2.1.2.pdf Older versions:
  15. I've updated the PDF! There are a few fixes to some of the information. A few typos here and there were also fixed. After getting some feedback on Discord from a few people, I also added some more information regarding the resource map structure as well as Xbox Halo's cache partition. A few people weren't very sure about this concept, so I made sure to give it a more thorough explanation.
  16. If you mean the servers physically running on a phone, unfortunately, there's no source code release of the game, nor is there any current reverse engineered version of the game or even a decomp, so you'd have to go through the daunting effort of reverse engineering the game or finding out how to run the binaries on a phone. If you go the binary route, hardly any phones run Windows. Most run Android or iOS, so you'd have to use something like Wine as a wrapper so the binaries can run. Also, most phones use an ARM CPU, where Halo is compiled for x86, so not only would you be wrapping the binary, you'd likely have to emulate it, too. Doing that and having it run with playable performance is not something that can be done easily especially given how low powered many phones are. And of course, Halo's dedicated server can be somewhat CPU intensive which may eat at your battery life a bit more than you'd expect. This is a cool idea, of course! Implementing it would be pretty hard.
  17. I've been using this monitor for about a week now, so it's time to write a review on it! For reference, this monitor replaces my older Acer G257HU smidpx 25" monitor which I reviewed here: What's good about it? This monitor has a 2560x1440 (quad HD) 144 Hz nano IPS display. Nano IPS is a better version of IPS which cover more than the sRGB color space. You can read a whole article on it on DisplayNinja or ViewSonic, but in a nutshell, it's IPS but better. Anyway, like most IPS displays, the viewing angles are really good. The gray-to-grey (G2G) response time is also pretty low. I wouldn't say it's 1 ms as advertised, though. Sure, you can set the Response Time to "Faster" and you'll technically get an average of 1 ms response time, but the result is tons of inverse ghosting artifacts and trailing due to overshoot, which kind of defeats the point of getting a low response time (less ghosting!). Thankfully, this is not the default setting. In fact, the default settings are pretty good - MUCH better than my previous Acer monitor which maxed out the overdrive setting by default, resulting in LOTS of the aforementioned artifacts. I primarily do programming, so 1440p, while not necessarily required, is extremely useful for what I do, and going back to 1080p would've been a far bigger downgrade than the upgrade of going to 144 Hz. I also play video games, though, and I wanted to try something better than 60 Hz. It also support for variable refresh rate (VRR). This results in the monitor adapting to the frame rate of the game - basically a reverse form of vSync with none of the input lag. The on-screen display controls for the monitor is also pretty good (it uses just one button under the display!). It lets you configure a wide variety of settings, including two custom profiles and a few built-in profiles for various use cases (FPS, RTS, sRGB, "reading") as well as two other settings "HDR Effect" and "Vivid". The custom profiles let you configure most of the settings, while the other ones only let you configure brightness and contrast. sRGB mode is nice for viewing content, and the two custom profiles are really useful, but I'm not sure what the point of the other settings are. The stand is also pretty good, too. You can pivot, tilt, and raise/lower the monitor (but not rotate - you have to rotate the stand, itself). And if you don't care, you can use your own VESA mount, instead. Lastly, the monitor is not terribly expensive. I got mine for about $480 (after tax) which really isn't too bad considering it's a 144 Hz, 1440p, IPS display. Can I use Adaptive-Sync or FreeSync with my PC or console? To use VRR with this monitor on a PC, you need an AMD (GCN 2.0 or newer), Nvidia (1000 series or newer), or Intel (11th gen or newer) GPU to take advantage of this feature. Older Intel, Nvidia, and AMD GPUs do not support the standard. If you're on a console, currently only Xbox One X/S and Xbox Series X/S will work via FreeSync. The Nintendo Switch does not support either standard (it does not use DisplayPort and it uses an Nvidia chipset), but the PlayStation 5 is planned to get support for this in a future update. Also, you cannot use VESA Adaptive-Sync over HDMI. Only DisplayPort actually officially supports variable refresh rate, where with HDMI 2.0, you have to use the proprietary FreeSync standard (only HDMI 2.1 or newer natively supports Variable Refresh Rate - this monitor only has 2.0 ports though!). So, depending on your device (basically any device with a non-AMD GPU), you may have to use DisplayPort to get this feature. And, of course, the game needs to actually run below the refresh rate of the monitor. If it runs at or above the refresh rate, you'll get tearing as usual. At 144 Hz, it's probably not going to be that bad (assuming you even notice it), but it is something to watch out for. Is 144 Hz so much better than 60 Hz? Let me start by saying the difference between 60 Hz and 144 Hz was immediately noticeable. Merely moving the cursor on my desktop was immediately better. Scrolling on pages looks really smooth, too. And, of course, gaming, itself, looked so much better. Of course, I wanted to know if this was placebo! After playing on 144 Hz for a while, I did a blind test where I did not know the refresh rate. To do this, I wrote a Bash script that changed my refresh rate to randomly either 144 Hz or 60 Hz without telling me which one, and then ask me what I thought the refresh rate was. I found I could, indeed, reliably tell the difference between 144 Hz and 60 Hz, even though I had not used this monitor for more than a few hours. But does 144 Hz look twice as good as 60 Hz? After all, 144 is more than twice as high as 60. Personally, I think it's a matter of opinion depending on what you play. First, let's invert the numbers to convert refresh per second to seconds per refresh. 144 Hz is 6.944 milliseconds per refresh 75 Hz is 13.333 milliseconds per refresh, or 6.389 ms worse than 144 Hz. 60 Hz is 16.667 milliseconds per refresh, or 9.722 ms worse than 144 Hz. 30 Hz is 33.333 milliseconds per refresh, or 16.667 ms worse than 60 Hz. While it refreshes more than twice as fast, going from 60 Hz to 144 Hz is really only 58% as much of an improvement as going from 30 Hz to 60 Hz - something mostly seen on consoles. However, smoothness isn't the only improvement of going to a higher refresh rate. Because more information is being presented to you ever second, that also means the time between button input and response is effectively improved. Therefore, 144 Hz not only looks better, but games play better, too. What's not so good? My main gripe is that there is only one DisplayPort port while there are two HDMI ports. This doesn't seem like a very bad thing until you consider the following: You can only get DisplayPort Adaptive-Sync if you use... well... DisplayPort. As stated earlier, HDMI 2.0 does not natively support this technology, thus you have to use a proprietary standard like FreeSync if you want VRR over HDMI, where anything else would have to use DisplayPort. Also, if you use the HDMI port and have FreeSync enabled, the refresh rate is capped at 100 Hz when at 2560x1440 and 120 Hz when at 1920x1080. If I can only fully take advantage of the monitor with ONE of the ports, then the other ports are mostly pointless if you care about variable refresh rate. A second DisplayPort port would've been really nice. So, yeah, I ended up disabling FreeSync on the HDMI ports and just used Adaptive-Sync on the DisplayPort input. The monitor, itself, has no speakers, which, itself, isn't a problem since most monitors' built-in speakers are terrible, anyway. However, the audio quality from the headphone jack on this monitor isn't great. It's noticeably worse than motherboard audio. Also, the black aesthetic of the monitor is really good, but the slight "gamer" red accents on the stand and back of the monitor, while not garrish, feel a bit unnecessary. Maybe I'm just being very picky? At least they're using a matte black for everything facing the front, but the red accents would look weird anywhere except in a home environment. Lastly, do not bother with HDR on this monitor. The contrast ratio is okay, but not really good enough to be called HDR. Forget that it says HDR anywhere on the box. Other notes This monitor has a crosshair you can turn on. If you're playing something like a first-person shooter that has a shoddy reticle, you can use this to compensate for it. You can also use the crosshair in games that intentionally do not show you a crosshair without anyone knowing. However, note that doing so makes you a gigantic tool at the same time, so use with caution!! Conclusion This is a pretty good monitor. In fact, it's certainly the best monitor I've ever personally owned. The display looks nice. The colors and viewing angles are good. The refresh rate provides a really good experience in both gaming and regular desktop usage, and I've finally been able to properly watch the 120 FPS version of that one somewhat popular MCC video I made. The only real drawbacks are that there's only one DisplayPort connector and the HDMI inputs only support up to 1440p @ 100 Hz or 1080p @ 120 Hz if you have Adaptive-Sync turned on. It doesn't matter for stuff like my Nintendo Switch which would only ever support 60 Hz anyway, but if I connect a second PC (which I sometimes do), it actually does matter. And, of course, if your input device doesn't have a built-in audio jack, the monitor's 3.5 mm audio jack doesn't have very good audio quality. Pros IPS display (good viewing angles and color accuracy) 2560x1440 (plenty of pixels for regular usage) 144 Hz (smooth, responsive) 10-bit color support Adaptive-Sync / FreeSync Premium support (with compatible systems) Good grey-to-gray response times Good on-screen display Good stand (and VESA) Cons HDMI ports do not support 144 Hz with FreeSync turned on, only 100 Hz (1440p) or 120 Hz (1080p) Only one DisplayPort input, which makes the above con an even bigger issue Poor audio quality via 3.5 mm headphone jack Does not actually hit 1 ms response time without significant overshoot (but the default setting is pretty good) Not actually HDR If I had to rate this out of five stars, I'd say... it depends. If you only have one DisplayPort-compatible device you plug into your monitor and you have your audio coming from your motherboard, as is the case with most PC gamers, this monitor is easily a five star experience. Otherwise, I'd give it three stars. If you need to use the audio from the video cable (i.e. no direct audio from the system you're plugging in), the audio is terrible. You can probably split the audio from the video feed, but you'll have to buy a separate device for that, and they're usually around $20 for HDMI. I can't find anything on DisplayPort online except using a series of adapters. And if you need Adaptive-Sync support from multiple inputs, switching input to input is a pain. Sure, you can buy a $30 DisplayPort switcher, but it's not going to switch the audio (unless you're okay with the monitor's really bad audio). All in all, it's a good monitor, but having only one DisplayPort input, having a maximum of 100 Hz maximum refresh rate on the HDMI ports with FreeSync on, and, of course, the poor audio quality from the headphone jack all hold it back.
  18. My newer write-up does actually use "magic" but not in the way you use it. Traditionally, a "magic" is what identifies parts of a file. File explorers (e.g. macOS's Finder) may use this when an extension cannot identify a file. For example, in a Halo cache file, "head" identifies the header, "tags" identifies the tag data, and "sbsp" identifies a BSP tag, too. The Ogg container magic is "OggS" as well. Here's a description of a "magic number" on Wikipedia: https://en.wikipedia.org/wiki/File_format#Magic_number I don't consider a hardcoded address, 0x40440000, to be a "magic" as it does not actually help identify the file in any way, nor is it directly written in the file. I say "traditionally" because, yes, community terminology does not always equate to the terminology everyone else uses. I prefer to not call a memory address a "magic" to avoid confusing people outside of the community. This is the same thing as me discerning the "retail" version of Halo PC from Custom Edition, since "CE" is also used to refer to Halo: Combat Evolved, itself. And, yes, semantics of course. Also, thanks!!!
  19. I've updated the PDF with revision 2.0. This is a complete rewrite of it, and it no longer uses Google Docs, instead using LaTeX. You can view information about that here: https://en.wikipedia.org/wiki/LaTeX This rewrite contains more information as well as existing information being updated. Here is a sample page: Here's what it looked like before: I will leave the older versions up for now, but I do not recommend anyone use them as they contain old or outdated information.
  20. Oh, yeah, this is primarily intended for custom maps first and foremost. This is never going to produce Halo-like lightmaps. That said, I DO intend to reverse engineer tool.exe's radiosity and make my own lightmapping tool, possibly with modern features such as threading.
  21. I'm working on a new Blender plugin for generating lightmaps, Shadowmouse! This uses Cycles to bake lightmaps and Blender to unwrap UVs. It uses the radiosity parameters set in your tags to set up Cycles materials and sunlight. With this, you can bake high quality lightmaps for a number of maps with no manual work necessary (besides clicking a few buttons and running a couple commands), and you do not need to worry about tool's really bad UVs. Here are some examples. Blood Gulch (Original Halo PC lightmaps) Blood Gulch (Cycles lightmaps [WIP] - 2048x2048, 1024 samples, ~8 hours) camera.txt: 23.231102 -60.409565 10.358509 0.345733 -0.919217 -0.188493 0.066352 -0.176431 0.982086 1.221730 Things to note: Shadow definition is much higher on the Cycles lightmaps. UVs aren't broken on the Cycles lightmaps (look at the cliff on the right - the rock strangely has two shadows on the Halo PC lightmaps - an issue NOT present on the Xbox lightmaps) Sunlight strength is a bit lower on the Cycles lightmaps. In honesty, I'm not really happy with that, so I'm going to try increasing the sunlight intensity by 50%. Unfortunately, because it took 8 hours to bake these, I'll have to rebake these later. Longest (Original Halo PC lightmaps) Longest (Cycles lightmaps [WIP] - 2048x2048, 16384 samples, ~10 hours) camera.txt: -15.382186 -15.644083 0.837852 0.762132 0.529893 0.372231 -0.305612 -0.212480 0.928195 1.221730 Things to note: The actual sunlight is properly shown now on the Cycles lightmaps. The map is way too bright now, however. This may have to do with how Cycles does materials, or maybe Halo doesn't do indirect lighting very well. Either way, even if it's technically more realistic, it also completely changes the appearance of the map. This is because Cycles calculates lighting for 4 bounces by default. Setting the number of indirect light bounces to 1 gets a more desirable result although not 100% exact (see below). This may also be why Blood Gulch's shadows don't contrast as much. Anyway, I'm considering having the script set this by default for all of the materials. Longest (Cycles Lightmap [WIP] - 2048x2048, 512 samples, 1 indirect light bounce, ~12 minutes) Ignore the noise here. This is 512 samples, so it's really rough with indirect lighting. This is definitely not a replacement to tool.exe lightmaps, but rather an alternative. Not everyone will want to use this. Here are a few reasons why: It uses Blender, not 3ds Max (or other programs) Most people use 3ds Max, not Blender. Blender compatibility is something that is only recent, thus most Halo tutorials are for 3ds Max. So, I'm sure a lot of people would prefer something like Aether which uses 3ds Max. While you are not required to use Blender to make your model to use Shadowmouse (and, by the way, you should always use a separate project for baking lightmaps!), Shadowmouse is a plugin for Blender, NOT 3ds Max. I have no plans to make a 3ds Max-compatible version of this tool. 3ds Max is prohibitively expensive for me ($1530/year), and since I don't use 3ds Max, I do not know how to write in MAXScript. The file size is huge The file size of large lightmaps is utterly titanic, especially with 32-bit color. Blood Gulch's lightmaps at 2048x2048 end up being over 200 MiB! You can use 16-bit color like what the original lightmaps used. This will halve the file size (and if you're making Xbox lightmaps, you should do this!). However, at these resolutions, banding is going to be more prevalent. You can also use DXT1, reducing the size to 12.5% the original size, but block artifacting is going to utterly destroy some lightmaps. Time and energy Time is probably the biggest con of using Cycles. Cycles is very CPU demanding and time consuming! Higher resolutions and higher sample count both result in longer baking time, and some BSPs will take longer than others. For example, Blood Gulch at 2048x2048 with 1024 samples took well over 8 hours to bake on a Ryzen 5 2600 with the sample count set to 1024. Sample counts less than 8192 have noticeable noise in dim areas, but 8192+ samples takes an extremely long amount of time. Longest, at 16384 samples, took 10 hours, and it's way smaller than Blood Gulch and has only 1 lightmap texture to bake, not 15! Either way, while Cycles baked lightmaps, the PC was not very usable. Seriously, if your CPU doesn't have very many cores or has a low clock speed or IPC, then generating a bunch of 2048x2048 lightmaps with these settings is NOT going to be something you can just do overnight. And, of course, a Sandy-Bridge era Intel Core i5-2500K or AMD FX 6300 is going to absolutely chug compared to newer, better CPUs like the Intel Core i7-10700K or AMD Ryzen 7 5800X. It's not going to look like Halo I've done a lot of work in figuring out how to make materials that match Halo's radiosity parameters. However, the fact of the matter is that it's not possible to make Blender output a lightmap that perfectly matches the Halo aesthetic. Which, if you're going for a higher resolution, it just isn't going to happen anyway. Not only is it not possible to match the original Halo aesthetic, but if you use scenery that has random permutations (e.g. rocks), it's ESPECIALLY not going to look right. These will cast shadows that won't be correct for different permutations, resulting in the chance of a very dark shadow surrounding the scenery every time you load the map Some manual work can make things look more like Halo-style lighting, but it will ultimately be up to your expectations.
  22. For your first point, the built-in errors for the toolset is often highly cryptic. You MIGHT get a useful error message sometimes. But often times, you just get a generic exception error which CAN'T be searched, making them very un-user friendly. When it does have errors, many people often have to resort to messing up their tags until the tools are finally happy with them. And when it doesn't report errors where it should, the game crashes. Invader, on the other hand, is very impressive and well-polished for the feature set it provides. Error handling is also way better, often telling you exactly what is wrong with your tags if you have errors and even providing an automated means to fix tags if it's too much to try to fix everything yourself by hand. Not only that, but Invader supports a variety of inputs besides .tif and .wav for creating assets. Tool's LibTIFF implementation may not work with some TIFFs made by newer image editors. Invader also lets you use .png, .tga, and .bmp in addition to having a newer LibTIFF implementation. Invader also supports FLACs for audio input, allowing you to keep sizes down. Unlike tool.exe, it also does not require you to violate the law to make Xbox ADPCM sound tags, and the Xbox ADPCM sound is a bit better, too. Invader also has really good performance with large tags. The tag editor, for example, takes less than half a second to load d40_b. Guerilla, on the other hand, takes about a million years to open it. For your second point, the documentation may not be that much yet, but that's because I value quality over quantity and I've had to write it myself. Here are some examples: Want to make a bitmap? I have one of the best tutorials for that. It not only explains how color plates work and the many different quirks of them, but it explains all of the different formats you can use for making bitmaps including the pros and cons of them. https://github.com/SnowyMouse/invader/wiki/Creating-a-bitmap Want to make a sound? There's hardly any tutorials on that, but the Invader tutorial not only tells you how to make a sound tag, it tells you how pitch ranges and permutations work and also explains the various formats. https://github.com/SnowyMouse/invader/wiki/Creating-a-sound Invader also does a number of things the base tools simply do not do, and it is way more reliable at finding errors that the base tools do not do. It also does not introduce a number of errors the base tools do. I and many others consider this "very impressive" but the fact of the matter is that people use the stock tools because they're the stock tools. Not because they're actually any better to use, and certainly not because they have more documentation available. Such is the way of things here. And honestly, it's feedback like this that make me wonder if making a reimplementation of the Halo Editing Kit is even worth it (not blaming you of course - this is just what people tell me all the time). Not a lot of people test it, and no one actually lends a hand. I am lucky if someone even says "I'd help if I could program" here. I have had to pull so many hours and sleepless nights just to get Invader where it is by myself because, let's face it, no one cares. Almost everyone is perfectly happy using a broken, buggy, closed source toolkit for making their maps. Again, my concerns with this are that no one will use it, especially with MCC's modding support potentially being right around the corner, thus most people aren't going to use this format, thus it wouldn't be worth the added confusion. If MCC CEA was never ported to PC or I was certain it wouldn't go anywhere modding-wise, I would be fully on board with making this new format. And, of course, MCC CEA's new format is still .map, which all seven games are already .map.
  23. The problem is that .map is such a generic file extension. Tons of programs use files with .map extensions. And the game even has bitmaps.map/sounds.map/loc.map which aren't cache files but a completely different format to the other map files. Yes, changing the header will prevent the stock game from loading it. This is something Chimera does. However, people still want the extension changed - something I'm implementing in a future Chimera update that's in the near future. It's worth noting that MCC no longer compresses the header, but these maps are still incompatible as they use a different base memory address (thus they will crash the game) despite using version 7. We did give this consideration a while ago. The problem isn't so much implementing it on a client but moreso having tools that build maps with these tags. While Invader can build maps, people prefer to use the stock tools to build maps. So to get more people to use this convention, you would have to write a program that patches a .map file with this metadata. Anyway, right now, the map downloader isn't going to download things that aren't incompatible with the client you're using. HAC2 users aren't going to get a map that requires Chimera. Rather, each mod gets their own type of file. As for getting the client to only download just the header, this is something we'd have to figure out with msalerno1965, as he's the guy who runs the repo. He'd have to modify his repo. This is a really good writeup and some really good ideas for a new format. However, now there's yet ANOTHER format coming, this time for MCC (version 13). I have no doubt that this will create even more confusion. Not only that, but it has more tag space and support for things that Halo PC doesn't support like monochrome textures. This, too, will be .map. I'm starting to wonder if the new format I was considering will even be worth it at this point.