Mac Gaming Mods

Seabees4 wrote:You mean whole new bsps/maps of scenery? Kewl! As for the internalizer, you'd have to ask root.

Modzy wrote:Looks good!

How to use Bitmaps Internalizer:
1. If you're working with a demo map, hack it to a full version header.
2. Open your map, find the bitmap you want to internalize.
3. Once you click on a bitmap, hit the arrow to your right. That will display all the reflexives, each reflexive is its own .dds file.
4. Select which reflexive you want, normally there is only one though.
5. If the bubble saying "Internalized?" isn't filled in, click it.
6. You should get a message box saying it was successfully internalized.

All done.

Modzy wrote:

Altimit01 wrote:The issue relates to importing anything from CE. Consider first that every bitmap and sound tag contains a pointer to a literal address in either the bitmaps.map, sounds.map or elsewhere within the map itself. For this particular case, the battle rifle would have sounds and bitmaps stored in the raw data section of the map it was in. When you recursively export the file, it gets all of the meta data but doesn't actually extract any of the raw data except for models. With normal maps this was acceptable since bitmaps and sounds were always externalized but more recently we've seen more and more internalized and CE content. So what happens is the bitm and snd! tags that were imported point at some position within the map itself that most likely contains either model, BSP or tag index data. When the application reads the data there as bitmaps or sounds it interprets them as "corrupted" data and the harlequin bitmaps, grating sounds are the result. When you "fix" the "corrupt" data by writing to those locations you fix the sound and bitmaps but corrupt the original data which was there. For example, it would corrupt the model as your second picture shows. There are a couple of ways to fix this. The easiest if you have the tools to do it, is to write the bitmap and sound data to the end of the map and fix the bitm and snd! tags to point to those locations. Alternatively you could change the flag in the bitm and snd! tags to make them external and then use the PC EOF trick to import the bitmap and sound data to the end of the bitmaps.map and sounds.map files. In either case it involves understanding the nature of raw data and how bitm and snd! tags are laid out in order to hex them and fix the offending addresses.

Lol, thats more then some of the newer people can handle.
I'm getting my personal pack ready for release.
For that, I just edited the bitmaps tags so that they point out-side the map.
Then people can use apps like Bitmap Internalizer, to re-Internalize the bitmaps data in the correct section of the map. (raw data section)
Just inject the .dds files using your Eschaton .7 (bitmaps demo) and your done.
This method works every time, and does not kill models or other raw data.

That was all I could do with the tools we have.

Kayar wrote:This is all CE?