Archived M2K2 Forum
I do believe I've pretty much tried replacing all the multiplayer themes at least and a couple boss themes. Been trying to add the songs as new files too, using the world editor to change the StreamedAudio entities to play the new songs. It pretty much ended up with the same effect, crash or static on loop. I tested the original replacement attempts on both dolphin and on Wii via diosmios loader with no difference. Only tested the new files on diosmios. Should I attach a couple files I tested to see if you have better luck with them?
Go ahead and PM, it'll be worth investigating objective material.
I admit I didn't give RS03 much loop-testing within MP2.
Once I get some free time I'll try in dolphin, and account for loop-constraints I may have missed.
EDIT: RS03 has particularly tricky packing at the end of the stream, that could be the point of failure
I admit I didn't give RS03 much loop-testing within MP2.
Once I get some free time I'll try in dolphin, and account for loop-constraints I may have missed.
EDIT: RS03 has particularly tricky packing at the end of the stream, that could be the point of failure
trying to figure out how MayaSpline properties work in MP2/MP3/DKCR now. I'm reverse engineering the implementation in MP2 with some help from the symbols from Trilogy as well as Tropical Freeze (the MayaSpline implementation in DKCTF is actually really similar to the MP2 one, to the point that I can identify the same functions in both). My current understanding is it's a 2D hermite curve where X = Time and Y = Amplitude. Structure in the file is:
u8 - EInfinityType PreInfinity
u8 - EInfinityType PostInfinity
u32 - Knot Count
CMayaSplineKnot array
u8 - EClampMode ClampMode (0 = unclamped, 1 = clamped to min/max, 2 = something else? not sure yet, the code looks like it might be truncating the decimal portion)
float - Min Amplitude
float - Max Amplitude
(note I think the structure is different in DKCR, not sure about MP3)
Hoping to reverse engineer the code that constructs the curve and then write something to load and visualize the spline.
edit: also, on a side note, DKCTF has static functions for converting MayaSplines to/from text. Wonder why that's in there...
edit 2: the pre/post infinity values are probably the same thing that's described on this page: https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-619CAE9C-107D-4504-A769-227DDC847153-htm.html
u8 - EInfinityType PreInfinity
u8 - EInfinityType PostInfinity
u32 - Knot Count
CMayaSplineKnot array
u8 - EClampMode ClampMode (0 = unclamped, 1 = clamped to min/max, 2 = something else? not sure yet, the code looks like it might be truncating the decimal portion)
float - Min Amplitude
float - Max Amplitude
(note I think the structure is different in DKCR, not sure about MP3)
Hoping to reverse engineer the code that constructs the curve and then write something to load and visualize the spline.
edit: also, on a side note, DKCTF has static functions for converting MayaSplines to/from text. Wonder why that's in there...
edit 2: the pre/post infinity values are probably the same thing that's described on this page: https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-619CAE9C-107D-4504-A769-227DDC847153-htm.html
I just came up with an interesting theory on one of the unknown CMDL flags. Some models have the 0x1 bit set and others don't, and IIRC we've verified that it probably doesn't do anything (I think the model loading code ignores it?). I'm thinking now it might indicate that the model is skinned. I've taken a look through a bunch of random models and so far everything I've looked at lines up with that theory; all the models that have the flag are referenced from an ANCS file and all the models that don't have it aren't. Does anyone want to help verify this is correct?
I don't think the game uses it, but if that correlation is consistent that could be really useful for the tools to determine whether the model needs to be configured for skinning.
edit: welp found an exception, 6fa561d0 (elevator platform model). I guess either the correlation isn't completely correct, or the elevator had animations that weren't included on the disc for some reason.
I don't think the game uses it, but if that correlation is consistent that could be really useful for the tools to determine whether the model needs to be configured for skinning.
edit: welp found an exception, 6fa561d0 (elevator platform model). I guess either the correlation isn't completely correct, or the elevator had animations that weren't included on the disc for some reason.
Actually, I bet if you check all models used for platforms it's set. Platform models, or anything using waypoints to move, will probably have it set because it's probably a way to differentiate "dynamic" models from static, whether they use a world bone (defined by the actor's origin) or are rigged.
So I just ran into something pretty silly. There's one ANCS file, 23c00d8a.ANCS, that associates the Fusion Power Suit model with the CSKR for the regular Power Suit instead of the Fusion Suit one. It's for the "visor acquired" cutscene animation. The end result: the animation looks like this.
This happens ingame too if you sequence break to get one of the visors without any suits with the Fusion Suit on :P Miles found this a while ago and I forgot about it til now, haha
This happens ingame too if you sequence break to get one of the visors without any suits with the Fusion Suit on :P Miles found this a while ago and I forgot about it til now, haha
Oh god, wonder who was responsible for that goof during development?
BTW, has anyone figured out a way to find out which model (or models) an animation or skeleton file references, im searching for the CMDL Prime uses for its arm cannon world model (the one we see in cutscenes or the pause menu) and I just cannot seem to find it, so I figure another file must reference it and if it does I can do a search through my unpacked PAK's to see if I can find it. Or am I going way too OTT to find this one?
BTW, has anyone figured out a way to find out which model (or models) an animation or skeleton file references, im searching for the CMDL Prime uses for its arm cannon world model (the one we see in cutscenes or the pause menu) and I just cannot seem to find it, so I figure another file must reference it and if it does I can do a search through my unpacked PAK's to see if I can find it. Or am I going way too OTT to find this one?
The arm cannon world model is actually a weird exception- I don't think you're going to find any direct references in the ANCS files or object parameters, because AFAIK that model attachment is hardcoded as part of PlayerActor. Regardless, all the arm cannon world models are in TestAnim.pak. Specifically:
e88d10e1.CMDL - Power Beam
5596be79.CMDL - Wave Beam
87d38e46.CMDL - Ice Beam
1b4938ae.CMDL - Plasma Beam
ae89ab8c.CMDL - Phazon Beam
e88d10e1.CMDL - Power Beam
5596be79.CMDL - Wave Beam
87d38e46.CMDL - Ice Beam
1b4938ae.CMDL - Plasma Beam
ae89ab8c.CMDL - Phazon Beam
So, there's now a public Wii U exploit that works on the latest firmware, and it's actually pretty easy to get up and running... As a result, it's now possible to actually run edits you make to Wii U games, so I'm now a little more interested in doing more research on Tropical Freeze. Here's a dumb hex edit I did as a test.
I've mostly focused on understanding the ROOM format more fully right now. There's still a lot I don't know, but so far, wow it seems more different than I expected. First of all, there are no less than 376 layers in the first level 1-1. Yes, that's not a typo, there are 376 layers. Some of them are empty and a bunch of them have duplicate names (there are 15 layers named Pickups). So that's really weird and probably needs some more research, lol. I'd be questioning whether these are even supposed to be layers, except they're pretty clearly referred to as Layers by the fourCCs in various parts of the format (and by the symbols in the RPX). I'm mostly guessing based on what I've understood about the structure of the file, but it seems like the layers are organized into groups under something called load units... it's possible load units now serve a similar purpose to what layers did in the previous games and layers are used to group objects together? I'm completely guessing now, though.
The biggest change though is how the objects themselves are put together. It seems like objects are now referred to in the code as Game Object Components, and they aren't standalone anymore - each component seems to now explicitly represent one part of an object rather than an entire object in itself. Then there's one object type which is structured completely different from all the other ones, called just GameObject. GameObject components have no connections and no properties; they have a list of sub-components, then a bool (probably Active) and position/rotation/scale. The interesting thing is a lot of the component types are just the same ones we know from the older games (Relay, Timer, Counter, etc) but there's some new ones that are extremely generic, like Render, Static Collision, Health, among others. I'm hesitant to jump to conclusions without fully verifying it, but the impression I get is you can basically make your own objects by assembling the components you want and attaching them to a GameObject. If that's the case, then that makes the engine a lot more flexible, and I already really liked how flexible it was in the older games, heh.
Tropical Freeze also has the same deal that DKCR did with properties that are internally assigned default values, and it probably does the same thing where properties are excluded from the file if they match their default, so there are some very fun times ahead to actually get a functional editor up and running. I could probably reuse parts of the tool that I wrote for DKCR and the Primes, but a lot of it I'd have to rewrite from scratch because the code doesn't look like it's written the same way as in the older games, and the RPX format (the executable) seems a fair bit more complex than the DOL format.
Anyhow, I documented everything I've figured out on the wiki. If anyone's interested in more info, go check it out. The wiki also now has a full list of every component in the game that I got from going through the disassembled code in the RPX.
I've mostly focused on understanding the ROOM format more fully right now. There's still a lot I don't know, but so far, wow it seems more different than I expected. First of all, there are no less than 376 layers in the first level 1-1. Yes, that's not a typo, there are 376 layers. Some of them are empty and a bunch of them have duplicate names (there are 15 layers named Pickups). So that's really weird and probably needs some more research, lol. I'd be questioning whether these are even supposed to be layers, except they're pretty clearly referred to as Layers by the fourCCs in various parts of the format (and by the symbols in the RPX). I'm mostly guessing based on what I've understood about the structure of the file, but it seems like the layers are organized into groups under something called load units... it's possible load units now serve a similar purpose to what layers did in the previous games and layers are used to group objects together? I'm completely guessing now, though.
The biggest change though is how the objects themselves are put together. It seems like objects are now referred to in the code as Game Object Components, and they aren't standalone anymore - each component seems to now explicitly represent one part of an object rather than an entire object in itself. Then there's one object type which is structured completely different from all the other ones, called just GameObject. GameObject components have no connections and no properties; they have a list of sub-components, then a bool (probably Active) and position/rotation/scale. The interesting thing is a lot of the component types are just the same ones we know from the older games (Relay, Timer, Counter, etc) but there's some new ones that are extremely generic, like Render, Static Collision, Health, among others. I'm hesitant to jump to conclusions without fully verifying it, but the impression I get is you can basically make your own objects by assembling the components you want and attaching them to a GameObject. If that's the case, then that makes the engine a lot more flexible, and I already really liked how flexible it was in the older games, heh.
Tropical Freeze also has the same deal that DKCR did with properties that are internally assigned default values, and it probably does the same thing where properties are excluded from the file if they match their default, so there are some very fun times ahead to actually get a functional editor up and running. I could probably reuse parts of the tool that I wrote for DKCR and the Primes, but a lot of it I'd have to rewrite from scratch because the code doesn't look like it's written the same way as in the older games, and the RPX format (the executable) seems a fair bit more complex than the DOL format.
Anyhow, I documented everything I've figured out on the wiki. If anyone's interested in more info, go check it out. The wiki also now has a full list of every component in the game that I got from going through the disassembled code in the RPX.
Quote from Bearborg:
The arm cannon world model is actually a weird exception- I don't think you're going to find any direct references in the ANCS files or object parameters, because AFAIK that model attachment is hardcoded as part of PlayerActor. Regardless, all the arm cannon world models are in TestAnim.pak. Specifically:
e88d10e1.CMDL - Power Beam
5596be79.CMDL - Wave Beam
87d38e46.CMDL - Ice Beam
1b4938ae.CMDL - Plasma Beam
ae89ab8c.CMDL - Phazon Beam
e88d10e1.CMDL - Power Beam
5596be79.CMDL - Wave Beam
87d38e46.CMDL - Ice Beam
1b4938ae.CMDL - Plasma Beam
ae89ab8c.CMDL - Phazon Beam
So, if that is the location of those models in the first 2 games, where the heck did they go when Prime 3 released? I've been looking through places like the Logbook.pak but I can't seem to find them, which is slightly annoying as being able to take a look at these models (not just the arm cannon models) gives me an insight into how retro handled the first person to third person morph ball transition and how they set up their cut scenes.
So I think Retro screwed up some stuff on their texture cooker and didn't account for the block sizes + padding correctly, and I'm kinda wondering if you guys might know anything more about this
First MP2 Metroid5.pak 3bb2c034.TXTR is I8 32x64 with 4 mipmaps. I8 is 8 bpp and uses 8x4 blocks. The last mipmap is 4x8, so to fit the image data what should happen here is the texture should be padded to 8x8 (two 4x8 blocks). However, Retro seems to have either tried to use smaller padding values or they didn't account for padding at all - the last mipmap is (4*8 = 32) bytes instead of 64 so the bottom half of the image is completely missing. This is the only I8 texture in any of the games that goes below 8x4 so I haven't been able to confirm if this is a common problem with their I8 textures or if it's just this texture that got messed up somehow.
Secondly, starting in DKCR they seem to have screwed up the padding on every 4x4 block format. They are supposed to be 4x4 blocks but on all those formats (IA8, RGB565, RGB5A3, and RGBA8) mipmap sizes are padded up to 8x8 instead. The regular image data is correct and stored at the right resolution, and you can read/display it fine, but then the remainder 3/4 of the data for that mip is complete garbage data. Examples include L01_Volcano_Fireballs.pak 2315373c795aa411.TXTR (IA8), FrontEnd.pak 6d25fe2220e2a635.TXTR (RGB565), and L03_Ruins_ShipAttack.pak 13445b6e3506ea1a.TXTR (RGBA8). These formats are only screwed up in DKCR, they're fine in the Prime trilogy.
First MP2 Metroid5.pak 3bb2c034.TXTR is I8 32x64 with 4 mipmaps. I8 is 8 bpp and uses 8x4 blocks. The last mipmap is 4x8, so to fit the image data what should happen here is the texture should be padded to 8x8 (two 4x8 blocks). However, Retro seems to have either tried to use smaller padding values or they didn't account for padding at all - the last mipmap is (4*8 = 32) bytes instead of 64 so the bottom half of the image is completely missing. This is the only I8 texture in any of the games that goes below 8x4 so I haven't been able to confirm if this is a common problem with their I8 textures or if it's just this texture that got messed up somehow.
Secondly, starting in DKCR they seem to have screwed up the padding on every 4x4 block format. They are supposed to be 4x4 blocks but on all those formats (IA8, RGB565, RGB5A3, and RGBA8) mipmap sizes are padded up to 8x8 instead. The regular image data is correct and stored at the right resolution, and you can read/display it fine, but then the remainder 3/4 of the data for that mip is complete garbage data. Examples include L01_Volcano_Fireballs.pak 2315373c795aa411.TXTR (IA8), FrontEnd.pak 6d25fe2220e2a635.TXTR (RGB565), and L03_Ruins_ShipAttack.pak 13445b6e3506ea1a.TXTR (RGBA8). These formats are only screwed up in DKCR, they're fine in the Prime trilogy.
Quote from Parax:
Secondly, starting in DKCR they seem to have screwed up the padding on every 4x4 block format.
Not that I know much about reverse engineering, doesn't this usually mean 'you're going about it wrong' and not the original person?
Not to sound like a dick though. I would just think that maybe I'm starting off wrong somewhere/something has changed if information previously known true to me was ringing false 10 times out of 10.
Nope. This is stuff that's consistent across all GC/Wii games - what I said is backed up by both the official and unofficial documentation. There's also the issue that if I -did- have that info wrong for whatever reason, I wouldn't be able to decode the images correctly because the block sizes are essential to unswizzling them correctly. Also, the fact that the extra data in the file is uninitialized garbage data and not valid image data is another clue that it's something they did wrong.
My guess as to what happened is Retro used a tool from the GC/Wii SDK to compress the textures, and then their cooker opened the resulting file and copied the image data out one mipmap at a time to paste into the TXTR files. Their tool would have had to calculate the size of each mipmap accounting for padding in order to know how much data to copy, and it seems they had the block sizes wrong so they calculated the wrong size. If that's what happened, then it explains why the actual image data itself is correct despite being the wrong size. It's also understandable they wouldn't have caught the mistake since it only affects the lowest-level mipmaps on a very small minority of textures and it's not something that would really show up ingame at all.
Now, why they would have changed it to incorrect values when they already had it right in the Prime series is beyond me. They might've rewritten the texture cooker in between MP3 and DKCR.
My guess as to what happened is Retro used a tool from the GC/Wii SDK to compress the textures, and then their cooker opened the resulting file and copied the image data out one mipmap at a time to paste into the TXTR files. Their tool would have had to calculate the size of each mipmap accounting for padding in order to know how much data to copy, and it seems they had the block sizes wrong so they calculated the wrong size. If that's what happened, then it explains why the actual image data itself is correct despite being the wrong size. It's also understandable they wouldn't have caught the mistake since it only affects the lowest-level mipmaps on a very small minority of textures and it's not something that would really show up ingame at all.
Now, why they would have changed it to incorrect values when they already had it right in the Prime series is beyond me. They might've rewritten the texture cooker in between MP3 and DKCR.
I would think that it would be a tool refactor and someone accidentally used the wrong constant than the calculation itself being wrong, the algorithm is pretty straight forward and hard to mess up, a constant is easy to goof though. So that backs up what Parax is thinking.
Also, I have to agree with Parax again, it's highly unlikely our tools are wrong, since Parax, Jack, and I have all come to the same overall implementation independently using official and unofficial documentation, it's either we're *all* wrong, or retro goofed, which seems more likely?
Also, I have to agree with Parax again, it's highly unlikely our tools are wrong, since Parax, Jack, and I have all come to the same overall implementation independently using official and unofficial documentation, it's either we're *all* wrong, or retro goofed, which seems more likely?