Jump to content

Wind Waker Hacking Thread


xdaniel
 Share

Recommended Posts

EDIT: I just realized... I posted stuff in the wrong forum... Really. I got carried away with the beta stuff, and I meant to post it in the Cutting Room Floor forum, but I put it in here instead.

So...umm... oops xP

EDIT 2: Since the original text was lost due to my stupid-ness >.< and I was banned from their forum for some reason, I will put a condensed version here.

Basically, Room 19 definitely isn't the boss room, because the real beta boss room (sadly not on the disk) looks much bigger and has a slightly different design (I came across this beta picture of it).

 

EDIT 3: Something I just realized, is that we don't have a minimap viewer. Currently the only way to view them is replace the minimap of a normal place with the map in question.

Link to comment
Share on other sites

Posted Image

Heh. It uses 0x0A to determine line breaks, it seems. Argh! It's midnight on a school night! How terrible is that? I need to go!

(At least I'm a hacker now...!)

 

It's morning, so I'll add one more thing:

 

4C 69 6E 6B 00 00 00 00 FF FF 00 14 05 00 00 00 46 20 84 00 C6 27 B0 00 00 56 80 00 FF 00 FF FF

These are the values for the PLYR I put in room19. Here's what I came up with when figuring out positions:

 

-0x46, 20 and 84: Z (Up and Down); changing 46 makes the actor move a very large amount, while chaning 20 makes it move only a little. Changing 84 is an even smaller change. For this, the format may be that the 17th, 18th and 19th bytes control up and down position.

 

-0xC6, 27 and B0: X? (Left and Right): Same format as above- first moves a lot, second a little, third even less. Might generally be 21st, 22nd and 23rd bytes. (Changing the 00 between Z and X didn't do anything, so maybe it's a way for the game to determine what's what.)

 

-The second 0x00 after 0xB0, the 0x80 after 0x56 and the 0xFF after the second 0x00 control rotation; changing 0x00 rotates the object backward and forward, changing 0x80 spins it left and right, 0xFF spins clockwise and counterclockwise. 0x56 and the second 0x00 don't change anything. Might be the 25th, 27th and 29th bytes for all files.

 

Now, I have to go to school, so I'll finish this later. Right now, though, I can't seem to find the values for Y (forward and backward).

Link to comment
Share on other sites

The position values are IEEE-754-style 32-bit (single-precision) floating-point values, where ex. 1.0 would be 0x3F800000. You can convert back and forth between their floating-point and hexadecimal representations using the calculators here: http://babbage.cs.qc.edu/IEEE-754/

 

Rotations are likely the same as OoT/MM's, signed 16-bit shorts from -32768/0x8000 to 32767/0x7FFF, which you can divide by ca. 182.0444444 to get their rotation in degrees.

 

[Actor name (8 bytes, ASCII)] [Parameters (4 bytes) ??] [X/Y/Z position (4/4/4 bytes, 32-bit floats)] [X/Y/Z rotation (2/2/2 bytes, 16-bit shorts)] [Actor number in room (2 bytes) ??]

 

EDIT: An eternal struggle with several BMD files, some documentation on the file format and the BMDview2 source later...

 

Posted Image

 

Posted Image

 

The randomly colored highlight in the first screenshot is the dzb file's collision, which TP doesn't appear to have (so no collision in the second shot)

 

EDIT 2:

 

http://magicstone.de/dzd/random/WWViewer_v002.rar (Win32 binary + source)

Edited by xdaniel
Link to comment
Share on other sites

Heh. It uses 0x0A to determine line breaks, it seems.

That's the most reasonable text format in a game that I've ever heard. Standard line breaks are 0x0A == '\x0a' == '\n'. Windows, of course, breaks this rule for some stupid reason and does "\r\n".

 

xdaniel: Looking good, as usual.

Link to comment
Share on other sites

Alright, implemented texture wrapping, filtering (tho with somewhat broken mipmapping), blending modes, alpha compare and culling - again mostly thanks to BMDview2 -, some of which can be seen in the following screenshot:

 

Posted Image

 

Not sure what I'll look into next - some texture coordinate glitches and fixing up the incorrect hierarchy usage (ignoring translation/rotation/scaling right now, which makes Outset Island's ground separate from its walls and houses -.-) - tho I really need to go over my awful code and rewrite it as well...

Link to comment
Share on other sites

I still can't believe that I was able to make room19 to load. I feel excited!

Now I'm trying to figure out a way to see it in it's own group, with correct environment settings and whatnot. I'm thinking an AR code, but it might also be possible to see it through the debug menu that's been discovered. I'm also looking to see room20 in M_dai, a beta version of the first room in the Earth Temple.

Link to comment
Share on other sites

SanguinettiMods: I suppose it's slowly approaching an OZMAV2-like level, at least for WW (but only as TP's mostly untested). And I wouldn't rule out .obj dumping, but that's not an immediate concern for me right now - for now, improving/rewriting the BMD parser is more important, not to mention bugfixes and such.

 

Sage of Mirrors: I think the level select menu doesn't have the unused dungeon rooms on it, but maybe the menu itself can be hacked to load them, ex. replacing one of the used rooms with a reference to an unused one, tho I'm not sure how.

 

Edit: HA! Excuse my French, but fuck yeah!!

 

Posted Image

  • Like 1
Link to comment
Share on other sites

Right, let's see, I mentioned rewriting the BMD parser, didn't I... I started rewriting it in C# as opposed to C. It's much cleaner already, but of course not yet on the level of its C incarnation, let alone BMDview2 - I'm about to get to SHP1 parsing, so that I'll see actual primitives again, and not just a bunch of gray points. And you know, considering this "language shift", it kinda seems like I'm mainly using C nowadays to prototype things, proof-of-concept-ish, while coding actual programs and such in C#.

 

Anyway, Arcaith: Texture dumping will be the first thing I'll see about implementing when I get to dumping things, seeing how easy that should be. Models we'll see about, as it's not an immediate concern as mentioned above (especially now).

 

EDIT: Time of day, 6:10 am. Reason for staying up: the C# BMD parser and renderer. Result: I think I deserve some sleep, all things considered:

 

Posted ImagePosted Image

 

Finally my code's very close to BMDview2's visual quality :D

Edited by xdaniel
Link to comment
Share on other sites

Posted Image

 

Damn, that's quite an improvement over OoT's textures, isn't it? Anyway, as you might be able to guess, texture dumping is in and working. What's quite a problem, and the main reason why I'm not releasing this version yet, is crashes and broken geometry with many different models (E3 Outset Island, some of WW's items like the Hookshot, etc.). It often tries to read primitive data beyond the end of the chunk, which is of course a dumb thing to do... Not all previously untested models break it, tho:

 

Posted ImagePosted Image

Link to comment
Share on other sites

Nah, don't drop OoT just yet, hacking WW and TP effectively is still quite a while off. Viewing stuff might be possible somewhat easily by now, editing on the other hand is still a hex editor affair.

 

That said, C# Wind Viewer has been improved some more, resulting in much less broken geometry or crashes (did I mention how annoying BMDs/BDLs are to work with?) and built-in RARC archive support - you can now simply open up a RARC file, Yaz0-compressed or not, the program reads its structure, and automatically renders all models it can find within. Each one can also be toggled on and off, which is useful for archives containing ex. item models, or for when there's still rendering or translation/rotation bugs:

 

Posted Image

Link to comment
Share on other sites

Interesting fact of the day: If you don't have the bow when you start the Gohdan fight, he sneezes out green rupees instead. Weird.

I was messing with the exits, and I made the exit to one of Outset's islands the Tower boss room. Now I'm going to try replacing room19 with the boss room.

 

 

It seems that stage.arc files (found in the same folders as the map arcs) hold the data for misc stuff that doesn't fit into the .bdl or the .dzr, like doors. But I've also found another file in the stage.arc called stage.dzs. It has the same format as the dzr (Chunk headers that give the number of individual blocks and the offset of the first block, followed by the actual information). These have unique headers, and the headers in SirenB's stage are as follows:

-STAG (No idea, contains one data segment)

-RTBL (No idea, contains one data segment)

-SCLS (This one doesn't make sense. It has two exits, one that is headed to the main Siren folder and one that's directed to itself, the SirenB folder. Huh???)

-FLOR (Literally the number of floors? Inside Forest Haven has only one of these, while TotG has 4 and Forbidden woods has 5. Might be, as a quick look-up of the two dungeons shows that they have the same number of floors as they do segments in the FLOR chunk)

-TGDR (Unknown, has one data segment)

-MULT (Unknown, one data segment)

-DMAP (Unkown, one data segment)

-EnvR (Unkow)

-Colo (Lighting/time of day)

-Pale (Fog)

-Virt (Fade distance, I assume. Makes the surroundings gradually fade to black, while keeping geometry visible)

-RCAM (Unkown, one data segment)

-RARO (Unkown, one data segment)

There are also some misc. stuff that's I've come across:

-EVNT (Cutscenes?? The data here has stuff like 'meet_deku,' 'getperl_deku' and 'BOSS_WARPOUT' for Inside Forest Haven)

-LGHT (Gee, I wonder if this is Light? :D)

-PATH (No idea.)

-AROB (No clue!)

-PPNT (No clue)

I'm thinking that most of these (such as EnvR and Colo) might deal with environmental things, like fog and particles such as the ashes in Dragon Roost Cavern and forest debris in both the Forbidden Woods and Forest Haven (might be prudent to cross reference those two to see if they have anything similar; might lead to knowing which header controls those particles). No clue what the others could be.

Link to comment
Share on other sites

.bck files - ID/type "J3D1 bck1", see first 8 bytes of .bmd/bdl and related files - probably contain animations, stored in an ANK1 chunk. That said, Wind Viewer C# is currently 100% broken, as I've been trying for two days to get the models' hierarchy to load and render correctly. Every model has a hierarchy, as simple as it may be, including the actual level maps, which is where the broken positioning of Outset Island in early screenshots/C builds came from. I got that "fixed" or "working" for part of Outset and maybe one or two more models, but everything else was garbage with level elements all over the place, let alone character models. I've been working with what's a somewhat simple hierarchy, the little crabs that run around the beach (Object\Kn.arc), but even after countless hours, I'm not much further:

 

BMDview2 left, Wind Viewer C# right:

 

Posted ImagePosted Image

 

You can kinda sorta with some imagination see a resemblance of a proper skeleton between karada and ashiL, but that's about it so far... I really hate skeletal systems. Who needs animation and shit when you can have something nice and permanent and static? /sarcasm

Link to comment
Share on other sites

Freaking finally.

 

Posted ImagePosted ImagePosted ImagePosted Image

 

Do note there still appears to be positioning glitches with certain models, but overall the skeletons are read and translated/rotated/scaled much, much better now. However, there's also still a big problem with most actor models apparently not loading correctly, which I haven't yet tried to figure out. I think it's obvious that something's wrong here...:

 

Posted Image

Link to comment
Share on other sites

Looks like Old Man CNJHWRUT3IFJY!

 

I've actually been on a quest of my own. I'm trying to figure out the structure of .rarc files so that I can add the sky model from Hyrule (the one that looks like the surface) along with its .btk to Outset's archive to see if I can make other maps have it. I was actually kind of miffed when I found out it was an actual model and not a set of values in the .dzs XP

Link to comment
Share on other sites

Been playing around with the audio recently. I've learned that the .afc files in the Stream folder are tracks played during cutscenes and the title screen. I believe that the .bms files held in the JaiSeqs.arc are the tracks played in playable areas of the game; these seem to use the .aw files, which store sound files like enemy voices and even instruments (there's a program to extract them, but sadly there isn't any documentation). The game can only use files from a .aw that it has loaded (duh), but I'm not sure how it decides which ones to load; I'm looking into the .dzr and .dzs files to see if sndpath has anything to do with it.

 

Edit: In the file called d_a_tag_event.rel:

Bk.mo2.dragon.SUPERELF.fairy_flag_on_Jmp.fairy_Jmp.BEAST_GATE2
SUPERELF! lol. Must mean the Fairy Queen. Wonder what this file does? The rels have no ASCII, aside from the rare things like this. Maybe they're actor scripts?
Link to comment
Share on other sites

Posted Image

 

And the glitches you can still see there are most likely because I don't support weighted/skinned matrices yet. That looks a bit more complicated - as if normal matrices weren't complicated enough! - so I didn't yet try to get those going. It wouldn't even have made sense so far, considering even said normal matrices were never 100% correct, and I'm still not completely sure they are now. They seem to be correct, considering non-weighted models (like that damn crab - I've seen it so many times over the last week, I'm sick of it) and stage models (at least Outset Island, Forsaken Fortress exterior, Windfall Island, Forest Haven exterior) look pretty much perfect(?), translation- and rotation-wise. Texturing, colors, etc., etc. are something else of course, but the general shape is correct for those now.

 

Also, also still broken because of the weighted matrices, have some Link and Tetra/Zelda:

 

Posted Image

Posted Image

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.