Kavawuvi

Invader

137 posts in this topic

Here is another small update:

 

invader-build:

  • New argument: --always-index-tags. This will force all indexable tags to be indexed without checking, speeding up map build time slightly. Only use this if you have not modified any tags present in bitmaps.map, sounds.map, or loc.map.

invader-bitmap:

  • Dropped libpng, instead opting for stb
  • Added support for TGA and BMP formats through stb
  • TIFFs won't have their RGB multiplied with alpha by libtiff anymore. If you want this behavior, do it yourself. You don't, though.
Vaporeon, Takka and ST34MF0X like this

Share this post


Link to post
Share on other sites

Tiddy-bits:

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.

 

04bLLgx.png

 

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
Takka and ST34MF0X like this

Share this post


Link to post
Share on other sites

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.
ST34MF0X and Takka like this

Share this post


Link to post
Share on other sites

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.

ST34MF0X, Takka and ranarene like this

Share this post


Link to post
Share on other sites

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.

Takka, Sunstriker7 and ST34MF0X like this

Share this post


Link to post
Share on other sites

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.

 

unknown.png?width=1253&height=706

 

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!

ST34MF0X and VoidsShadow like this

Share this post


Link to post
Share on other sites

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.

ST34MF0X, DSalimander and Takka like this

Share this post


Link to post
Share on other sites

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.

Takka and ST34MF0X like this

Share this post


Link to post
Share on other sites

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

Takka and ST34MF0X like this

Share this post


Link to post
Share on other sites
  • Recently Browsing   0 members

    No registered users viewing this page.