Grenediac's Explanation of Mapfiles on IRC
Grenediac's Explanation of Mapfiles on IRC
ok, there are 3 parts to the model
there is the model index, the model meta, and the raw data
the model index is in the tag index and points to the meta
the meta points to the raw data, which contains the verts and indices for all of the model's submodels and
variations
now, when you rebuild a map...
the raw data portion does not work properly
let me get a link to show you how the mapfile works
http://www.halomods.com/projects/MapFor ... _level.htm
ok, you can see that there is the mapfile header, followed by the bsp
then the model raw data, which is followed by the index
after the index is the metadata
now, what happens during a rebuild
is that all of the meta data gets reorganized
but, the raw data doesn't
or something like that, im not exactly sure
so when mono did his library mod
he moved ALL of the raw data to the end of the map
from both source maps
which fixes the problem, but makes the mapfile really big
so you might ask why model injection "sort of" works
well, what happens is the raw data gets replaced by something that is not the same size
if you notice sometimes, model injection corrupts its own object and other nearby objects
and you get the jagged effect
that is because the raw data overwrote some other models raw data partially
which is also the reason the corruption changes when you get farther away
the raw data contains the verts and indices for different LODs
so one Level Of Detail may be corrupt, while others are fine
you have to update the headers if you change meta sizes
if you use the new SparkEdit to generate the offset lists
it includes the raw offsets for models
start and end
if you want to swap models, replace the raw data of one model that is larger than the one you are importing
"gui swaping"...what does that mean?
there is the model index, the model meta, and the raw data
the model index is in the tag index and points to the meta
the meta points to the raw data, which contains the verts and indices for all of the model's submodels and
variations
now, when you rebuild a map...
the raw data portion does not work properly
let me get a link to show you how the mapfile works
http://www.halomods.com/projects/MapFor ... _level.htm
ok, you can see that there is the mapfile header, followed by the bsp
then the model raw data, which is followed by the index
after the index is the metadata
now, what happens during a rebuild
is that all of the meta data gets reorganized
but, the raw data doesn't
or something like that, im not exactly sure
so when mono did his library mod
he moved ALL of the raw data to the end of the map
from both source maps
which fixes the problem, but makes the mapfile really big
so you might ask why model injection "sort of" works
well, what happens is the raw data gets replaced by something that is not the same size
if you notice sometimes, model injection corrupts its own object and other nearby objects
and you get the jagged effect
that is because the raw data overwrote some other models raw data partially
which is also the reason the corruption changes when you get farther away
the raw data contains the verts and indices for different LODs
so one Level Of Detail may be corrupt, while others are fine
you have to update the headers if you change meta sizes
if you use the new SparkEdit to generate the offset lists
it includes the raw offsets for models
start and end
if you want to swap models, replace the raw data of one model that is larger than the one you are importing
"gui swaping"...what does that mean?
Last edited by farklem on Thu Feb 26, 2004 2:15 pm, edited 1 time in total.
Re: Grenediac's Explanation of Mapfiles on IRC
the GUI is the Graphical User Interface, meaning that you are swapping things like the crosshair and whatnot...farklem wrote:"gui swaping"...what does that mean?
This post printed on 100% recycled electrons.
-
- Posts: 1375
- Joined: Fri Oct 24, 2003 1:30 am
- Location: Earth
- Contact:
![]() |
Re: OK
yeah, and putting it into numbered steps is good too... I just dont like bullets...farklem wrote:I plan on putting that in plain english in the next few days. I have no idea what gui swapping is. Grenediac just told me to post this sine I coppied and pasted it from the chat.
This post printed on 100% recycled electrons.
Was looking at the map dir structure from the link and seen this..
Data Type Name Description
-----------------------------------------------------------------------------
int decomp_len File length (length decompressed for Xbox)
is this a possible way to chnge filelength for the xbox map files?
I know this is in PC section, but I am assuming more people who understand this better could awnser.
__Blaz0__
Data Type Name Description
-----------------------------------------------------------------------------
int decomp_len File length (length decompressed for Xbox)
is this a possible way to chnge filelength for the xbox map files?
I know this is in PC section, but I am assuming more people who understand this better could awnser.
__Blaz0__
Im trying to understand the Halo map format at the moment, particularly how it stores the tags...
The tag index contains tags which in tun have a number which points to the metadata. However this number seems to be made up from the offset of the metadata from the beginning of the file + a value which I don't understand where it comes from. The mystery value is the same for all the tags in a particular map but varies map to map (e.g. for danger canyon it is 3FB028F4)
The number presumably has some meaning and is stored somewhere in the file. HMT seems to be able to extract it from the file as it displays the correct offset and when you change the offset it updates it successfully. Anyone know what this value is?
The tag index contains tags which in tun have a number which points to the metadata. However this number seems to be made up from the offset of the metadata from the beginning of the file + a value which I don't understand where it comes from. The mystery value is the same for all the tags in a particular map but varies map to map (e.g. for danger canyon it is 3FB028F4)
The number presumably has some meaning and is stored somewhere in the file. HMT seems to be able to extract it from the file as it displays the correct offset and when you change the offset it updates it successfully. Anyone know what this value is?
- Iron_Forge
- Posts: 532
- Joined: Sat Sep 20, 2003 9:21 pm
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Yes, map files can be increased in size, however decomp_len (as far as I know), is only used by zlib to decompress the map...(Probably pre-allocates buffers based on this, or something ;o)...If memory serves me correctly, decomp_len is always a multiple of 512...In the main map file header, there is also a metadata_size, which needs to be increased aswell to make a map file larger...The metadata_size is the size of all the data starting at the map file index, to the end of file (EOF)...
Aha i finally found out how you get the magic number... thanks to this webpage with lots of useful map info: http://huge.dyndns.org/halo/
Basically you take the first int from the tag index (little endian) subtract the tag index offset and then subtract 28 to get the magic number, note that that page says 36, but when i tried it out it was actually 28
Basically you take the first int from the tag index (little endian) subtract the tag index offset and then subtract 28 to get the magic number, note that that page says 36, but when i tried it out it was actually 28
hm, maybe it can differ in some way between you and them?Xhzjang wrote:Aha i finally found out how you get the magic number... thanks to this webpage with lots of useful map info: http://huge.dyndns.org/halo/
Basically you take the first int from the tag index (little endian) subtract the tag index offset and then subtract 28 to get the magic number, note that that page says 36, but when i tried it out it was actually 28
This post printed on 100% recycled electrons.