Jump to content

Wind Waker Hacking Thread


xdaniel
 Share

Recommended Posts

I read some old threads about Dolphin and this model format over at Emutalk, and apparently Link's eyes are kinda tricky to render correctly. They looked pretty much just like this in Dolphin as well initially, as far as I remember, until someone came along and cracked the format for good.

 

Also, some more progress:

 

Posted Image

 

One correct arm, and that's about it so far.

 

EDIT: YES!

 

Posted Image

Posted Image

Posted Image

Edited by xdaniel
Link to comment
Share on other sites

YES! I just successfully added two files to a .rarc! rarcdump extracts everything correctly! Now to see if my idea works...

EDIT: Aaaaaaaaaaaaaaaaaaand it's a hang. >.> Guess I'll have to figure out if I can fix it correctly.

 

EDIT2: What in the name of Din are these?

 

Posted Image

 

Posted Image

 

 

They're (Wow, did I really post that as 'Their' the first time?) the two models held in the Title.arc with all the other areas. The tex folder holds a 2D Japanese banner for the game. Wonder what this was for? The water has an odd texture to it- it reminds me of the water used in Super Mario Sunshine.

The arc itself has no collision, nor does it have a .dzr or even a stage. As it stands, this model is useless. It has neither the structure of regular map (no 'Room0') nor the required files. Could this be some very very early stuff? The sky box looks a bit negative...

 

Edit3: I didn't want to make another post, so I'll just put these here:

 

Posted Image

Posted Image

Posted Image

Posted Image

 

How am I doing so far? Do they fit? I had to custom-fit each section of text so that the offsets didn't change; the text in the first pic is further into the file, and was displaced when I changed the other text, so the first slide is from a separate bmgres.arc. I'm hoping that as we really get into this stuff we can figure out how the game gets text offsets, and avoid that problem altogether. I suggest taking a look at the top half+ of bmgres, as that has a lot values.

 

If I could pack .dds files into a .bti, I could edit the actual images as well. Textures, too...

Link to comment
Share on other sites

Posted Image

Posted Image

The model you found is on the left, and the VrTest model is on the right.

I have no clue

 

EDIT: I believe that the VrTest model is actually older than the Title model.

 

Also, I recognised that skybox as being in a few screenshots and videos (It's in the E3 2001 trailer for instance, but you have to really look). It was also apparently used in old Outset Island revisions.

 

I tried hacking the E3 Outset Island to use the model, but it didn't want to load.

 

Also, kinda unrelated, but I believe that this island was the basis for all future islands as really old versions of Outset Island used these textures.

Link to comment
Share on other sites

Does that second one have collision?

 

Also, I think I've figured out (partially) how cutscenes might work. There are .arcs in the Object folders called Demo__. These seem to hold cutscene actor models (Ganondorf, Valoo, Maggie and Milla, ect.), the animations the characters do during the specified cutscenes (stored in bck amd btp), brk files and a new file called an stp. I've also observed that some have a model that's titled 'blackfadebox.' Hmm. Judging by the name, I'd say that these models' collision determines when and where the screen fades to black (At the top of the ladder in Grandma's house at the start of the Hero's Clothing cutscene, for example).

 

Alright, I've been taking a look at the stb. Specifically, I'm starting at a section labled JMSG. Here's what I've gotten by staring at them for an hour:

 

-There's a header, 17 bytes long. Looking at four of them (two from what I think is the cutscene where you get the Hero's clothes, one from the rescue scene in the Forsaken Fortress and the scene just before the final battle with G-dorf), I think I can make this assumption in format:

4A 4D 53 47 00 00 00 08 6D 65 73 73 61 67 65 00 02 00 00 xx 80 00 00
For the two from the clothes cutscene, xx is the same- 15. But the two others also have the same value there- 96. Might have to do with the number of entries, but I can't really be sure without some experimentation.

 

-Entries:

 

There appears to be some sort of entry format, ten bytes long; I've come up with this:

08 00 04 08 59 00 00 xx yy 02 00 00 zz 80 00 00
xx is always the same, it seems, for entries from the same section. yy has an increasing value (for one entry it's AE, for another its AF, for another it's B0, ect.). No idea what zz does.

 

There's also some kind of footer on three of four files, usually 0xD bytes long: Nevermind, I'm thinking now that that set of bytes pertains to another section, called 'control,' as the one that didn't have those kinds of bytes also didn't have that section.

 

-General header. At the start of a file, there's a header that's 23 bytes long:

53 54 42 00 FE FF 00 03 00 00 xx xx 00 00 00 yy 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
xx xx is the size of the .stb file, while yy is unknown at this point. This might be longer, but this is what each file has in common atm.
Link to comment
Share on other sites

Does that second one have collision?

Well, VrTest is a full map (with collsion and everything) you can load with the debug menu.

As for the other one... technically it's not even a room.

 

...wait a minute. A_nami is the invisible island. It has pretty much everything required of a room, EXCEPT for the actual island model. Of note, is that A_nami's collision is the same as for VrTest. The model you found lacks everything required of a room, except for the model.

Maybe the model you found is the BMD for A_nami?

Link to comment
Share on other sites

Hacked together a (incomplete) text viewer for the game's BMG files, or rather the ARCs they're packed into. Open up such an archive, say Msg\data0\bmgres.arc, and it should open it, get the BMG file, get all text offsets from it and display each message. It's rough around the edges, doesn't support any control codes, but it should at the very least work. Even Japanese SJIS text should be working, although I don't have a Japanese copy of the game and thus could only go by Msg\bmgresh.arc.

 

Download: http://magicstone.de/dzd/random/WWText.rar (Windows/.NET binary and source, release build in "WWText\WWText\bin\Release")

 

Posted Image

Link to comment
Share on other sites

Wow! That's pretty cool. If we could find the offsets that determine how the game gets text, could you build an actual editor off of this?

 

Edit: For the sake of writing it down...

Looking at the text through your viewer, I think I can identify some of the control codes...

 

1A06FF000001 and 1A06FF000000 seem to tell the game to make the text red.

 

1A05000001/02 has to do with the first line of 'Item Get' text. Not sure what. Bolding? Centering?

 

1A05000000 makes the game look for the player's name. I've noticed that, unlike Ocarina of Time, the game uses 'Link' in this space if no name is present (IE viewing cutscenes from the debug menu).

 

Er, 1A050000 (with only two sets of zeros after 05. How confusing!) seems to display the A button icon.

 

1A00000700- Not sure, might separate the first and second lines of 'Item Get' text.

 

1A05000010/11/0F make the game display the icons for the Y, Z and X buttons (in that order).

 

1A0500000C seems to display the control stick icon

 

1A05000014/1D/15 probably display C-stick positions.

 

I'll probably keep looking.

Link to comment
Share on other sites

Wow! That's pretty cool. If we could find the offsets that determine how the game gets text, could you build an actual editor off of this?

I'm guessing that the second value in an INF1 entry - that is, after the first 8 bytes, which are the text's offset into the DAT1 chunk - is the ID by which the game finds the text. So, I assume the game requests an ID, based on ex. a sign actor's parameters or something, then opens the current language's text archive (if it's the PAL version; say Msg\data0\bmgres.arc for English), goes through the INF1 chunk's entries and then loads the correct text once it's found the ID in the chunk.

 

Looking at the sign near Outset Island's watchtower, it's parameter/variable/whatever is 0x00000322. If we now look for ID 0x0322 inside the English text archive (I'm using the actual bmgres.arc here, as I didn't extract that yet), we get text offset 0x0000CF11, and some addition later (DAT1 base offset + 8 to skip its header + 0xCF11) we get 0x27219. And what do we read there? "<- Watchtower, -> Forest of Fairies"! Heh, I think we now know how it works. Can someone change that sign's parameter to 0x00000324? That should make it read "Notice: Windfall Auction Tonight!" etc. in-game now.

 

Woah, impressive. Was it more complicated than matricies on the N64? matricies in badrdp pl0x :D

The matrices themselves are stored in a pretty straight-forward way, however getting to them is more complicated. It involves indirection via multiple index values into different tables; can't recall exactly how it is from the top of my head, but it's something like "Matrices[indirectionTable[MatrixIndex]]" and I guess I'll look into badRDP matrix support sometime.
Link to comment
Share on other sites

The old Wind Viewer as released previously can load and show actors (in cube form, but at least that), and also shows the selected actor's information, ex. its variable, plus the offset at which the actor's definition can be found inside its DZR:

 

Posted Image

 

As for 0xCF11, I searched for the last 4 bytes of the sign actor's variable (0x0322) inside the text archive, Msg\<language folder>\bmgres.arc:

 

Posted Image

 

The first four bytes - here thus 0x0000CF11 - are the offset into the file's DAT1 chunk, which holds the actual text, minus 8 bytes (skipping the DAT1 header). Thus, as mentioned before, the formula is: "DAT1 base offset + 8 to skip its header + 0xCF11"

 

EDIT: Oh, yeah, I also slightly improved the text converter, so that it now correctly interprets extended ASCII, like our German umlauts (no download yet tho):

 

Posted Image

 

"There is either not enough space on the Memory Card, or the maximum amount of saved data has been exceeded. To save data for this game, one free file and 12 free blocks are needed."

Edited by xdaniel
Link to comment
Share on other sites

Posted Image

I got this by reverse-engineering your formula (The offset of the text minus 1A308). It actually acts just like a sign; must be the actor's parameters in the DZR that determine how the text is presented.

Now that you've got this figured out, making a text hack is technically completely feasible. However, it'd be VERY tedious to go in and fix all the offsets...

Link to comment
Share on other sites

Yeah, automated text extraction and insertion is what we're gonna need. I guess I'll look into dumping those BMGs into a typical Atlas-style re-insertable script file - look around http://www.romhacking.net/ -, just like many/most translation hackers do it. Probably the easiest way to go about here, as long as Atlas' pointer writing functionality can work with our INF1 entries...

 

EDIT: Added some stuff to the first post, mainly links to other posts in the thread; also, have another screenshot of the text viewer before I go to bed (download comes later):

 

Posted Image

Edited by xdaniel
Link to comment
Share on other sites

Posted Image

Confirmed: Adding text to the end of the .bmg file does not break it, and if you provide the offset the added text works perfectly!

 

Edit: How about a preview of the prologue remake I'm writing? I'll post the rest once I work out the formatting kinks.

 

Posted Image

Posted Image

Posted Image

Posted Image

 

In this version, Grandma is telling Link the story on the night before his birthday. It says 'Link' because that's the name I used when I started the file.

Link to comment
Share on other sites

  • 2 weeks later...

You know, I've been thinking... Maggie and Mila from the Forsaken Fortress cut scene, in their original clothes, load in one of the character test rooms. They act like normal actors. When you speak to them, they give the first message in the .bmg ("You can only call Tingle from places that have maps!"). I'm guessing that either A)the game loads the first string of text in the .bmg if there's no set variable, or B)both Maggie and Mila have their text variables set to 00. Later, after school, I'm going to see if I can change their text values. Maybe we can actually put them in the game with their original clothing.

 

Now, what I wonder is if it's possible to add entries to the .bmg. It would require a lot of offset-fixing, but it might be worth it. Constructing an entry for text added at the end of the file could keep us from having to cannibalize other entries.

Link to comment
Share on other sites

Now, what I wonder is if it's possible to add entries to the .bmg. It would require a lot of offset-fixing, but it might be worth it. Constructing an entry for text added at the end of the file could keep us from having to cannibalize other entries.

Similarly, I wonder if you can change the offsets defined for the .bmg. I suppose it's a matter of finding its entry on the file table or somesuch, but wouldn't that allow you to move it entirely somewhere else with more space?

Link to comment
Share on other sites

Zeth: Soon-ish, I guess.

 

Fi and Naxy: Seeing how the text entries are in one chunk, and the actual text is in another, I'm guessing all that's needed is changing the chunk sizes in their headers and just appending your new data to each chunk. Still need to verify that tho, as I'm going off memory right now, so no promises...

Link to comment
Share on other sites

Here's something odd. There are two objects, one called mo2 and one called mo2_si. Now, Mo2 is a moblin (Mo? Get it?), so what's Mo2_si? Thing is, we can't know. The .arc isn't formatted correctly, and just extracting a .bmd from the file doesn't work; the bmd has extra data in it that others don't have. What's weird is that this arc has a folder called MSG, with both entries in that called "zel_m100003.bin" and "zl00020.bin." They're nothing but jumbled numbers and letters, though. Mysterious! I wonder if there was supposed to be another version of the moblin.

 

Edit: Information on JaiInit.aaf!

 

00 00 00 01 00 00 06 70 00 00 94 C0

Dunno what the first four bytes, 0x00000001, mean. 0x670 is the offset of some kind of table (instruments, maybe...!?). 0x94C0 is the size of this table.

 

00 00 00 02 00 00 9B 30 00 00 20 60

Don't know what 0x2 means. 9B30 is the offset of the first entry called IBNK. Another entry called BNK follows this, after which comes several other entries labeled INST. Skipping ahead...

 

49 42 4E 4B 00 00 20 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x49424E4B is the ASCII for IBNK. 2060 is the length of the entire thing, from the start of this IBNK to the start of the next.

 

42 41 4E 4B 00 00 16 E0 00 00 17 20 00 00 17 60 00 00 17 C0 00 00 18 00 00 00 18 40 00 00 18 80 00 00 18 C0 00 00 19 00 00 00 19 40 00 00 19 80 00 00 19 C0 00 00 1A 00 00 00 1A 40 00 00 1A 80 00 00 1A C0 00 00 1B 00 00 00 1B 40 00 00 1B 80 00 00 1B C0 00 00 1C 00 00 00 1C 40 00 00 1C A0 00 00 1C E0 00 00 1D 20 00 00 1D 60 00 00 1D A0 00 00 00 00 00 00 1D E0 00 00 1E 20 00 00 1E 60 00 00 1E A0 00 00 1E E0 00 00 1F 20 00 00 1F 60 00 00 1F A0 00 00 20

The first four bytes are BANK. 16E0 is actually the offset of the first instrument relative to IBNK; this goes for all of the two-byte pairs (not sure what the lone ones, like 18, mean) All of the numbers here are offsets; ones like 18 are actually 1800.

 

49 4E 53 54 00 00 00 00 3F 80 00 00 3F 80 00 00 00 00 08 E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 00 10 70 00 00 10 80 00 00 10 90 00 00 10 A0 00 00 10 B0

First four bytes are INST. The two 3F80s and the 8E0 are the same throughout this chunk's INST entries. The 5... looks to tell the number of pairs after it (there are five 10xxs, for example). But what do they mean? What is significant about these IDs? I'll have to figure it out later.

Link to comment
Share on other sites

I think we've got a mystery on our hands!

 

So I was going through the cutscene objects, right? Well, I found the cutscene where Fado appears to tell Link to give Makar the song. Here's his model, located in Demo32:

 

Posted Image

 

So, that's Fado.

 

HOWEVER.

 

If THAT is the in-game Fado, then who is this character with Saria-green hair and outfit?

 

Posted Image

 

This little guy is located in Demo45, which seems to be a mishmash of models. The .stb is named 'runaway_majuto.' Dunno what it is.

 

Now, Makar does disappear from the scene where he plays the Wind God's Aria for the first time behind the waterfall... but it's replaced by the Demo35's Fado model! Fado is the only Kokiri in the game. So who is this guy? Judging by him holding the violin, it's in all likelihood a(nother) beta Fado. But why did they go with the one they did? Was the hair and sleeves too much of a reference to Saria? I actually like Demo45's model better. *Runs off to see if they have the same number of joints* Oddly enough, Demo45's version has 27 bones while the final has 25... why the difference...? Actually, he hasn't got anything associated with him. No proper animations (neither .bck nor .btp), no .btk... he's got a .brk (something about 'alfa_test?'), though. Looking at all the models involved (Quill, Grown-up Prince Komali, Valoo, and strangely the fat woman in the pink dress from Outset...!?), this may have something to do with the scene just after the Forsaken Fortress (where Valoo speaks to the King at the Tower of the Gods). Then again, it might just be some kind of filler data (fat pink woman, I'm looking at you), and they accidentally included the beta Fado in there...

 

Edit: Also, I found this model, called jb_dummy in Jabun's cutscene:

 

Posted Image

 

I think this very rough dummy model supports the theory that they added his cutscene in later in development, possibly even last-minute. They worked so quickly that they forgot to take out the dummy. Funny thing is that the final Jabun model has no tail.

Link to comment
Share on other sites

Maybe because he was supposed to be a descendant of Saria's could explain why WW Fado's unused design strikingly resembles her. But there's nothing that much radically different about the unused model one since, upon closer inspection, is the exact same thing as the final model only with a different hair color, different facial textures, and alternate sleeve textures who's design could further extend the descendant theory.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

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