Wind Waker Hacking Thread

[Sage of Mirrors]

 

YES. This is completely awesome in every way!

 

 

 

 

You may or may not see an example of what a hack could look like sometime soon...

[xdaniel]

Two more screenshots below... The first one I already wanted to post with the edit in my last post, but forgot about it. It's the Great Sea and all of its islands in their (*ahem*) full beauty:

 

 

Now, the second screenshot... well... I know this is technically "Wind Viewer", but as we know, there's so much similarity between them (excluding, say, collision) that it's just natural...:

 

 

Do note that this is not the build I posted above. TP support is rather sketchy in that one, and the BMD/J3Dx interpreter needed several fixes for bugs that didn't gravely affect WW, but were highly visible in TP... In fact, the interpreter still needs fixes as texture conversion tends to fail, coloring and translucency is often wrong, etc... but that's something for another day; this is primarily intended for WW after all.

[Jason777]

The great sea looks... pitiful. Still, pretty damn massive if you ask me.

[xdaniel]

Started a page about the DZx files on the wiki: http://wiki.spinout1..._GCN:_DZx_files

 

No idea if WW and TP are in the scope of the wiki, tho - it's called z64 wiki, after all. I'm basically waiting for a reaction from spinout. As my comment put it:

 

<!--

Yeah, not "z64" but Zelda and, unless you count the WW hacking thread at The GCN, not yet documented elsewhere AFAIK (and if it is, why the fuck have we been looking into this ourselves?), soo... okay to have this here?

 

Also, if it stays, SOOO MUCH TODO HERE >.<

-->

[Sage of Mirrors]

Well, I'm pretty sure STAG sets room properties, like item usage. I'm sure it might control some other things, too...

 

SCLS is definitely an exit list. There's only exits there.

 

There's a thing called EVNT? I'd better look at that!

 

 

By the way, Xdaniel, your release of Wind Viewer isn't going to waste! I've done a small little thing to demonstrate what it can do. I just haven't gotten around to filming it yet.

 

BINGO!

 

I've JUST discovered what event_list.dat is for! It... well... holds events! Events like camera movements, animations and text boxes that are too common to need an STB. Watch this:

 

 

I replaced the data under the heading AJ_SPEAK (the event that makes the old man on the balcony shout out to say 'L-Target Me!') with that of the heading called DEFAULT_RD_SCREAM (or was it 'ATTACK?'), making the game react as if Link had been within reach of a Redead's scream. I usually do this stuff without sound, so I'm not sure if the scream itself plays; I'll look into that in a moment.

 

Now, the petrified effect doesn't end. I'm pretty sure this has something to do with the fact that the Redead's AI controls this stuff...

 

Now, there's three sections within the Event_List.dat; a section that has the names of events within it (eg. AJ_SPEAK), a section that probably contains what these names go to and a third section with a purpose that I don't know yet. I think this is a pretty nice development! Maybe cut scene stuff ISN'T in the .stb, after all...

[Conker]

Wow, that's pretty cool, man!

[xdaniel]

For (I believe) the first time since I started hacking WW, I have actually changed something in the ISO. Everything else before was purely conjectural. And it's not even much I just did, I mapped some actors and parameters!

 

Name, then parameter:

Boko 00000000 = Boko Stick

Boko 00000001 = Bokoblin Machete

Boko 00000002 = Stalfos Club

Boko 00000003 = Darknut Sword

Boko 00000004 = Moblin Spear

Boko 00000005 = Phantom Ganon's Sword

 

[Sage of Mirrors]

Cool! I could see a few applications for that...

 

I also found something out. There a plethora of entries called 'kusax#.' Now, I found out that 'kusa' means 'grass' in Japanese, so I think it's obvious what they are now. The number differs from entry to entry, so I'm thinking that the number is how many pieces of grass are in a group. Theoretically, we might be able to change that number in-game by changing the name, but I haven't tried that yet.

[Secant]

I'm not so sure--it sounds a lot more likely that they just have varying arrangements of the grass kinds, from a generic circle to some of the more specific clump types, like the one that forms an arrow shape pointing to a crawlspace on one of the islands. Having an entry for the grass actor which has a single clump would be pointless--for the most part, I imagine they'd want at least 8 clumps in a single actor or so, to save space on actor data and entries on maps.

[Lishy]

Very excited about its progress!!

[Sage of Mirrors]

From looking at Event_List. dat files, here's what I've got figured out:

 

00 00 00 40 00 00 00 60 00 00 42 40 00 00 01 5E 00 00 AF A0 00 00 04 57 00 02 0A D0 00 00 05 2D 00 03 56 10 00 00 04 C6 00 03 69 28 00 00 02 37 00 03 72 04 00 00 07 D8 00 00 00 00 00 00 00 00

Every 8 bytes is a 'pair.' That is, the first four bytes are an offset to a section, and the second four are the number of individual entries in it.

 

The first pair point to the start of the 'header' section. EVNT from the .dzs files use the names of these headers to do events, but I'm not sure exactly what they do. There aren't any offsets in these headers (which are 0xB0 long), so I'm guessing that the engine might use some sort of indexing system to get the data related to these headers.

 

The second pair refers to what seems to be a large part of the file. This section contains entries 50 bytes long with names like CAMERA, TALKMAN, MESSAGE, TIMEKEEPER, DIRECTOR, PACKAGE and ALL, various actor names (Link, Bomb, Ship, ect.), and misc. stuff like 'Fire' and 'Zenfire.' Again, these have no offsets, so whatever the game uses these for it must use an index system. I have no idea what they could be for; instructions for the events, maybe?

 

The third pair marks a similar section to the pair above; entries here are still 50 bytes long, but have different names- I've seen WAIT, NEXT, COUNTDOWN, PAUSE, UNITRANS, MES_SET and TALK often, along with several others. No clue what they're for. More detailed instructions?

 

The fourth pair goes to yet another set of entries, these only 40 bytes long. They seem like the actual event commands- they use names like Stage, RoomNo, Layer, Startcode, MsgNo, Trim, Fovy, RelActor, RelUseMask, Center, Eye, Timer, TransType and BGCheck. Some of them sound camera-related.

 

The fifth pair introduces a different section. This has no ASCII. I'm guess this is either assembly or camera directions. Entries here are 4 bytes long.

 

The sixth pair is the same as the fifth- no ASCII. But this section is a bit more spread out (has more bytes that are just 00). Entries are also 4 bytes long.

 

The seventh and final pair indicate an... odd section. I have absolutely no clue what this is for. Some ASCII here includes (repeatedly) @PLAYER, @STARTER, @PARTNER, @TALKPARTNER and VISTA, with names of room folders, .stbs (some that don't exist, even) and other oddball things, like --or, --on, --tt, --oo, --oc and op, scattered around. There's probably some structure to this, I'm just not seeing it right now. This section is an exception to the the offset-entry number pair- in this case, the seventh pair indicates offset-length.

 

And there we have it. Stuff to look into, for sure, but now the main structure's documented.

 

 

I have just confirmed my suspicions- in each header, there are groups of 4 bytes that point to instructions in the second section of the file by their index. These bytes point to camera directions, Link's animations and possible other things, like player control and NPC animations.

 

Here's an example:

 

 

The ID for Link's 'Looking around' animation, which normally plays here, is 1D (and 62, I believe, though 1D might be a neutral pose). In the same .dat, the ID for Link's 'Telescope get!' animation (which comes with the telescope, apparently) is 1D7. By replacing only those two IDs, we change the animation Link does during this event- though, after his animation ends, it waits for Aryll's command to look out at their house, which never comes.

 

Now, camera and NPC animation is controlled in the same way. Text... I haven't gotten to that part yet, but one of the IDs in AJ_SPEAK leads to TALKMAN, which at some level holds the text pointer. I hope.

 

Speaking of levels, that's how Event_Lists work- The headers are the highest level, while op codes (I think?) are the lowest. Each entry at the second level has an index and IDs that lead to other entries in the third level, then that entry has an index and IDs to the fourth level. Then we get to the fifth level. At that point, you get a pair of bytes that probably translate to an op code and extension. What the sixth and seventh levels are for... I'm not entirely sure. Each header has a 'top' section, where most of the IDs I've seen are, and a 'bottom' section made up of 10 bytes boarded on either side by multiple FF values. I wonder if these ten bytes go to the sixth level?

[Sage of Mirrors]

 

So, here's what I've gotten in the realm of collision. I found a three-byte section that I thought was water collision in the .dzb for the room of the Tower of the Gods. But... it wasn't. It didn't do anything water-related.

 

These are the only things it affected, oddly.

 

I replaced all instances of C5 7A 50 with C5 9C 40. I don't know how this will help (if at all), but I'm worn out for now.

[Twili]

We know that WW Link's body is completely animated underwater, but did you know that his choking sound only plays when he's swimming on the surface of the water, but not when completely submerged?

 

 

More evidence that you were supposed to be able to swim underwater.

[Sage of Mirrors]

Hmm... that Dark Link person over on Jul introduced me to Framework.MAP. It seems to be a map of where EVERYTHING related to gameplay is stored, both somewhere (the .dol?) and what I believe to be RAM ('Virtual Address?'). With this information, I think we could begin making assembly hacks. Theoretically, anyway.

 

Kargaroc, where did you get that build of Dolphin that has a disassembler built in? Can I get a copy to test if these locations are correct? There isn't a 'Framework.rel' and I'm not entirely sure that these commands are in the .dol.

[Kargaroc]

Hmm... that Dark Link person over on Jul introduced me to Framework.MAP. It seems to be a map of where EVERYTHING related to gameplay is stored, both somewhere (the .dol?) and what I believe to be RAM ('Virtual Address?'). With this information, I think we could begin making assembly hacks. Theoretically, anyway.

 

Kargaroc, where did you get that build of Dolphin that has a disassembler built in? Can I get a copy to test if these locations are correct? There isn't a 'Framework.rel' and I'm not entirely sure that these commands are in the .dol.

 

run Dolphin with the -d argument and it should start in debug mode

[Sage of Mirrors]

Well, would you looky here...

 

// Message ID 0x355E, DAT1 offset 0x000735C9

<1A07FF00010096>Anchors aweigh!!!<1A07000004001E><end>

 

// Message ID 0x355F, DAT1 offset 0x000735E9

<1A07FF00010096>Hold the tiller steady!!!<1A07000004003C><end>

 

// Message ID 0x3560, DAT1 offset 0x00073611

As for our destination...<1A07000004003C><end>

 

// Message ID 0x3561, DAT1 offset 0x00073632

The wind will guide us!<1A07000004003C><end>

This is what Tetra says before she and Link go off in search of a new Hyrule. It's shown in the .thp, but that's obviously a recording- that means that this text is unused! I took a look, and there are two Demos that aren't used- Demo37 and Demo46. These are the ending (Link and Tetra on the surface, seeing Tetra's ship) and the epilogue (Link and Tetra leaving). So this proves without a doubt that they intended to handle the end and epilogue in the same manner as the rest of the cut scenes before something happened that made them change it to a .thp. I wonder what it was?

 

What's more is that the JMSG entry in the epilogue's STB points... to Niko's explanation of the first platform puzzle. Maybe the text was moved at some point?

[xdaniel]

Gonna leave this here for Kargaroc and his problematic archive:

 

₪ xdaniel (09 March 2012 - 12:19 PM) Alright, I'll look into it. Can't say when exactly i'll get to it, tho, as I won't be at home over the weekend

₪ xdaniel (09 March 2012 - 12:23 PM) room.dzr's ACTR chunk is broken, each entry is supposed to be 0x20 bytes long, but each one here has a 0x21st 00 byte

₪ xdaniel (09 March 2012 - 12:24 PM) Not to mention each entry is mostly composed of 0x2Es, or ASCII dots

₪ xdaniel (09 March 2012 - 12:25 PM) And the header says there's 0x0A actors, while the chunk only contains 6

₪ xdaniel (09 March 2012 - 12:27 PM) I'm guessing the game notices the problems as well, but just stops reading the ACTR chunk at that point

[Kargaroc]

Well, recently, a BDL converter was released that actually works! It's VERY basic right now, so it tends to look like crap ingame and it still looks like crap in the viewers, but atleast you can see it.

 

So, me and a few others on the talk page of WW on TCRF were attempting to convert the collision of the Alpha Forest to a BDL so it would load. Well, we were able to do that, for the most part.

 

Except for this little problem _[/sarcasm]

 

It seems that the Sketchup Alpha forest model has been scaled, and no longer matches with the collision.

 

Which brings up the question, how did the person who made the Sketchup model even convert it from a DZB?

 

As far as I know, no one has ever released a DZB converter of any kind.

 

I want to suggest making a quick and dirty DZB to OBJ converter with the old DZB Thingy code, though that would probably NEVER happen. Perhapse a OBJ exporter in Wind Viewer?

[SanguinettiMods]

 

 

Which brings up the question, how did the person who made the Sketchup model even convert it from a DZB?

 

As far as I know, no one has ever released a DZB converter of any kind.

 

I want to suggest making a quick and dirty DZB to OBJ converter with the old DZB Thingy code, though that would probably NEVER happen. Perhapse a OBJ exporter in Wind Viewer?

 

Twili was able to convert the alpha forest to OBJ because it was an old Maya file. (I believe that's how it worked, anyway)

[xdaniel]

The old Maya file =/= the alpha forest's collision. I do think, tho, that Twili put together his own program to export it to an .obj model or whatever. I might see about adding .obj exporting to Wind Viewer, can't say yet.

[Mallos31]

The old Maya file =/= the alpha forest's collision. I do think, tho, that Twili put together his own program to export it to an .obj model or whatever. I might see about adding .obj exporting to Wind Viewer, can't say yet.

He gave it to me since I use Maya a lot, and I ended up having someone at The Area convert it because Maya wasn't accepting the old format. The guy never gave me the script though. He said it was relatively easy to convert it to a .obj with a python script though.

[Sage of Mirrors]

Not Wind Waker, but interesting nonetheless:

 

 

 

The top image I ripped from Twilight Princess. The bottoms is for comparison. Looks like they planned to have a Mirror Shield in Twilight Princess! That, or this icon was used in some kind of test. Most likely the latter.

[Twili]

Not Wind Waker, but interesting nonetheless:

 

 

 

The top image I ripped from Twilight Princess. The bottoms is for comparison. Looks like they planned to have a Mirror Shield in Twilight Princess! That, or this icon was used in some kind of test. Most likely the latter.

 

You're nearly six years late, but good job.

 

[alphaheiti]

what do you guy´s think about this.

 

 

 

i maybe start a wind waker texture mod , nothing big but fun to make ;D

 

 

another screenshot

 

 

 

 

[Sage of Mirrors]

I've probably posted this before, but meh. We need some stuff here.

 

Event_list.dat. We've figured out that it's how the game handles less important cut scenes, such as what occurs when a Redead attacks you. Event_list controls camera movements and animations at the least, and it might control things such as item acquisition; however, it does NOT (from what I've seen) control text.

 

The file itself starts with a section of entries. These entries are B0 bytes long. They each begin with a name in ASCII, which seems to have 20 bytes allotted for it; this name can be referenced in a DZS file under the EVNT heading to be used in-game. The next 5C bytes are allocated for instruction index numbers (see below); each index number uses 4 bytes, and any unused space is nulled with FF bytes. The instructions in this section seem more related to animations and control lock-out, but it needs more investigation. The 18 bytes following the last section are more index numbers. These instructions seem to be geared towards camera movement, but again, more investigation is needed. Unused space is nulled with FF. The remaining 1C bytes are 00, with no functionality.

 

Beneath the index of entries, there are several sections of instructions. Like the ones above, these instructions begin with an ASCII name. Each instruction has an index number, starting from 0. This number is 25 bytes from the start of the instruction, and has 4 bytes allocated for it. The bytes after the index number seem to be more index numbers, seemingly for the section below. Those instructions are more specific, and each has an index number. Those have MORE numbers, for the section below them. I don't know how far this goes; at some point the instructions disappear and are replaced with ASCII-less bytes, possibly machine instructions.

 

After that, there's an odd section that leads up to the end. It has ASCII such as @PLAYER, @STARTER and @TALKPARTNER. I have no idea what this is for. The file ends with a list of the .stb files used.

 

So. Can anyone spare me some help in figuring out what the indexing is all about? I can't figure it out.