Wind Waker Hacking Thread

[Armos]

Nice, About time someone has made Wind Waker hacks.

[Ghost]

looks good

[JDYoungLink1]

I tried importing the Outset Island forest level in OOT debug and it didnt go exactly as planned.

I opened the .arc file in BMDView2 that worked fine, then i exported the level and put it in sketchup at this point so far so good

But when i used sharpOcarina to import it this was the result , i think ill retry later.

 

I was pretty close but... but as they say if at first you don't succeed try again XD

[Secant]

I'm guessing this is a fault of the exporter miscalculating the UV mapping coordinates. You might consider trying to export this in 3DS Max, as its exporter has far fewer errors than the one for SketchUp.

[JDYoungLink1]

I'm guessing this is a fault of the exporter miscalculating the UV mapping coordinates. You might consider trying to export this in 3DS Max, as its exporter has far fewer errors than the one for SketchUp.

 

I tried that every map that i export for SharpOcarina I then Import it into 3ds max and export it.

But what i havented tried is importing the file into 3ds max in the 3ds format that BMDView2 exports in then exporting it in obj format then importing it into SharpOcarina.

[xdaniel]

Uhm, that's not the alpha forest...? A_mori is the forest at Outset Island, if I'm not totally mistaken, while A_R00 is the unused one, complete with its ancient Maya file or whatever it was, that can't even be read by BMDview2.

[JDYoungLink1]

Uhm, that's not the alpha forest...? A_mori is the forest at Outset Island, if I'm not totally mistaken, while A_R00 is the unused one, complete with its ancient Maya file or whatever it was, that can't even be read by BMDview2.

 

my mistake in confusing the two. i managed to get the outset forest to work without any problems this time.

[xdaniel]

my mistake in confusing the two. i managed to get the outset forest to work without any problems this time.

No problem. Also, that's looking pretty nice! Although, sadly, this is one of the cases where the N64's small texture cache really shows, because the tree backdrop surrounding the area looks pretty awful in that low resolution/color depth... not much that can be done about it, tho, without ex. editing the model and breaking the texture up into two (one for the upper leaves, one for the trunk and grass)

[Lishy]

Offtopic, but that map looks GLORIOUS in OoT!

[JDYoungLink1]

No problem. Also, that's looking pretty nice! Although, sadly, this is one of the cases where the N64's small texture cache really shows, because the tree backdrop surrounding the area looks pretty awful in that low resolution/color depth... not much that can be done about it, tho, without ex. editing the model and breaking the texture up into two (one for the upper leaves, one for the trunk and grass)

 

That wasn't the issue I just took the picture before i applied all of the hires textures.

this is with all of them applied looks like.

 

i'll just leave this here*

[Secant]

Aside from the scaling of the maps being a bit large, these imports look great, JD.

 

Since this is more related to OoT modding than Wind Waker hacking, though, you might want to post these in a new thread so people don't get confused.

[JDYoungLink1]

Aside from the scaling of the maps being a bit large, these imports look great, JD.

 

Since this is more related to OoT modding than Wind Waker hacking, though, you might want to post these in a new thread so people don't get confused.

 

Sure thing Naxy. On-Topic Xdaniel are you goint to add a dump obj file option for the "WindMaker" in the near future? or if 3ds format the only available option(like BMDView2)?

[Sage of Mirrors]

Lessee, where do I begin?

 

The Wind Waker’s standard audio is stored in .bms sequence files. Like MIDI, these files contain track, instrument, note and other information.

 

The file begins with a list of all the tracks in this format:

 

C1 xx yy yy yy

Where xx is the track number (starting from 0) and y is the offset to the instrument.

 

Between the offset list and the first track, there’s a series of bytes, the length of which is different for every file. Since the end of this series usually ends with 01 E0, which tells individual tracks to repeat, I’m going to make an educated guess and say this holds song information- tempo, length, ect.

 

With that out of the way, we come to the fun part. Typical tracks start with their first 11 ( B )bytes looking like this:

 

E7 00 00 A4 xx xx A4 yy yy 9z 00

X, y and z all dictate what instrument the track is assigned to. They could be offsets into JaiInit, but I'll have to look into it more. After this, things start to get a bit fuzzy. Depending on the file, the section involving the instruments is shorter or longer. This makes getting a solid grip on where notes actually start somewhat difficult.

 

Here's how notes are stored:

 

xx uu zz aa bb

Where xx is pitch, uu is unknown (something to do with note position), zz is volume, aa is length and bb is also length (investigation needed). There might be more to it, might be less. I really need to research this more, too.

 

Interesting thing here: Notes are MIDI numbers converted into Hex. So, 69 is A, so that would be 45 in Hex. 70 is A#, so that's 46, ect.

 

Here’s a very short example of what I can do. I’m really tired, and I just wanted to get it out, so excuse the shortness, quality and choppiness. It’s supposed to be the first few notes of the Minuet of Forest… I had trouble with getting the spacing right. I might reattempt it later.

 

 

 

 

Doing that one little thing was very difficult, which is why it was just a little splattering of notes. I'm hoping someone will be able to help make a converter so that we can make MIDI files from these, and output .BMS files to put into the game.

[Conker]

Nice one, man! Wind Waker modding sure is coming a long way.

 

Sent from my EVO 4G using Tapatalk 2

[haddockd]

Found this in my travels. Has alot of documentation. I won't lie to you, I did not look through all 14 pages here and see if this was already posted. But it seemed to have relevant stuff so here:

http://www.emutalk.net/threads/52065-Zelda-Wind-Waker-resources?highlight=quest+64

[Sage of Mirrors]

Well, anyway.

 

While digging through the .dol, I discovered a lengthy list of names starting at 0x36F818. It looks to hold all of the valid actor names, as well as DZS and DZR header strings (PALE and ACT, for instance) and a few things from STBs. What could this be for? Could it be a reference table for the game? What about a remnant of an in-game editor? I haven't looked into it much, but I will try changing stuff and see if it messes with anything.

 

I see!

 

The list is a set of entries 0xC bytes long. The last three bytes are typically the variables. When I copied the variables from one boss (bwds) and put them into Gohdan's entry (bst), the result was that the game tried to load bwds (it loaded both the .rel and the actor's .arc), but there were severe problems with the registers and heap size and such. So this list is used by the game; in fact, it's probably how the game identifies actors.

 

Alright. In the case of the DZS header strings, the variable is actually the offset in RAM of the code that reads or inits the section.

[Sage of Mirrors]

Over the past few days I've been working on a sort of hack that compiles all that we know about TWW. This is the first release of that hack.

 

http://www.mediafire...t7jcg9tjvdcyyxw

 

From the Readme:

 

*The Legend of Grandma*

 

This is a small hack of The Legend of Zelda: The Wind Waker. It is mostly to demonstrate what

we have learned so far in the realm of how The Wind Waker works.

 

Here are the things that are present in this hack:

 

-Actor placement

-Waypoint placement

-Text editing

-Event editing

-Treasure Chest editing

 

Now, due to issues encountered regarding the making of a patch, this hack

is being distributed as its component files. In order to place these files in the ISO, you must download GCRebuilder,

which can be found here:

 

http://www.romhackin.../utilities/619/

 

 

A set of instructions for compiling and starting the hack are in the Readme, as well. Xdaniel and Lunaboy (the creator of the arc packer I used) have both been credited.

 

Here are some screenshots:

 

 

 

 

 

 

 

Keep in mind that this is a work in progress. I'm still trying to figure out how certain events (like the cutscene that starts when you first enter the forest) work with the use of Tags. Once that has been settled, though, I will begin editing the forest and lengthening the hack.

 

Now, I'm not sure how this will work on a PAL ISO. Replacing the bmgres.arc that is in the .7z might work, but it also might not due to differences.

 

All in all, this is pretty rough, so there might be an improvement in the future.

[Sage of Mirrors]

I decided to film the demo. What do you guys think?

 

 

 

[Armos]

Now all we need is Twilight Princess Hacking! ^__^ Good job guys. I need to get involved in some way but I barely know how to code... :/

[Jack Walker]

Is it okay to post stuff on Twilight Princess hacking here since TP and WW use similar engines? I've discovered some interesting things with TP that I would like to share.

 

Edit: Thanks for the help Sakura. I'll make a thread for TP hacking.

[Guest sakura]

Is it okay to post stuff on Twilight Princess hacking here since TP and WW use similar engines? I've discovered some interesting things with TP that I would like to share.

 

Feel free to make a TP hacking thread, or a thread detailing your findings. I think this should probably stick to WW hacking though, in order to keep it from being derailed or too cluttered

[Sage of Mirrors]

I've been researching what's in the SCOB and SCOx sections of the .dzr files. What I've discovered are things that I'm going to name "tags" due to the fact that many of them have the word "tag" in them. All tags follow this format:

 

xx xx xx xx xx xx xx 00 yy yy yy yy zz zz zz zz zz zz zz zz zz zz zz zz zz FF 00 00 aa aa aa aa bb bb bb FF

Where:

 

x = Name of Tag

y = Variable Field 1 (what variables are in here depends on the tag name)

z = Coordinate data (pretty sure)

a = Variable Field 2 (Doesn't seem to be used a lot)

b = Collision x, y and z

 

Note that this could be off a bit. Wind Viewer seems to make more fields for tags than there actually are.

 

Here's a list and description of the tags I've researched so far.

 

 

Name: ky_tag0/1/2

 

Purpose: Controls weather conditions and forest particle effect

 

Variable Field 1:

 

xx xx yy zz

x = Unknown

y = Weather condition/particle effect

z = Type/intensity

 

Variable Field 2: N/A

 

 

Name: TagEv

 

Purpose: Calls an event from the EVNT chunk of a .dzs. It can be used to call regular cutscenes, too, as long as the cutscene is referred to in both the area's event_list.dat and .dzs.

 

Variable Field 1:

 

xx FF yy yy

x = Event index in .dzs (starting from 0)

y = Unknown. Seems to play a part in how the event is called. Needs more investigation.

 

Variable Field 2: N/A

 

 

Name: TagMsg

 

Purpose: Calls an event from the EVNT chunk of a .dzs, with the added ability to display text. It works the same way as TagEv.

 

Variable Field 1:

 

xx FF yy yy

x = Event index in .dzs (starting from 0)

y = Unknown

 

Variable Field 2: Message ID of text

 

 

Name: AttTag/AttTagB

 

Purpose: Makes Link like in the direction of the tag.

 

Variable Field 1:

 

xx xx xx xx

x = Unknown

 

Variable Field 2: N/A

 

 

Name: TagIsl

 

Purpose: Unknown. It's found with a few of the major islands, such as Greatfish and Dragon Roost. The ID it uses to identify the islands isn't the normal island ID. When the ID is changed, the tag teleports Link to the specified island. Only three of them seem to work, though - 01, 02 and 03, which are Dragon Roost, Forest Haven and Greatfish, respectively.

 

Variable Field 1:

 

xx FF xx yy

x = Unknown

y = Nonstandard Island ID

 

 

 

There are a ton of other tags that need documented, but they will get done sooner or later.

[Lord Ned]

I have had some minor success with importing custom maps into Windwaker. I've only tried with two and succeeded with one. Here is the map in 3ds max, (a modified K_Test02):

 

And now here it is in game:

 

It unfortunately lost its ability to have lighting along the way, and my guess is it's due to texture conversions, etc.

 

This was created by unpacking the stage, un-Yaz0' if applicable, using a 3ds max script to import the .bdm (and extract textures), and then exporting to OBJ, using obj2bdl, and then converting back to bdm via bdl2bdm. Then using the rarc repacker, NOT COMPRESSING IT, and embedding it via the ISO repacker.

 

Unfortunately I haven't had any success with maps that start as a bdl, only ones that start as a bdm. I've been researching into the collision format some more, because I want to try and create a collision model creator to create new collision to match the geometry change.

[Sage of Mirrors]

Nice job with the model edit. I need to look into those programs soon.

 

Custom collision is the one thing that we really need now that it seems that custom models with textures are possible. If you could get a collision converter, that would be sweet!

 

Also, Xdan, I've been meaning to ask you - can you update WindViewer to make some of the stuff we've documented editable? I'm mainly looking at SCLS and TRES (being able to edit them without a hex editor would be super handy), but maybe some of the .dzs entries, too...? I did put some of them on the wiki page, but it's been a while since I've looked at it, so I'm not sure exactly what I've put in. Ah, EVNT (.dzs) has also been documented well, I believe.

[Lord Ned]

Nice job with the model edit. I need to look into those programs soon.

 

Custom collision is the one thing that we really need now that it seems that custom models with textures are possible. If you could get a collision converter, that would be sweet!

 

Also, Xdan, I've been meaning to ask you - can you update WindViewer to make some of the stuff we've documented editable? I'm mainly looking at SCLS and TRES (being able to edit them without a hex editor would be super handy), but maybe some of the .dzs entries, too...? I did put some of them on the wiki page, but it's been a while since I've looked at it, so I'm not sure exactly what I've put in. Ah, EVNT (.dzs) has also been documented well, I believe.

 

Thanks

 

I'm using XDan's C# code (I decompiled it, sorry!) as a basis for my collision stuff, because he has it well enough to load it so I figured it was a starting place. Working on trying to figure out the Unknown's. I have some ideas as to what they'd be, my guess is per-triangle collision flags (water, ice, solid, etc.) as well as perhaps bounding boxes, etc. I'm neck deep with a notepad document and a hex editor, learning as I go and punching things into my C++ app to try and get results. Going to write an OBJ exporter now to see if we can just dump collision models for the moment.

 

Also good work on all of the entity stuff Sage!

 

Edit:

What I've discovered so far is that the "Type" section (as documented by XDan) has a count of 5 but an offset of 0 for this collision, so I'm not sure if it's incorrect or whether it has a number sometimes but no actual value, etc.

 

Second Edit:

It finally occured to me that if my header is 48 bytes long, and the triangleOffset is 36, then the offsets are not listed from the start of the file. This then lead me to discover that none of my offsets are correct. While I fix that, I punched in the offsets manually for the moment, and got myself a collision model exported to obj: http://i.imgur.com/1XYUY.png Though this appears to not be quite correct still, it's pretty close to what it should be.

 

 

Something of note that I thought about is these collision models are only written as points. I think the surface needs normals too, because looking at Sunshine glitch videos as well as a few Windwaker ones, collision testing is only one way. Normals are either determined in-game by face-order, or that's part of the unknown collision data.

 

Final edit:

Needs a y->z flip, but I finally got meshes to load right. Had a few misunderstandings with it, I think my offsets are correct, they're just additive to something other than the start of the file, maybe it's an offset past the end of the previous data*? Will try some more tomorrow. Just leaving these edits here for anyone in the future who might learn from it.

 

*I don't think this is true. My current file has a 52 byte vertex offset, and a 36 byte triangle offset. The vertexes occupy the space between 52-292 (240 bytes long, 20 vertexes with 3 floats at 4 bytes each), adn then the face data starts IMMEDIATELY afterwards, occupying 292-452 or 160 bytes (10bytes per triangle, 16 triangles. 6 bytes goes to the index, then 4 bytes of "unknown".)

 

This means that the 52 byte vertex offset is correct, but the 36 byte triangle offset should actually either be 0, or 292 by either theory. I'll sleep on it and see what I come up with in the morning.

 

Use a proper Endian conversion!

The offsets are now as expected when I switched endian-conversion methods. Use: _byteswap_ushort / _byteswap_ulong (<intrin.h> for MSVC instead of writing your own.