Bye, bye OS data/resource maps.

This is a tool I wrote to remove the max filesize from the map compilation process. It also always writes 0 to the map file header.
This makes it that Halo will never refuse to open a map file because of its own filesize check.

This has been tested and all signs point to it being safe.
You can download the patch script here: https://github.com/gbMichelle/HCE-STK/blob/master/tool_patcher.py
Right-click the raw button and choose "save as" if you only want the script.
You'll need Python 3.2 or higher to run it.

I have not uploaded an edited .exe file because I know there is at least 5 different tool.exe's floating around right now. And I want to be transparent about what it changes.

While its outside the scope of what you've done, do you know if it also fixes the problem where OS tool can't read a shared map file of a size of 2gb or higher?

Wonderful now I can have all the tags I need. Thanks!

Bungie probably used signed integers for all of its file reading operations, what that means is that the filesize can max be 2GB instead of 4GB. You probably shouldn't have more than that though, because CE is 32bit.
Edited by SBB_Michelle on Mar 30, 2019 at 01:32 AM

Link

That download contains two folders. One called "With Model Hack" and one called "Without Model Hack". The model hack increases the vertex limit or whatever on Stock halo, but OpenSauce overwrites it anyway so it only works on Stock.

Either way, each folder contains their own tool.exe, OS_tool.exe and OS_tool2.exe that have been patched with the script located in the OP as of the time of this post.

You're getting 6 tools for the price of none. And now featuring 100% less Python.

It's worth noting that setting the file size (32-bit integer at offset 0x8) in the map header to 0 will allow such large maps to work without needing mods like Open Sauce.

Halo only reads this value to check if it's <384 MiB. If it is, the map is (probably) valid.

Actually, it also checks if it's >128 MiB, and if it is, it leaks resource descriptors like crazy. It also does weird things like the name in the header not being read properly.

Setting this value to 0, therefore, is always a good idea even if the map would work otherwise.

Edited by Kavawuvi on Apr 1, 2019 at 03:03 AM

I believe you actually meant 0x8, ending at 0xC. 0x8 contains the maps filesize in bytes written as a 32 bit int, whereas 0xC is all 0's.


Based on what you're saying though there may be existing maps that have some memory issues due to their size. Here's a basic tool to anyone who may need or want it. It'll write 0 to the filesize located in the header, or alternatively unpatch it by rewriting the filesize in bytes.



Link

This would only work on existing maps, and would only improve the memory loading issues that 002 describes in the post above. If there are giant maps like B30_evolved that would run better for whatever reason, now you can do that. But you still want either SBB_Michelle's patch or the pre-patched Tools to actually bypass the filesize limit for compiling new maps.

Oh yeah, that's what I meant.

Anyway, cool. And yeah, you still need to make a map that's such a filesize to take advantage of it.

I'm working on a map building tool, myself (Invader), and I'm thinking I'll just have it just set the file size to 0 when it builds a map.

Maybe I could put an optional setting in Pool to apply this patch if it doesn't already exist.

Doit. You should also add the option to change the execution folder.

Changing the execution folder exists. The cwd directive tells pool what directory to run tool from. I use it all the time.

Okay, so... I can use this on non-OS campaign maps as long as I have SBB_Michelle's patch or the Hacked Tools?

I'm building a new level and it's too big. I don't want to remove content, what tool do I need to build my level?

Hacked Tools or Michelle's Patch


I have an existing mapfile, like B30_Evolved or another .MAP/.YELO file that is over 128MB in file size. I want to fix the memory glitches 002 mentioned. What tool do I need?

HugeMapPatch


The two are independent and serve different roles. HugeMapPatch is more or less useless, but if you're concerned about the memory issues Kava mentioned above that's it's purpose. HugeMapPatch just writes a value to the map header of an already built map. It CANNOT bypass the mapsize limit, since the mapfile must already be compiled. It is only used to improve memory issues for large map sizes.



Edited by DeadHamster on Apr 7, 2019 at 04:03 AM