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

Kavawuvi

Administrator
  • Content count

    4,094
  • Joined

  • Last visited

About Kavawuvi

  • Birthday April 10

Extra Information

  • Gender
    Male
  • Contributed
    $100 (US) to Open Carnage
  • Raffle Victor
    One-time

Computer Details

  • Name
    Dark Citadel
  • Central Processor
    AMD Ryzen 5 2600
  • Motherboard
    MSI B450M MORTAR
  • Graphics
    MSI GeForce GTX 1070 Gaming 8G
  • Memory
    32 GB [2x 16 GB] G.Skill Ripjaws V Series
  • Storage
    500 GB Samsung 970 EVO
  • Power Supply
    EVGA SuperNOVA 650 G3
  • Case
    Fractal Design Node 804
  • Display
    Acer G257HU smidpx 25" 2560x1440 60 Hz
  • Keyboard
    MAX Keyboard Nighthawk X9
  • Mouse
    Logitech M510 Wireless Mouse
  • Operating System
    Arch Linux

Recent Profile Visitors

70,951 profile views
  1. Added a new program to the Invader toolkit: invader-archive. It works like invader-build except, rather than outputting a cache file, it outputs a .tar.xz file of the HEK tags that were used to build the map. This can be useful for distributing cache files as a set of tags, preserving the original tag data. Want to test it? You can download a Windows build here: https://invader.opencarnage.net/builds/nightly/download-latest.html
  2. It's a small but still quite important update for invader build: Firing position detection is more accurate Detail object collection tags now work Windows builds are also now being automatically uploaded as I work on Invader. You can get the latest build here: https://invader.opencarnage.net/builds/nightly/download-latest.html
  3. You can now download nightly builds which are hosted courtesy of @Tucker933. https://invader.opencarnage.net/builds/ These are Windows builds that are compiled from a snapshot of Invader's git repository at the time the build was made. If you don't want to wait until I post the next build of Invader, this is the place to go. However, some features may be incomplete or outright broken. Also, only a limited number of builds will be retained.
  4. Every so often, I get asked these questions. I figured it's worth answering here so people can find it later. Will invader-build get a GUI? The short answer? If it does, it probably won't be from me. The long answer? Making a good GUI takes a lot longer than than making a good command-line tool. Since I work on Invader on my spare time without any compensation and I have a limited amount of spare time these days, I'm only going to give as much time as required for it to be a good command-line tools. Also, you don't strictly need a GUI to build cache files, and it may actually be faster and more efficient to type the invader-build command in a shell than to open a GUI and navigate your filesystem for directories and files. That said, anyone is welcome to create their own GUIs for any Invader program. Are there any plans for replacing other features of the Halo Editing Kit? The short answer? Yes! The long answer? The Halo Editing Kit is limiting and it's closed source. For many reasons listed in this topic, it should be replaced in its entirety. Therefore, if I finish invader-build, to achieve this goal, I should replace another functionality of Halo Editing Kit, repeating until there's nothing left to replace. Where is Salamander? The short answer? It's being worked on but it's not in Invader's repository. Stay tuned. The long answer? Salamander has been fully functional for a long time, but the reason I haven't released it was because I was waiting for Blender 2.8 to come out. Now that it's out, I'm going to be working on porting it to Blender 2.8. How far is invader-build in completion? The short answer? Pretty far. The long answer? If you are building multiplayer maps without scripts or detail object collection tags, it should work perfectly. Will invader-build support Open Sauce maps and tags? The short answer? If it does, it probably won't be from me. The long answer? As I said before, I work on Invader on my own spare time without any compensation of any kind. I'm only going to give it as much time as is required for it to work with the base Halo Custom Edition game. That said, anyone is welcome to fork the Invader project and add the definitions themselves, though I probably won't accept any pull requests for it.
  5. I've updated the OP to better reflect the current status and description of Invader: a toolkit rather than a singular program.
  6. I've made progress and have gotten firing positions to a point where most AI aren't standing still. The beach battle on The Silent Cartographer is now an actual battle. The raycasting function still needs work before I release builds of it. Thus, if you need this right now and are unwilling to wait for the next build, you'll have to compile Invader from source. Sorry!
  7. Automatic aimbot detection has always been unreliable, especially when it comes to server side detection. Even if someone writes a detection for this that doesn't have false positives, it will always be a game of cat-and-mouse. Best of luck to whoever wants to take this job, but I think the best way to curb cheaters is to have active admins. If someone who is bad at the game wants to cheat, they'll find a way, and you need to be there to stop them.
  8. Added a section, "Why should the Halo Editing Kit be replaced?", to the top of the post. It's a good idea, but it's possible that pinning it right now may be premature. While I do think the topic is worth watching for updates, it isn't yet helpful enough to warrant pinning to the top of a section, plus it's in the Development section, not the Tools section. At the time of writing this, not enough of the Halo Editing Kit has been replaced for anyone to even make a simple box map. If and when enough of the Halo Editing Kit has been replaced that you can start to make complete maps without using the Halo Editing Kit, then I think it will be worth pinning this. For now, I recommend following this topic if you want updates to it. You can do so by clicking the Follow button on the top right corner of the page. I hope that answers your question.
  9. The Halo Editing Kit sucks and everyone knows it. How do we replace it? I made a list of stuff that needs to be done and stuff that has already been done. Why should the Halo Editing Kit be replaced? The Halo Editing Kit is unmaintained and unsupported. It contains plenty of bugs, and it is not very user-friendly. It also contains numerous limitations and restrictions that may make sense with the limited 64 MiB memory of the original Xbox but not a PC game even from this time period. It was also made for much older systems (pre-2004 systems), and while it still works with modern systems due to Windows's robust backwards-compatibility support, issues have crept up in the past that make some things worse than what they were in the past (Sapien and Guerilla have UI issues, for example). Also, to use the Halo Editing Kit, you must agree to an additional restrictive license that takes away your freedom to use their software. Invader, on the other hand, uses the GNU General Public License version 3.0 which ensures that the software is free and stays free. Mozzarilla and Refinery are part of the MEK which use the MIT license, a license with even fewer restrictions than the GNU GPL. But the worst of all is that the Halo Editing Kit is closed source and nonfree. Locking down the source code is not only unhelpful to the modding community, but if people begin relying on the software, it proves to be detrimental to the modding community. Why? Because if the software stops being actively maintained and supported, the modding community ends up having to rely on this unmaintained and unsupported software, resulting in potential complications and issues. If issues arise (bugs, limitations, or better ways to do things have been found), there is no way to update the software without resorting to reverse engineering and modification of the binary, so people end up being stuck with the limitations and bugs of the older, closed source software until this happens. In a way, the closed source software ends up being worse than not having the software in the first place. What needs done? Questions we can answer right now: Where do you get the base tags? Use Refinery. How do you edit your tags? Use Mozzarilla. How do you make your scenario tag? Use Mozzarilla. How do you make string list tags? Use Mozzarilla. How do you make HUD message list tags? Use Mozzarilla. How do you make animation tags? Use Mozzarilla. You currently need to use closed source software to make the animations as there is no JMA exporter for Blender yet. How do you make physics tags? Use Mozzarilla. You currently need to use closed source software or an outdated version of Blender to make the JMS files. How do you make model tags? Use Mozzarilla. You currently need to use closed source software or an outdated version of Blender to make the JMS files. How do you make your bitmaps? Use Mozzarilla or invader-bitmap. How do you build your multiplayer maps? Use invader-build. Questions we cannot answer right now: How do you make your sounds? We don't know yet. How do you make your fonts? We don't know yet. How do you compile your scripts? We don't know yet. How do you make .scenario_structure_bsp tags? We don't know yet. You currently need to use closed source software or an outdated version of Blender to make the JMS files. How do you make collision model tags? We don't know yet. You currently need to use closed source software or an outdated version of Blender to make the JMS files. How do you place your objects? Besides manually placing them in Mozzarilla or placing them in Blender and using an old invader-scenario tool I wrote to apply them to a .scenario tag, we don't know yet. How do you make sprites? Besides manually making the sprite data yourself in Mozzarilla, we don't know yet. How do you bake lightmaps? We don't know yet. How do you build your singleplayer maps? We don't know yet. Milestones to achieve? Making a HUD from scratch: Requires being able to edit tag data (use Mozzarilla) Requires being able to create 2D texture bitmaps (use Mozzarilla or invader-bitmap) Making a simple multiplayer map: Requires being able to build a map (use invader-build) Requires being able to create scenario tags (use Mozzarilla) Requires being able to edit tag data (use Mozzarilla) Requires being able to place objects (use Sapien from the HEK) Requires being able to compile BSPs (use tool.exe from the HEK) Requires being able to bake lightmaps (use tool.exe from the HEK) Making a new object completely from scratch: Requires being able to make animation tags (use Mozzarilla) Requires being able to make model tags (use Mozzarilla) Requires being able to edit tag data (use Mozzarilla) Requires being able to make a HUD for weapons, units, and vehicles (can be done fully in Mozzarilla, optionally using invader-bitmap for bitmaps) Requires being able to make collision model tags (use tool.exe from the HEK) Requires being able to make sprites for stuff like bullets and decals (use tool.exe from the HEK) Making a new campaign map: Requires being able to edit tag data (use Mozzarilla) Requires being able to make string tags (use Mozzarilla) Requires being able to create scenario tags (use Mozzarilla) Requires being able to build singleplayer maps (invader-build works, but it cannot yet place firing positions correctly, so use tool.exe from the HEK for better results) Requires being able to compile scripts (use Sapien from the HEK) Requires being able to place objects (use Sapien from the HEK) Requires being able to compile BSPs (use tool.exe from the HEK) Requires being able to create sounds for voice acting (using tool.exe from the HEK) Requires being able to bake lightmaps (use tool.exe from the HEK) Requires being able to make sprites (use tool.exe from the HEK) Making a complete game: Requires being able to edit tag data (use Mozzarilla) Requires being able to make multiplayer maps (incomplete) Requires being able to make campaign maps (incomplete) Requires being able to make objects from scratch (incomplete) Requires being able to make fonts (use tool.exe from the HEK) Where do I get this stuff?
  10. I'm working on a raycasting function in Invader. What this function essentially does is create a ray from point A to point B. If the ray intersects with a surface, it returns the following things: Coordinates of the intersection Surface index (can be used to determine the material of the surface) Surface leaf (can be used to determine the cluster the surface is located in) There are a few uses for such a function, but the reason I'm making it right now is so I can accurately determine the surface and cluster indices for an encounter (AI) firing position. I'm also going to be using it to determine if the spawn point of an encounter (that doesn't use 3D positions) is within a BSP, as brute forcing this is slow. To be honest, this function is going to be very hard to write and get to be accurate if I even get that far, but to build singleplayer maps, it's important.
  11. Here's a small update. Cluster index for firing positions is now calculated. Refactored the function for checking if a point is within a BSP. If an encounter isn't found in the BSP, its BSP index gets set to -1. Player starting locations and move positions are no longer considered when checking if an encounter is located within a certain BSP. It turns out that tool.exe only checks squad starting positions and firing positions. Someone also reported a bug with invader-crc that occurs when specifying a CRC higher than 0x7FFFFFFF. It turns out MinGW uses 32-bit integers for longs while GCC on Linux uses 64-bit integers for longs, and I was using std::strtol which gets signed longs (and since I tested only on Linux, I never got any issues since longs can be 0x7FFFFFFFFFFFFFFF for me). I've changed this to std::strtoul to get unsigned longs.
  12. At least they're upfront about it. I've been asked a lot of times about porting Chimera features to MCC, and I basically answered this on my Chimera Discord, but here's basically the summary of it: As amazing as an opportunity it would be to mod Halo CE Anniversary, I'm probably not going to buy it. I don't have a lot of money, and I certainly can't justify spending $10 on a PC game I already own on the PC. Also, I don't want to release a fix for the game that bans you from Xbox Live. Ideally, they'd make it so if you have mods, anticheat gets disabled (obviously no matchmaking and stuff but that's fine). However, they could also have it so if you even so much as think about fixing the fog in Assault on the Control Room, you'll take a well deserved VACation from Xbox Live Halo 3 PC looks cool though.
  13. Here's a pretty important update: invader-build's AI BSP detection is now nearly 100% accurate to tool.exe's AI BSP detection. I say "nearly" because I need to implement a raycasting function so I can accurately calculate the distance of an AI encounter spawn point to the floor. Currently I brute-force this and it's inefficient, but it's good enough for Bungie's campaign, most likely with 100% accuracy. Here's what's left for invader-build before it's fully functional: Firing positions do not work properly yet due to two hidden values not being calculated yet. I don't know what these are, so I am spending a lot of time investigating it. For now, AI will stand in place to fire. The Pillar of Autumn has a softlocking issue in the first room. If you don't make it to the door in the cryo chamber before the crewman makes it, then the door might not open. This will need addressed. The scenario references array is not yet generated. This is required for script. Extracted maps should work fine since this array is already built, but new maps or maps with new scripts will need this manually set up for now. Detail object collection tags do not yet render. I don't know why.
  14. Another small update: I fixed an issue with invader-crc exceptioning on certain maps. Also, I've benchmarked invader-crc against Refinery's CRC spoofer. Both Release and Debug builds were tested. These were built using GCC 9.1.0 for 64-bit Linux. Also, to keep things fair between invader-crc vs. Refinery, a few things were done in the test. For both tests: Both used 64 MiB RAM disks rather than the usual SSD to maximize I/O ui.map did not have any corresponding bitmaps.map, sounds.map. or loc.map Both used separate ui.map files to avoid them from impacting the result of one another Results seen are actually the averaged, combined result of five runs For Refinery: Because invader-crc is a purely command-line tool, I opted to use Refinery's REPL which is also purely command-line rather than opting to use the GUI, as a GUI can tax performance The time to open and save the map was timed in addition to the CRC spoofing itself since invader-crc does both, too For Invader: Debug benchmarks were also done to provide a worst-case scenario if you choose to compile for Debug for whatever reason It's unsurprising that invader-crc is 40x faster than Refinery at spoofing the CRC32 of ui.map when you consider that invader-crc is already compiled from C++ source while Refinery is run from a Python script. This makes invader-crc better as a dedicated CRC32 spoofing tool. Even so, 2.7 seconds to spoof one map isn't too bad if you aren't planning on spoofing multiple maps. Refinery, after all, has a multitude of features besides CRC32 spoofing including deprotection and extraction. Other changes: invader-build: Improved (but not perfected) BSP detection for AI encounter placement Increased the verbosity of BSP detection for AI encounter placement; this may be put behind a command-line switch in the future Refactored the function for checking if a point lies inside of a BSP Added a warning for encounters that are partially inside of the BSP Other: project() is now specified in CMakeLists.txt to silence a warning that may appear when building using newer versions of CMake
  15. Nice. Chimera 1.0 fixes this issue with Refinery, too, so look forward to a release of that.