[x86] Halo Cache File Size Limit

[Kavawuvi 7,026]

Halo will automatically reject cache files if their header has a filesize that exceeds exactly 384MiB (that's 402.3MB on OS X). In hexadecimal, that is 0x18000000.

 

 

I wrote a HaloMD plugin for writing NOP over the selected data and then I made a video of me testing it, by copying the entirety of sounds.map and bitmaps.map into bloodgulch.map. If it is this easy to do it in HaloMD, is it easy to do it with HAC?

 

 

Know that this Blood Gulch is now incompatible without the extension I wrote. I know that Tool has some sort of weird limit thing, as a bunch of people discussed, so it's not really that useful for Halo CE, only Halo PC and HaloMD.

Edited April 16, 2014 by 002

[WaeV 5,049]

I made a video of me testing it, by copying the entirety of sounds.map and bitmaps.map into bloodgulch.map.

 Did you test whether that map breaks Halo when your fix is not in place? IIRC, there's some data in the mapfile which specifies how long it is... I suspect that extra data on the end is just ignored by default.

 

You might also test your fix by using Eschaton to compile a really large map, instead of just appending data hodge-podge. Make sure to find a map that definitely breaks stock Halo, but definitely works given your fix.

 

If it is this easy to do it in HaloMD, is it easy to do it with HAC?

Yes, in that Bt could easily modify the executable this way if he wished. No, in that HAC does not currently have an extension API.

 

If Quickbeam ends up being the Windows counterpart to MD (which I increasingly hope it to be), this might be possible with Python extensions... But at this rate I can't expect it will be ready for at least another year.

 

On the other hand, HAC may become an open community project before Quickbeam extensions do. Oh well, we'll get there one way or another.

[NeX 1,756]

tool has the 128MB limit for multiplayer maps. That being said, tool_pro is the same program without the limiter, which is what I've been using to compile revolution maps that go over the limit (and usually just in general so I dont have to flip flop between the two).

[Kavawuvi 7,026]

Did you test whether that map breaks Halo when your fix is not in place? IIRC, there's some data in the mapfile which specifies how long it is... I suspect that extra data on the end is just ignored by default.

 

You might also test your fix by using Eschaton to compile a really large map, instead of just appending data hodge-podge. Make sure to find a map that definitely breaks stock Halo, but definitely works given your fix.

 

That is actually how data is internalized. I could, if I wanted to, have one of the tags reference a bitmap/sound in the junk I pasted. Halo will not use any of it until it's needed, so it's mostly unused. Since the combined bitmaps.map and sounds.map is much larger than 384MiB, and only small portions of them are actually used when a map is loaded, I figured this would be a great way to test it.

Take Phoenix 3, for example.

The unshaded black area is internalized data. It takes up 84% of the map. If I subtracted it, the file size would be only 20MiB. I could insert the internalized data into sounds.map and bitmaps.map wherever it's offsetted, then change every bitmap and sound to have it not be internalized. Everything except Phoenix 3 would be broken looking, then.

 

It does not break stock Halo; Halo simply ignore the map. Such a map that breaks this limit probably does not exist, because Halo CE likely has the same limits.

Edited April 16, 2014 by 002

[WaeV 5,049]

 Such a map that breaks this limit probably does not exist, because Halo CE likely has the same limits.

I remember Pepsi hitting the limit while working on his Zelda mod, but he just removed some resources until he was under the limit.

[Tiel 89]

iirc Tool Pro does the same thing and it creates buggy maps.

[Kavawuvi 7,026]

I remember Pepsi hitting the limit while working on his Zelda mod, but he just removed some resources until he was under the limit.

What I mean is, I don't think anyone is going to release a mod that goes over this limit, because the map won't work, so they would be releasing a bloated and broken map. What I want is this limit to be possibly resolved in HAC or something. Edited April 17, 2014 by 002

[WaeV 5,049]

What I mean is, I don't think anyone is going to release a mod that goes over this limit, because the map won't work, so they would be releasing a bloated and broken map.

Mmm. An MD mod could depend on your extension as a fix, but nil doesn't host maps larger than 200MB anyways, as you pointed out.

[Kavawuvi 7,026]

Mmm. An MD mod could depend on your extension as a fix, but nil doesn't host maps larger than 200MB anyways, as you pointed out.

It's not because it breaks anything, but because it takes too long to download such a large map, and it takes forever to patch large maps, as well. It wouldn't mean anything to HaloMD, since nil has a 200MB restriction (190MiB if you're a Windows guy). It would likely mean something to HAC, though, because there's no fascist mod submission policy in place.

[NeX 1,756]

iirc Tool Pro does the same thing and it creates buggy maps.

 

From my experience anything that doesn't break the "real" limit doesn't cause buggy-ness. However, from what I understand any time a reference to data that is "outside" the limit is called during runtime, say, a firing .sound tag for a weapon, the game will crash. So it can run smoothly until I grab that gun and shoot it, leading people to erroneously believe their tags are the problem, when really they've just stuffed too much shit into one map.