Melee Arcive Viewer (MAV) in development project.
- Thread starter Tcll
- Start date
OP
Tcll
Complexity == Fun >:3
- Thread Starter
- #444
O.O
nice job revel
can't wait to see what comes out of this
umm...
for the sake of me practically not knowing too much of how to really do anything...
could you maybe answer any of my Q's I've posted in the past while you were away <:3
I really need to catch up on my knowledge, and brawl isn't working out too well :/
people are either lazy or tied up and won't post for weeks...
so yea...
might as well catch up here...
nice job revel
can't wait to see what comes out of this
umm...
for the sake of me practically not knowing too much of how to really do anything...
could you maybe answer any of my Q's I've posted in the past while you were away <:3
I really need to catch up on my knowledge, and brawl isn't working out too well :/
people are either lazy or tied up and won't post for weeks...
so yea...
might as well catch up here...
OP
Tcll
Complexity == Fun >:3
- Thread Starter
- #445
yo revel...
forget my past Q's...
I'll ask when I need them
no-one else understands how the relocation table works but you...
so umm...
how bout filling us in :/
I understand how to use the table to get the specific offsets...
what I don't understand is how do you tell the seperate data groups apart from each other??
(such as verts, normals, UV's, etc...)
forget my past Q's...
I'll ask when I need them
no-one else understands how the relocation table works but you...
so umm...
how bout filling us in :/
I understand how to use the table to get the specific offsets...
Code:
size = int(dataBlockSize) + 32
count = int(relocationTableCount)
file.seek(size, 0) #I think '0' = from start :/
while (count > 0):
index_location(file.read(4))
count -= 1(such as verts, normals, UV's, etc...)
Last edited:
From the relocation table you cannot tell what is what. The relocations are only used to adjust the various offsets in the file into actual address when the file data is loaded into memory. The root nodes contain offsets to the beginning of particular data, and their string names tell you what you can expect there. For Smash Brothers Melee for example _matanim_joint, _joint, ftData, map_head, and other names designate different starting structures and so on...
OP
Tcll
Complexity == Fun >:3
- Thread Starter
- #447
ah so the root nodes, along with the string types play the role of telling what data type it is
I assume the strings are buried within the file?? :/
and also...
how exactly do I use the root nodes??
I've went all this time just guessing they were material nodes...
now I find out they're not
I assume the strings are buried within the file?? :/
and also...
how exactly do I use the root nodes??
I've went all this time just guessing they were material nodes...
now I find out they're not
Well, with the root nodes, unless you know the structure it points to you have to find the size of the structures. Each offset referenced in the relocation table itself references the beginning of another structure. By the nature of the way structures work, they should not overlap, thus you can usually tell the size of a structure byte taking the length of data between the start address and the beginning of another structure location. This is what the templates i have been posting help with, as they mark the beginning of each structure in blue. It may be necessary to compare like structures in multiple files to ensure the sizes match and it is not actually an array of structures. From there you have to determine what values do what, since some structures can contain offsets, you can figure out the purpose of the structure by following the child structures they point to.
OP
Tcll
Complexity == Fun >:3
- Thread Starter
- #449
I havn't used 010 editor since it quit on me...
are you good at GUI programming by chance??
maybe you could try to program a hex highlighter for SSBM...
I've tried and failed multiple times
the best I can do for a GUI is in HTML...
but I'm better at Py than JS, so you see my delema
sry...
had to get this off my chest so I could concentrait
(what I suck at doing)
OP
Tcll
Complexity == Fun >:3
- Thread Starter
- #450
hmm... I see...
but that again just tells me not exactly what I need to know...
could you state that talking more about the node related to the offset...
or more like how the nodes work with the table to find the data...
or...
is it similar to an mdl0 where the nodes are the offset groups in the relocation table,
or simply stating
(node1 points to group1, and so on)
_____
reloc tbl:
group1
group2
group3
node1
node2
node3
with the groups containing the offsets to the particular data types,
and the nodes actually being the list offsets...
IDK...
just a theory...
In Melee data, the relocation table has no other use than to tell you where every valid offset value in a file is located. There is not guaranteed ordering or type as far as this table is concerned.
From matching structure size between files with like root node information, following enough of the offsets in the hierarchy of structures to reach the desired data and notice patterns, the various main and sub-structure can be formed.
if you follow a series of offsets and come across a structure that consistently has offsets to Material and Mesh data, you can assume the containing structure is related to Model information, until something disproves it.
Example, in Melee: There are a lot of root node types that end in "_joint". Some of these nodes also have "Top", "TopN", "matanim", "shapeanim", and other sub-strings in the name. With some knowledge of how melee works and a little graphics programming background, an assumption can be made that "matanim" might have some thing to do with "MATerial ANIMations", "shapeanim" with "SHAPE ANIMations", and so on. But "joint" in particular usually mean a bone or some other skeletal or hierachy based node element. Following an offset of a root node that simply ends in "_joint", without any other sub-strings, may lead to a structure with a bunch of gibberish values that are not definite yet, but a patter emerges where there are a bunch of zero values separated by a series of three 0x3F800000 values. From know of hex values and their various representations, this sticks out as the float value 1.0f. Given the assumption that the information was joint/bone related, this could lead one to think of joint transforms and matrices, where a very common place to see a series of three 1.0f values would be as the scale factor of a transform. Looking through more similar structures may lead to the notion that these values appear to always be one, while the two sets of three values around them also seem to be valid floating point value with the eventual determination being that these are the rotation and translation portions of these components. Upon further inspection you may come across offsets within a common location within the joint structure that when valid also seem to point to other joint structures. Playing around and comparing values may lead one to consider these to be with next and/or child pointers to the joints that follow in the hierarchy.
From there it is a series of trial and error, or comparing again any other known information available, and so on until reasonable assumptions can be confirmed, denied, or otherwise.
From matching structure size between files with like root node information, following enough of the offsets in the hierarchy of structures to reach the desired data and notice patterns, the various main and sub-structure can be formed.
if you follow a series of offsets and come across a structure that consistently has offsets to Material and Mesh data, you can assume the containing structure is related to Model information, until something disproves it.
Example, in Melee: There are a lot of root node types that end in "_joint". Some of these nodes also have "Top", "TopN", "matanim", "shapeanim", and other sub-strings in the name. With some knowledge of how melee works and a little graphics programming background, an assumption can be made that "matanim" might have some thing to do with "MATerial ANIMations", "shapeanim" with "SHAPE ANIMations", and so on. But "joint" in particular usually mean a bone or some other skeletal or hierachy based node element. Following an offset of a root node that simply ends in "_joint", without any other sub-strings, may lead to a structure with a bunch of gibberish values that are not definite yet, but a patter emerges where there are a bunch of zero values separated by a series of three 0x3F800000 values. From know of hex values and their various representations, this sticks out as the float value 1.0f. Given the assumption that the information was joint/bone related, this could lead one to think of joint transforms and matrices, where a very common place to see a series of three 1.0f values would be as the scale factor of a transform. Looking through more similar structures may lead to the notion that these values appear to always be one, while the two sets of three values around them also seem to be valid floating point value with the eventual determination being that these are the rotation and translation portions of these components. Upon further inspection you may come across offsets within a common location within the joint structure that when valid also seem to point to other joint structures. Playing around and comparing values may lead one to consider these to be with next and/or child pointers to the joints that follow in the hierarchy.
From there it is a series of trial and error, or comparing again any other known information available, and so on until reasonable assumptions can be confirmed, denied, or otherwise.
OP
Tcll
Complexity == Fun >:3
- Thread Starter
- #455
KK well that tells me a bit...
but if you were a program trying to find the data,
how would you go about doing that??
that's what I'm trying to say...
I speak better in computer than english...
so almost everything you've told me there means nothing
I do know a little bit more about bones now though
but say you have a joint node...
what does that node do...
is it an offset to a location added to a particular number of offsets,
or does it define an offset list in the relocation table...
the relocation table in an mdl0 does the same thing...
but there's a "relocation table" in the header linking to specific parts of the real relocation table...
you see where I'm confused... :/
are the nodes associated with the relocation table in any way??
if not, then what do they do??
and how do you get verts, normals, faces, etc to be read accordingly??
how does the cpu know??
sry for tonza Q's
but if you were a program trying to find the data,
how would you go about doing that??
that's what I'm trying to say...
I speak better in computer than english...
so almost everything you've told me there means nothing
I do know a little bit more about bones now though
but say you have a joint node...
what does that node do...
is it an offset to a location added to a particular number of offsets,
or does it define an offset list in the relocation table...
the relocation table in an mdl0 does the same thing...
but there's a "relocation table" in the header linking to specific parts of the real relocation table...
you see where I'm confused... :/
are the nodes associated with the relocation table in any way??
if not, then what do they do??
and how do you get verts, normals, faces, etc to be read accordingly??
how does the cpu know??
sry for tonza Q's
OP
Tcll
Complexity == Fun >:3
- Thread Starter
- #456
well
I still don't know how to use the nodes
is it offset*node or what... IDK
anyways...
that's not what I came here to post about
I came here to post more useless knowledge about mdl0 files...
it seems they're not as similar to dat files as I thought
(literally EVERYTHING contains a header)
in the mdl0 header, there is (at most) 11 group offsets
1 group offsets to a specific point in the relocation table
in that offset is a header
(IDK too much abt this just yet, but I'm learning)
here’s the header so far:
0×00(4) = block length
0×04(4) = ??
0×08(4) = ‘FFFF0000′
0x0C(2) = ?? (’0020′,’0001′,’0002′,’0004′,’0008′(all I’ve found so far))
0x0E(10) = pad(10)
0x18(#) = data offsets
these offset to the actual datasuch as verts or whatever...
of course, each having it's own header
well...
there's my useless data
I'd like to get something accomplished on melee, but I currently don't know what to do to find the exact data type...
but whatever
I'll work on the mdl0 importer first, and modify that for the dat files
but if I could just find out how to use the nodes or whatever
IDK...
*mind spiraling out of control*
I still don't know how to use the nodes
is it offset*node or what... IDK
anyways...
that's not what I came here to post about
I came here to post more useless knowledge about mdl0 files...
it seems they're not as similar to dat files as I thought
(literally EVERYTHING contains a header)
in the mdl0 header, there is (at most) 11 group offsets
1 group offsets to a specific point in the relocation table
in that offset is a header
(IDK too much abt this just yet, but I'm learning)
here’s the header so far:
0×00(4) = block length
0×04(4) = ??
0×08(4) = ‘FFFF0000′
0x0C(2) = ?? (’0020′,’0001′,’0002′,’0004′,’0008′(all I’ve found so far))
0x0E(10) = pad(10)
0x18(#) = data offsets
these offset to the actual datasuch as verts or whatever...
of course, each having it's own header
well...
there's my useless data
I'd like to get something accomplished on melee, but I currently don't know what to do to find the exact data type...
but whatever
I'll work on the mdl0 importer first, and modify that for the dat files
but if I could just find out how to use the nodes or whatever
IDK...
*mind spiraling out of control*
GameWatching
New member
hey guys !
What's up ?
GameWatching
New member
btw,
your method still not working for me >_<
your method still not working for me >_<