Shell Bitmaps

[NeX 1,756]

Ok, I'm trying to replace the gametype icons (the ones that appear in a rhomboid box in the upper right hand corner of the default HUD) with new ones. The ones I have should be a smidge higher resolution, and also hopefully move the position of the images around.

 

I ended up replacing the team_background (the box) with "nothing" to get it to disappear, since removing the reference gives an error in tool. Obviously the game needs these tags to think straight, but replacing the "original" team_background.bitmap with a new one wasn't an issue. Tool spits "this bitmap is a different size (x) than expected (y)", but it compiles and seems to work fine.

 

However, when I try to alter the individual bitmaps themselves, I get weird things.

 

The .bitmap tags themselves are referenced by a tag_collection tag, which is seemingly referenced by....nothing. Expanding in eschaton seemed to agree. Well, that's odd, but I replaced the tag_collection references for the ui\shell\bitmaps\team_icon_<take your pick>.bitmap tags with my new ones.

 

For my effort I recieved nothing - just empty space where the old images were.
Ok, well, maybe the tag_collection doesn't like to be tampered with. Simply replacing the .bitmap file with a new one of the same name should "trick" it right? Or at the least give me the same issue of not appearing?

 

Not so! I actually get the SAME image that was there before...even though that bitmap no longer exists in that path, and the bitmap that DOES exist there (with the same name) isn't the image that is displayed. It's like a ghost file. I even went so far as to take the original .bitmap that I had renamed completely out of the folder, flush my HAC cache after rebuild, follow the chain to make sure the renamed custom .bitmap was indeed the correct image, and still I get the default images. I'm really not sure what's going on, I've checked the virtual cache as well, and still nothing seems to make sense.

Are this bitmaps even changeable? Do they have to be the same dimensions? I'll keep trying things, but if anyone has any input on it, it'd be greatly appreciated. I feel like I've exhausted all of the logical operations based on my current knowledge, so I ask now when I'm reduced to simple experimentation, which, while enjoyable, is very time consuming with a poor cost:reward ratio.

[Inigo Montoya 241]

I've always heard that the multiplayer icons are "engine controlled". I think that's only part true.

The tag_collection is what I like to call a "base" tag. Nothing references globals.global, the same goes for that, part of Tool's compiling process is using that tag-name to build the map.

You can delete the references in Guerilla/Kornman. Just hit "delete" next to it when that reflexive is selected, I've done that in Carthage so I can confirm the mapfile compiles without any issues.

I have also noticed it's reluctance to show up. I'm guessing that Tool simply won't internalize the bitmap, and it's looking for it in the bitmaps.map file that CE has. Give me a moment or so, I'll post back with some updated info.

Edit:

I can confirm it's an "indexed" tag. So when Tool builds the map, it's expecting it to be located in the bitmaps.map file, and therefore when Halo loads it, I assume it too is expecting it to be located in the bitmaps.map file.

Seems it actually is "engine controlled".

Edited March 5, 2014 by Inigo Montoya

[Kavawuvi 7,026]

Not sure if this is helpful, but I've found that tag collection tags contain a ton of the ui widget definition tags. Their existence isn't referenced, same for tags like the game globals tag, the stock ustr tags, and some of the bitmaps and sounds.

This is the executable for Halo for Mac OS:

Here's Halo PC:

As you can see, their paths are actually hardcoded into the executable.

[NeX 1,756]

That makes sense, but why replacing the original tag with a new one in the same path with same name doesn't work is beyond me. I've seen it done, too, ill have to find a link

[Inigo Montoya 241]

It's not a normal tag. The placement is entirely engine controlled, and the bitmap is inside the bitmaps.map file. When you're replacing the .bitmap file, it's internalized. The engine is trying to pull it from the external mapfile.

Look into Harbinger, and read the explanation Altimit listed. Indexed tags (1's as they're called) reside inside the bitmaps.map file, and have to be pulled out manually and matched up with an existing bitmaps.map file (the Halo PC Version)

Here's how a normal tag works;

Assault Rifle.Weapon--(tag_location_address)-->Assault Rifle.gbxmodel--(tag_location_address)-->Assault Rifle.Shader_Model--(tag_location_address)-->Assault Rifle.bitmap

Here's how this tag seems to be working, and 002 is helping confirm my suspicion;

Halo.exe--(look in bitmaps.map at offset 0x###)-->team_icon_ctf.bitmap

The "Tag Collection" is just that. A collection of tags to make sure that they're in the map. Just like the globals references all the grenades and weapon tags, and bipeds and everything else that NEEDS to be there for the game to work. The tag collection isn't doing anything with the tags, it's not using them. Just referencing them. The pistol USES it's model, the tag_collection just calls for it so Tool will pull the tag. Halo.exe is what's using that bitmap.

Edited March 5, 2014 by Inigo Montoya

[NeX 1,756]

Welp then ill just have to make 'em disappear. Disappointing, but this game often has its hard limits.

[Takka 13,376]

aLTis: Giraffe helped me with this. Apparently I had to modify bitmaps.map in order to compile the map with different bitmaps.

[giraffe 794]

When compiling a map with tool, it will try to use the bitmaps from bitmaps.map instead of the bitmaps in your tags folder.

1. Make a backup of bitmaps.map
2. Open the original bitmaps.map in a hex editor
3. Search for bitmap tag name
4. Rename it to a tag that doesn't exist
5. Save bitmaps.map
6. Compile your map