Wind Waker Hacking Thread

[xdaniel]

One thing I'm interested in that I haven't seen is the locations of loading zones. Sure SCLS is an exit listing, but I haven't come across any coordinates. That would be really cool and allow for some new possibilities.

"Loading zones" as in, say, dungeon entrances/exits? I'm gonna go ahead and guess that's some exit-enabled collision polygons, the same way the N64 Zelda's work.

 

I hadn't looked very deeply into collision in WW, but if it's similar to OoT/MM, then you've got a collision polygon type that's set to trigger one of the exits defined elsewhere (in this case presumably in the SCLS chunk), as well as any number of polygons that are set to be of that type. If you step onto one of those polygons in-game, it triggers the transition to whatever map is defined by that exit.

 

Hope that helps any, even if it's just a theoretical idea.

[Sage of Mirrors]

"Loading zones" as in, say, dungeon entrances/exits? I'm gonna go ahead and guess that's some exit-enabled collision polygons, the same way the N64 Zelda's work.

 

I hadn't looked very deeply into collision in WW, but if it's similar to OoT/MM, then you've got a collision polygon type that's set to trigger one of the exits defined elsewhere (in this case presumably in the SCLS chunk), as well as any number of polygons that are set to be of that type. If you step onto one of those polygons in-game, it triggers the transition to whatever map is defined by that exit.

 

Hope that helps any, even if it's just a theoretical idea.

It works similar to that, yeah. LordNed and I have just about completely decoded the collision format. It's some other technical things (and laziness/free time shortages/lack of coding experience on my part) that have stopped us from making an obj2dzb converter. It would be fairly simple - no texture data needed. The only data we'd need from the model is the vert and face data. Everything else can be automatically generated or handpicked by the user.

 

My STB research is just about complete. At one point, I had a version of Wind Viewer that could view the basic structure of an STB file:

 

 

I never got around to finishing it, as I believe I messed up my only copy of Wind Viewer's source (I'll have to grab it again and re-do this), but this is how I hope to get STB files editable. Also on a side note, the "Unknowns" in that list are known now.

[Antidote]

Nice, I'd like to see your research on the STB files, I abandoned my project on them.

[Vexiant]

I do concur with the above poster.

[Sage of Mirrors]

Well, here's a document that I've compiled on the JFVB object. It's the only entirely unique object type, as the others share the same structure. JFVB does not. Enjoy:

 

 

JFVB holds data used for animated actions. Typically these actions are only related to the camera (JCMR), but it's possible that

other objects could use it, too.

 

Different commands utilize the entries in the FVB object for different things. The animated Field of View and Roll commands use

1 entry, while the animated camera and target positioning commands use 3 - one entry for each axis (X/Y/Z).

 

JFVB consists of a header that is 18 (hex)/20 (dec) bytes long, and a variable number of entires, which themselves 

are variably sized. The header begins at offset 0x20 (hex)/32 (dec) in an STB file, and follows this format:

 

/*+0x00*/ int totalSize; //size of the object from 0x00

/*+0x04*/ string "JFVB";

/*+0x08*/ string "FVB";

/*+0x0C*/ Unknown; //shouldn't worry about it, it's the same everywhere

/*+0x10*/ int fvbSize; //size of the section from 0x08. I dunno, it's weird

/*+0x14*/ int numEntries;

 

The entries themselves seem to mimic the other objects in that they are technically composed of commands, but the structure

is the same across nearly all of them. The first entry in an FVB object is at 0x18 in the object, or 0x38 in the entire STB file.

These fields are common for all entry types:

 

/*+0x00*/ int entrySize;

/*+0x04*/ int16 entryType;

 

The entry type seems to determine something, but I don't know what yet. The majority of the entries have a type of 5, but some

have a type of 6. There are major differences in commands between the two.

 

In a type 5 entry, there are typically 3 commands - animLength, interpType, and data. While these follow the command syntax

found in the other object types, I will forego explaining it here in favor of doing it elsewhere where it would be more

useful. The offsets of the commands are as follows:

 

+0x08 animLength

+0x14 interpType

+0x1C data

 

animLength is C (hex)/12 (dec) bytes long, and seems to give an inconsequential estimate as to how long the animation is in-game.

The relavent floating point data can be found at 0x08 relative to the command, or 0x10 relative to the start of the entry itself.

 

interpType seems to be how the engine interpolates between the points. The default value is 3, which is a smooth spline

running through each of the coords. The data here begins at 0x04 relative to the start of the command.

 

data holds what JFVB was designed to hold - floating point coords. It is structured like so:

 

/*+0x00*/ int16 loadLength; //length of the command starting from 0x04

/*+0x02*/ int16 commandType; //this just indicates that it holds the coord data

/*+0x04*/ int numCoordPairs;

 

Coords start at 0x08 relative to the command, and 0x24 to the entry. They are 8 bytes long. The first 4 are the

interpolation timestamp, and the last four make up the actual coordinate.

 

The timestamp controls when the engine interpolates to the coordinate that it preceeds, which controls the speed

and smoothness of the animation. They act as a sort of timeline, giving the engine at what time since the animation started

it should be at the coord. The data is length in seconds, encoded in floating point.

 

Every entry is padded at the end by 4 null bytes. These are counted in totalSize and fvbSize, but NOT in the data command.

 

 

 

 

[Antidote]

That's how I was thinking it was formatted, but I never got around to checking. Nice to know I was at least heading in the right direction.

[xdaniel]

Just wanted to say, it's really cool to see people actively working on improving Wind Viewer. Sage of Mirrors, Lord Ned, Abahbob, Pho, anyone else - you're awesome.

[Vexiant]

I'm more focused on Super Mario Sunshine and Star Fox Adventures.  And Bravo on the JFVB documentation. I posted it on spin's wiki, I figured you wouldn't mind.

[lawatson]

All this work being done is so amazing, yet I wish I had the brainpower to understand the numbers and letters everywhere.... I'm not the programmer type just yet. I still can't wait for everyone to contribute more to this, though!

[Vexiant]

Programming follows a syntax just like English (obviously being intertwined with numbers and not /looking like any native tongue/), huehuehue

[Antidote]

Decided to take a look at JPC files and managed to crack the format's structure in less than an hour:

struct JPASectionEntry
{
    char Type[4];
    uint Len;
    ubyte data[Len - 8];
};

struct JPASection
{
    ushort Unk1; // ?
    ushort SectionCount;
    ushort Unk2; // ? seems to be multiples of 2: 0, 128, 256 and 512 are common
    ushort Unk3; //   ""
    JPASectionEntry Sections[SectionCount] <optimize = false>;
};

struct Texture
{
    char Tag[4]; // TEX1
    uint DataSize;
    ubyte Data[DataSize - 8];
};

struct
{
    char Magic[8];
    ushort unkCount;
    ushort textureCount;
    uint textureOffset;
    JPASection unkSections[unkCount] <optimize = false>;
    FSeek(textureOffset); // A gap between the sections and textures isn't uncommon, so a seek is a good idea
    Texture Textures[textureCount] <optimize = false>;
}file;

[Antidote]

As proof that I know wtf I'm talking about I dumped the particle textures from common-r.jpc and converted them to PNG:

https://dl.dropboxusercontent.com/u/21757902/TP_Particles_common-r.zip

[Antidote]

Been working with the collision format (kcl), and I now know all the potential flags:

Basically take everything you know about MKWii's KCL flags and discard them, all knowledge acquired from them is useless.

 

The collision flags can have a value from 0x00 to 0x54, I currently don' t have their effects documented but I'm going to start working on that now.

Some help would be greatly appreciated, I can provide the KCL viewer for those who need it.

[Sage of Mirrors]

TWW doesn't use KCL. It uses DZB. Exactly what format are you RE'ing here?

[Antidote]

This thread is for both TP and TWW, last time I made a TP Specific thread it got merged into this one.

[Sage of Mirrors]

Alright. I got confused. Apologies.

[Antidote]

Or maybe I'm an idiot, and got my threads mixed up >.>

@Mods, can you please move relevant posts to the correct thread?

[Antidote]

I'll be adding comments and elaborating on some points, but here is my 010 Editor template for RARC Files. I'm releasing it as GPLv2 but any resulting code is yours:

http://pastebin.com/gw11cGFA

http://http://pastebin.com/qFarfjk2 -  Elaborated version

Edited June 13, 2014 by Antidote