Edit history:
Aruki: 2015-02-05 11:12:05 pm
Aruki: 2015-02-05 11:11:09 pm
Aruki: 2015-02-05 08:42:40 pm
Aruki: 2015-02-05 08:40:24 pm
Aruki: 2015-02-05 08:19:06 pm
Aruki: 2015-02-05 07:46:24 pm
Aruki: 2015-02-05 07:44:49 pm
Aruki: 2015-02-05 07:42:26 pm
Aruki: 2015-02-05 07:41:23 pm
Aruki: 2015-02-05 07:19:42 pm
Aruki: 2015-02-05 07:17:51 pm
Aruki: 2015-02-05 07:09:47 pm
Aruki: 2015-02-05 06:48:50 pm
Working on implementing the ANCS dependency parsing that I said I was going to do four days ago. >.>
I've just parsed the first table in 8169653a.ANCS. Just wanted to post that I've found out Skippy's incorrect about type 3 being null. It's like type 4 in that it contains a number of substructs. It's structured like:
The funny part is that I'm seeing a lot of type 3s that contain type 4s which contain type 0s... there's definitely some level of recursion, lol.
dump of the contents of the first footer table in 8169653a.ANCS
I'm finding it kinda confusing to follow all the posts here to understand the format, lol. Will put some info up on the wiki once I've got this working properly.
edit: Running into a problem. In the second table in this file, at 0x1633A, the table entry has type 0 marked, but there's an extra long before the anim ID. Any idea, Skippy?
edit 2: I think I figured it out... the struct types in the second table aren't the same types as the one from the first table. 0 is a container (guess) - long type, struct thattype. 1 and 2 are the ones we already know. 3 is null, like Skippy said. I seem to have been able to parse the second table correctly by doing that.
edit 3: Oh I think Skippy already mentioned something like this.
edit 4: There was another piece missing of the third table. In the long/float/float/long, the first long is another count value which is followed by a number of 12-byte-long structures. That count/table is in every file, while the second one (after the floats) is only in 3/4. The ANIM/EVNT pairs are only in 4. I've been able to parse the whole file now, and I'm running it on other files as well with no issues so far.
Do you think you could point me to where this code is in the demo disassembly, Skippy? I've got most of the functions labeled so I might be able to find what some of this data actually is. Also, how many unknown struct types are there, if you know?
edit 5: I've added this stuff to the dependency parser. No issues encountered, at least for Metroid1.pak! All ANIM and EVNT files are now accounted for! I think what the parser is mainly missing now is A. a few script objects and B. some stuff in particles. Once it successfully detects every file, the next challenge will be to figure out how to trim the unnecessary duplicates.
edit 6: just throwing out there.. wonder if these ending tables might be specifying animation blends? It definitely seems to be an animation sequence of some sort at the very least. The entries that have multiple animations listed seem to be animations that you'd expect to play sequentially:
edit 7: also I hate when I get to the point of editing my posts this many times
I've just parsed the first table in 8169653a.ANCS. Just wanted to post that I've found out Skippy's incorrect about type 3 being null. It's like type 4 in that it contains a number of substructs. It's structured like:
Code:
u32 count;
for (count) {
u32 StructType;
struct that type
u32 unknown;
}The funny part is that I'm seeing a lot of type 3s that contain type 4s which contain type 0s... there's definitely some level of recursion, lol.
dump of the contents of the first footer table in 8169653a.ANCS
I'm finding it kinda confusing to follow all the posts here to understand the format, lol. Will put some info up on the wiki once I've got this working properly.
edit: Running into a problem. In the second table in this file, at 0x1633A, the table entry has type 0 marked, but there's an extra long before the anim ID. Any idea, Skippy?
edit 2: I think I figured it out... the struct types in the second table aren't the same types as the one from the first table. 0 is a container (guess) - long type, struct thattype. 1 and 2 are the ones we already know. 3 is null, like Skippy said. I seem to have been able to parse the second table correctly by doing that.
edit 3: Oh I think Skippy already mentioned something like this.
edit 4: There was another piece missing of the third table. In the long/float/float/long, the first long is another count value which is followed by a number of 12-byte-long structures. That count/table is in every file, while the second one (after the floats) is only in 3/4. The ANIM/EVNT pairs are only in 4. I've been able to parse the whole file now, and I'm running it on other files as well with no issues so far.
Do you think you could point me to where this code is in the demo disassembly, Skippy? I've got most of the functions labeled so I might be able to find what some of this data actually is. Also, how many unknown struct types are there, if you know?
edit 5: I've added this stuff to the dependency parser. No issues encountered, at least for Metroid1.pak! All ANIM and EVNT files are now accounted for! I think what the parser is mainly missing now is A. a few script objects and B. some stuff in particles. Once it successfully detects every file, the next challenge will be to figure out how to trim the unnecessary duplicates.
edit 6: just throwing out there.. wonder if these ending tables might be specifying animation blends? It definitely seems to be an animation sequence of some sort at the very least. The entries that have multiple animations listed seem to be animations that you'd expect to play sequentially:
Quote:
TYPE 0: ddc07e1a.ANIM - A_intoleanstandl_pirate
TYPE 0: 66ff3245.ANIM - A_leanstandl_pirate
TYPE 0: e03ac5a.ANIM - A_outofleanstandl_pirate
TYPE 0: 66ff3245.ANIM - A_leanstandl_pirate
TYPE 0: e03ac5a.ANIM - A_outofleanstandl_pirate
edit 7: also I hate when I get to the point of editing my posts this many times