Posted 14 April 2012 - 11:17 PM
Posted 15 April 2012 - 06:35 PM
Don't inject bitmaps with eschaton, it adds a fuzzy cloud around them. Sounds like you did it right.
Ryx, I'm having trouble with the internalizing. I did what you said. I expanded putput.map, went to the Data Internalize then I checked the boxes and clicked rebuild map. I think the bitmaps were already in through HMT but I don't know how to inject bitmaps in Eschaton, so I'm guessing that's where I messed up. Can you explain it again please?
If you injected the bitmaps with anything internalizing them will add them to the map, what it does is add the bitmaps to the end of the map file instead of bitmaps.map
Posted 16 April 2012 - 03:13 PM
Posted 16 April 2012 - 05:36 PM
Naw you can inject them with hmt then just internalize them with esch at the end, you don't need to EOF unless you're releasing a mappack.
Alright then, I'll continue to use the EOF trick with HMT. Thanks.
Posted 16 April 2012 - 09:28 PM
Posted 18 April 2012 - 09:53 PM
Posted 19 April 2012 - 12:35 AM
You don't need a bitmaps.map if you internalized correctly. Are you running all the tools as admin?
Errrm, I'm not doing so well with internalizing. I put the bitmaps in through HMT, then I internalized with Eschaton. When I put the new rebuilt map into my MAPS folder with a new bitmaps.map the Chiron map is just black (Black = only the skins that I editted). The lights are still there and that's basically it lol, everything else is black.
Posted 19 April 2012 - 04:08 PM
Posted 19 April 2012 - 07:09 PM
You don't need a bitmaps.map if you internalized correctly.
Wouldn't that only be the case if you internalized ALL the bitmaps? You should only need to import the ones that changed, and continue to rely on bitmaps.map otherwise. Otherwise you'll balloon your map's filesize.
Posted 20 April 2012 - 05:24 PM
Posted 21 April 2012 - 02:15 AM
I don't remember what EOF does, I never really did enough skinning to use it.
Edited by WaeV, 21 April 2012 - 02:16 AM.
Posted 21 April 2012 - 06:41 AM
I like effing with shield effects and bitmaps. They look too bland in Bungie's defaults; In my opinion.
Posted 22 April 2012 - 11:29 AM
The bitmaps were originally stored in a central bitmaps.map resource map, where they were pulled from when a play map was loaded. The benefits of this are that bitmaps remain constant across maps, so editing a bitmap will apply the changes to every map that uses that bitmaps.map file.
The bad side of this is that it does that. In some cases when modding, you may want a bitmap to only appear on one map. Before Eschaton, the only way to do this was through an EOF using HMT. This copied the bitmap data, and placed it at the end of the bitmaps.map file. It then changed the reference to the new point inside the .map.
The plus side to this, is when a bitmap is stored at the end of the file, it can be larger then the original bitmap. Because the mapfile is based off of the bitmaps being at a specific part of the map, if you made a bigger bitmap it would have to overwrite whatever came after it.
So now instead of having to make them the same size, you can make a fully custom bitmap of any size, and not worry about it overwriting anything else, because it's already at the end of the file.
Now, if you did an EOF, then EOF'd another bitmap, then took the first one and injected a larger bitmap, it'd overwrite the second. It only works if it's the last bitmap inside the mapfile, so make sure to inject all your larger bitmaps before you EOF another one.
But EOF isn't always the best solution for sharing mods. For huge projects spanning multiple maps, it works well because the bitmaps.map can be included with it. However, for small maps and mods, it becomes a burden because the users must download the entire bitmaps.map file, which is over 300MB stock.
To solve this, Internalizing bitmaps became the new standard. Instead of placing them at the end of the bitmaps.map file, they were re-written inside the .mapfile itself. This is done in many CE maps with custom content, the bitmap information is simply written inside the map itself, and there's something that lets the engine know that the bitmap is stored internally as opposed to the stock external storage in the bitmaps.map
So the engine reads that "internal" 'flag', reads the pointer (offset) that lets it know where it's stored, and pulls the bitmap information from inside the map.
Now, internalizing all your bitmaps adds on a lot to the filesize of your map, so it's usually best to only internalize bitmaps you plan on editing, and leave the stock textures to be referenced externally.
Posted 24 April 2012 - 08:54 PM
IT WAS SO FUCKING EASY TO MAKE BUMP MAPS LMFAO!!!!!!!!!!!!!!!!!!!!!!!!1
I was a dumbass because what I did is that I... I won't tell it, because I was just westing weeks doing that ¬¬
Ty so much fot this tutorial <3
- WaeV likes this
Yeah! We want to play it!
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users