Jump to content

Wind Waker Hacking Thread


xdaniel
 Share

Recommended Posts

Tools:

Wind Viewer (C# .NET), map viewer and editor, binary and source: http://magicstone.de...orEdit_full.rar

WW Text Viewer (C# .NET), message file viewer, binary and source: http://magicstone.de...om/WWText_2.rar

 

Documentation:

.dzr and .dzs files: http://wiki.spinout1..._GCN:_DZx_files

.stb cutscene files: http://wiki.spinout1..._Cutscene_Files

Partial .dzb documentation: http://www.the-gcn.com/topic/627-wind-wakers-alpha-forest/ and later on in this thread

 

(More infos and older tools in the original post in the spoiler...)

 

 

Seeing Kargaroc mention actor replacement on the Shoutbox, I think we should have ourselfs a little Wind Waker hacking thread to channel our knowledge and findings somewhere. Not that I know much about it yet...

 

For one, there's Twili's partial .dzb documentation for WW's collision models in this thread: http://core.the-gcn....s-alpha-forest/ - Based on that, I hacked together a .dzb collision viewer for the game: http://magicstone.de...indWakerDZB.rar (Windows binary + source)

 

Improved .dzb and .dzr viewer "Wind Viewer", release 2: http://magicstone.de...Viewer_v002.rar (again Win32 binary + source, requires libMISAKA, curses, etc; OZMAV2-style console interface) - supports .dzr, .dzb and .bmd/.bdl (to an extend)

 

Wind Viewer, .NET rewrite (1st build): http://magicstone.de...ActorEdit_1.rar (Win .NET binary; no source yet)

 

WW Text Viewer (2nd build): http://magicstone.de...om/WWText_2.rar (Win .NET binary + source)

 

Next up, some unverified things about the .dzr files, in which ex. actors are stored. Those files are made of different chunks of data, each of which has a kinda header that contains an ID in ASCII (4 bytes), gives the amount of (whatever)s in the chunk (4 bytes), plus the (whatever) data's offset in the .dzr file (4 bytes). The file starts with the amount of chunk headers (4 bytes), followed by the first header.

 

Chunk types (only a few of them so far):

 

SCLS ("???"), 12 bytes per entry: Exit definitions.

FILI ("File Information"?), 8 bytes per entry: no idea what's in there.

LBNK ("L?? Bank"?), 1 byte per entry: Again, no idea what those are.

RPAT ("Room Pattern"?), 12 bytes per entry: Once more, no idea.

RPPN ("Room Position Points"?), 16 bytes per entry: Points probably used for actor paths (waypoints, basically).

PLYR ("Player"), 32 bytes per entry: Player actor definitions.

ACTR ("Actor"), 32 bytes per entry: Other actor definitions.

SCOB ("???"), 32(?) bytes per entry: Also appears to follow the actor data format, no idea what kinda actors are in here, tho.

SOND ("Sound"?), 28 bytes per entry: Not sure, tho E3ROOP's lone entry here has the ASCII "sndpath" at the start...

RCAM ("Room Camera"?), 20 bytes per entry: Again, not sure, E3ROOP's entry says "DungeonUp" at the start.

RARO ("Room ???"?), 20 bytes per entry: No idea, no readable ASCII in there.

2DMA ("2D Map"?), 56(?) bytes per entry: Likely defines stuff for the on-screen map, don't know for sure.

 

Notes by Sage of Mirrors (chunks, possible cutscene infos, text control codes):

http://core.the-gcn....dpost__p__12235

http://core.the-gcn....dpost__p__12564

http://core.the-gcn....dpost__p__12697

 

TP chunk notes by fkualol:

http://core.the-gcn....dpost__p__12039

 

SCLS, exit definition format (incomplete):

- [Target map name (8 bytes, ASCII)] [Parameters (4 bytes) ??]

(...parameters unknown, probably control which entrance to use on the target map?)

 

ACTR, actor definition format (really incomplete and unverified):

- [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) ??]

(...looks correct, not really confirmed yet.)

 

RPPN, point definition format (also incomplete):

- [unknown (4 bytes)] [X/Y/Z position (4/4/4 bytes, 32-bit floats)]

(...also looks correct, also... you know)

 

So, yeah, I guess I'll try to verify some of the stuff I posted, feel free to chip in with anything you know or can deduce or whatever.

 

Edited by xdaniel
Link to comment
Share on other sites

None of this is my work and I either got it from google or from Kargroc himself (he can let me know if he objects to me posting this and I will remove it of course):

http://www.gekinzuku.com/forums/index.php?topic=1458.0

http://www.amnoid.de/gc/

Quote from Kargaroc:

First, I used a combination of a few programs to get the 3DS model converted to a OBJ model with UV maps. I used a program called Accutrans3D to convert the 3ds to a obj with uv maps. However, that obj will not import to SharpOcarina properly. So I used a program called Poseray to fix the OBJ. Once you do that, it should open in SharpOcarina.

I made a 7z archive that has all the tools you will need, as well as a txt file for how to use the programs (well, except for Poseray and Accutrans3d, which I didn't put into the archive until after I wrote the readme. Link: http://dl.dropbox.com/u/16672629/Zelda_GC_stuff.7z

Link to comment
Share on other sites

Posted Image

 

E3 Outset Island's collision and ACTR chunk actors (partially, might be incorrect). Will put the program and source up soon-ish, tomorrow or so.

 

Edit, comparison shot:

 

Posted Image

 

This is impressive, say, if you find out more about wind waker's code would you be able to (if not already) move around or replace actors?

Edit:

This is something very interesting, it seems people have discvered a way to import wind waker stages into SMG2 i dont know if this is much help but if someone is able to discover how they did it, it would explain more of wind wakers code.

 

Link to comment
Share on other sites

Wind Viewer v0.0: http://magicstone.de/dzd/random/WindWakerDZB_2.rar

 

Posted Image

 

Source requires libMISAKA (and in turn curses, just check the CB project file) to build, because of the OZMAV2-style console system. On the plus side, it should also build under Linux.

 

Console commands:

- loaddzb <filename>: Load .dzb file to use

- loaddzr <filename>: Load .dzr file to use

- help: What you just read, basically

 

Controls:

- Mouse: Camera direction

- WASD: Move camera slowly

- TFGH: Move camera really quickly

- F1/F2: Cycle through players

- F3/F4: Cycle through actors

- F5/F6: Cycle through points

- F9: Toggle random polygon colors

- F12: Toggle HUD

- ESC: Take a guess

Edited by xdaniel
Link to comment
Share on other sites

None of this is my work and I either got it from google or from Kargroc himself (he can let me know if he objects to me posting this and I will remove it of course):

http://www.gekinzuku...hp?topic=1458.0

http://www.amnoid.de/gc/

Quote from Kargaroc:

First, I used a combination of a few programs to get the 3DS model converted to a OBJ model with UV maps. I used a program called Accutrans3D to convert the 3ds to a obj with uv maps. However, that obj will not import to SharpOcarina properly. So I used a program called Poseray to fix the OBJ. Once you do that, it should open in SharpOcarina.

I made a 7z archive that has all the tools you will need, as well as a txt file for how to use the programs (well, except for Poseray and Accutrans3d, which I didn't put into the archive until after I wrote the readme. Link: http://dl.dropbox.co...lda_GC_stuff.7z

 

Note: That PM was meant for Ocarina of Time hacking, as it walked you through the steps required to convert a Wind Waker model into something readable by SharpOcarina. For Wind Waker hacking, I'm not sure any program exists that can convert a model into a BMD.

 

For the actor replacement, I just found where the actors were in the DZR (it's easy; the actors are identified by their names), and replaced the name with another, and if it's shorter than the original, filling in the left over space with 00s.

 

I am only able to do this currently with non-Yaz0'ed DZRs, as I don't know of a packer that can create a archive that it will accept. That's how I figured out how to remove actors en masse; one time I tried to replace the (what else?) Kargaroc's model with the one from TP, and the result was the actor wouldn't load at all. It wouldn't crash the game though, it would just "remove" them from the game.

 

EDIT: well, I guess I could post the video I made for deviantart...

Link to comment
Share on other sites

Not sure if these are also in WW... too lazy to check. But anyways:

 

REVT - Cutscenes (0x1C bytes per entry)

TRES - Treasure Chests (same format as ACTR, 28th (0x1C) byte defines the item value )

Door - Guess. (0x24 bytes per entry, similar format to ACTR. First 8 bytes ASCII name, 4 bytes parameter, 12 bytes X/Y/Z translation (32-bit float), not entirely sure about the rest.)

 

Note that this is from taking a look at Twilight Princess' dzr files, and may or may not be similar to Wind Waker's.

 

I'll edit this post once I re-figure out the data. I never bothered documenting anything in plain text because I thought no one would ever have any interest in hacking Wind Waker/Twilight Princess.

Link to comment
Share on other sites

Started writing a BMD model parser...

 

Posted Image

 

That's supposed to be E3 Outset Island - pier in the lower right, the tower on the left, forest in the top right. Recognizable, but still a long way to go.

 

EDIT, two hours later:

 

Posted Image

 

Final Outset Island this time - much more recognizable, huh?

Edited by xdaniel
Link to comment
Share on other sites

fkualol: I suppose so:

 

Posted Image

 

The DZR format is identical between the two games (plus eventual additional chunks that TP has and WW doesn't), but TP doesn't seem have DZB files? Also, the BMD parser and renderer is still junk. Well, that's probably obvious from the screenshot...

 

Sage of Mirrors: If you can get the DZR back into the game - which I actually haven't tried yet at all - you could add one to the chunk count (offset 0x0, 4 bytes), add a PLYR chunk to the list (so "PLYR <player count, 4 bytes> <data offset, 4 bytes>"), add the actual player actor data to the end of the file, and fix the offsets in the other chunk definitions to accommodate for the added 12 bytes of the PLYR chunk (so ex. if SCLS was "SCLS 0x00000009 0x000000DC", make it "SCLS 0x00000009 0x000000E8").

 

Alternatively, see if there's a chunk you don't really need (tho that might be difficult, ex. I have no idea what's 100% needed by the game) and replace that one, along with its data, with your new PLYR chunk and data.

 

EDIT: There we go, much better BMD support...

 

Posted Image

 

Tho no materials, textures, matrices, joints, etc., etc., etc... Also, really messy code...

Edited by xdaniel
Link to comment
Share on other sites

Ah... XDaniel? I regret this, but I'm not quite understanding what you're talking about with 'chunks.' I understand offsets, just not the rest.Would it be possible for you to give a bit more simplified explanation?

Also, I'm going to try finding a .dzr to replace room19's original (think I'll replace it with room20's...) and see if that's what the problem is. If it is, it would be even more worth it to figure out the X/Y/Z positioning stuff. Then we could edit one of the .dzrs to have a PLYR that's positioned inside the model of the room.

Edit: YEAH! I replaced the .dzr file, and the room loaded! But... Link fell to his death a second after it loaded, so I didn't see anything XD Oh well. It's still a plus!

Link to comment
Share on other sites

Oh, "chunks" is what I call those PLYR, ACTR, etc. blocks, so the chunk definitions would be the list near the beginning of the file that has all those 4-letter descriptions, while the chunk data is what each definition points to. So basically, to try and add a player actor to the file, you'd need to add such a "PLYR chunk" to said list.

 

Using E3 Outset Island as an example, its last chunk definition is at offset 0x28 and says "SCOB 0x00000001 0x00001974", thus ending at 0x34. Next, the file is currently 0x19A0 bytes long, so you'd need to insert "PLYR 0x00000001 0x000019AC" after the SCOB chunk - 0x19AC because "file length (0x19A0) + length of the new PLYR chunk (0x0C) = offset of your player actor data (0x19AC)". Now the file is 0x19AC bytes long; next thing to do is fix the other chunk definitions and add 0x0C to their pointers, so ex. "FILI <0x00000001> <0x00000034>" would become "FILI <0x00000001> <0x00000040>".

 

I hope that helps somehow, it's a bit complicated and I'm not that great with explaining stuff.

Link to comment
Share on other sites

Oh! I see! So, to add PLYR to the file, I need to add it to the list, give it its own pointers and fix the other pointers on the list?

Hm. You would make the pointer for the PLYR in your description 0x000019AC because the new information relating to PLYR would start at that offset, right? And we're fixing the other chunks for the addition of the PLYR header and offset?

Final question. 0x00000001 and 0x00001974. Is this where the game looks for the information relating to the chunk header? So it would look from 0x00000001 to 0x00001974? Or does the information start at 0x00001974?

 

 

Oh! Oh, I get it now! Reading the OP again, I see it! The first offset is the number of things related to the chunk header, and the second is where the data for that header starts!

Link to comment
Share on other sites

That should basically be it, yeah. At 0x000019AC I'd then put the PLYR actor's data, as per the description in the first post (0x20 bytes, starting with actor name, then parameters, then position, etc). As for 0x00000001, that's the number of <whatever>'s the chunk contains, so in this case, it would be one player actor, while with a normal ACTR chunk, you'd probably have something like 0x0000003A actors or whatever.

 

Edit: Ah, too late, but good that you figured it out :D

Edited by xdaniel
Link to comment
Share on other sites

Another quick question: After I add the new PLYR data at where I'm placing it (starting at 0x9F, the end of room19's dzr file), do I need to fix anything again? Or was the fixing at the start of the process only necessary because we added data in the middle of the file?

 

Edit: Posted Image

 

It worked! Wind Viewer recognizes the addition! I copied the data from the E3 outset file you provided in the program's folder, so it's not positioned correctly.

 

Also, room19's dzr has an exit header. That exit? Yeah, the destination map is SirenB. What's in SirenB? The tower's boss room. I think this means that room19 was meant to be a room you'd visit after beating the boss.

Link to comment
Share on other sites

Looking at Siren's Room19's dzr myself now... Here's how it might (hopefully) work, step-by-step:

 

- Go to offset 0x34, right at the end of the LBNK chunk definition, and insert 0xC bytes (0xFF for the moment)

- The file's size increased from 0xA0 to 0xAC bytes, which is where we'll put our PLYR actor's data

- Go to offset 0x0 and change the amount of chunks from 0x00000004 to 0x00000005

- Go back to offset 0x34 and enter the PLYR chunk's definition, overwriting the 0xFF's: "PLYR <0x00000001> <0x000000AC>" (0x504C5952 0x00000001 0x000000AC in all hex)

- Go down to the end of the file (0xAC) and enter your PLYR actor's data (ex. take Room18's data from offset 0xC8 there, it's 0x20 bytes long)

(- You'll likely need to adjust the player's coordinates so that he doesn't just spawn outside the room)

 

...and that should be it in terms of editing the file. ...and I just noticed you edited your post! Sneaky little fella :D Let's see...

 

Yeah, you'll need to change the coordinates, otherwise Link will likely just fall to his death. And yep, noticed the exit as well, although I wasn't sure what SirenB was. So it's the boss room? That does sound interesting...

Link to comment
Share on other sites

Posted Image

Yellow is the chunk info, red is the rest. That's how it turned out for me.

 

Edit:

Posted Image

 

Posted Image

 

Posted Image

 

 

Oh! I also found where the text is stored! It's stored in bmgres.arc in the res/msg folder and starts at 0x1A309. Huh. One odd thing I've found is that "This is but one of the legends of which the people speak" is sandwiched between Medli's text. Wonder why?

 

No! No, wait! The full line says, "This is but one of the legends of which the people speak... Uh, were you listening to that? Oh, how embarrassing." Unused Medli line for when you through her into a wall the first time you're in Dragon Roost???

 

Hmph. Then again, looking at how chopped up the text is, I guess it could be randomly stuck in there. :/

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

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