Sage of Mirrors

New release: https://github.com/Sage-of-Mirrors/Ocarina-Text-Editor/releases/tag/v1.0.3 Adds the ability to save to both the ROM that was originally opened and a new ROM. Also adds the ability to load MessageList.tbl and StringData.bin files, meaning you can now open the result of saving to Extracted Data.

It was fake. The image is a cropped and slightly edited version of another image elsewhere.

This is a text editor for the Master Quest debug version of Ocarina of Time. It has the ability to add and remove messages from the list, and it automatically adjusts for bigger or small amounts of text in a message. No more space limitations due to hex editing! Currently, it can only open a big endian debug ROM, and it can save to another ROM, to a PPF patch, or to two files (StringData.bin, the actual string data, and MessageTable.tbl, the message list). There are minor improvements to be made, but it is unlikely that any major changes will be made to the program. Github Link: https://github.com/Sage-of-Mirrors/Ocarina-Text-Editor Current Release: https://github.com/Sage-of-Mirrors/Ocarina-Text-Editor/releases/tag/v1.0.2 Wiki: https://github.com/Sage-of-Mirrors/Ocarina-Text-Editor/wiki

Alright. I got confused. Apologies.

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

Where can these non-model models be found?

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:

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.

I went to the Modifications board, all ready to pin the Wind Waker Hacking thread But it's already pinned I am disappoint

Nothing new to report in the past few months. I've still been documenting the STB files, but I'm having trouble with them. I can't figure out how the engine assigns JACT chunks to the models in the archive. I originally thought that it had to do with the order both the models and the JACT chunks are in the RARC/STB file (As in the first model gets the first JACT, the second model the second JACT, ect.), but after several attempts to put the King of Hyrule into the title screen's STB file, I'm starting to think that that's not the case. Could anybody lend me a hand in looking at these files? Also, another thing I've been doing is trying to trace where the Wind Waker direction/notes are stored. However, I haven't had much luck yet. I've looked at the code in the .dol, but since I can't read PPC that well, I couldn't find anything. Having custom Wind Waker songs is a must. I'd appreciate some help in this area, too. Ha! I did it! What this is is the King of Hyrule's model and a wait animation inserted into the archive of the title cutscene, Demo51. I found out that model assignment is actually a command in the JACT section, 04 07 39. While I was able to get this working, I'm still not entirely sure how it works... I know 04 07 39 assigns a JACT to a model, but the source of the argument for that command that decides which model to use isn't clear. What I had to do to make the King work was cycle through values starting at 00 to find the ones that the game wouldn't error on. I still have to look into it, but I believe it has to do with the files' entry in the RARC header - that is, the chunk for those files that determines their size and location in the archive.

I see. My apologies.

I'm not sure if I believe it. That head model looks way too nice to be original to the game. An early April Fools prank, perhaps.

XD I mistook this for a PM for some reason! CAn someone delete this post?

"...Grandma, you're on fire again..."

Got some info on some of the chunks in cutscene files. JSND controls sound effects and music. This is the header: xx xx xx xx 4A 53 4E 44 00 00 00 zz yy yy yy yy yy yy yy yy Where: X = Size of JSND chunk Z = Unknown Y = ASCII ID of chunk ("SE" and "sound" are common names here. I don't think it matters.) The actual entries are surprisingly regular, and are 0x18 bytes long. 02 00 00 xx 80 00 00 10 00 04 07 99 yy 00 zz zz 00 04 05 C2 00 00 00 00 Where: X = Delay before sound is played Y = Type of sound: 00 for a sound effect, 80 for a sequence file, and C0 for a stream Z = Index of desired sound effect/sequence file/stream JMSG is similar, and deals with text. 02 00 00 xx 80 00 00 08 00 04 08 59 yy yy yy yy Where: X = Delay before displaying string Y = Entry number of desired string There's usually a second portion to JMSG, called "control." This section deals with what the cutscene should do when text is displayed - namely, if it should wait until the text box is closed to continue the scene. Unfortunately, it's not that simple, and the only thing I've really got is the entry length and the variable: 02 00 00 xx 04 00 00 01 Where: X = The variable. What this actually does isn't quite clear. Changing it to a high value causes some of the strings to fill one text box and overflow it while the cutscene plays without stopping, while a lower value tends to stop the text box from displaying at all. My theory at the moment is that this value is related to something in the Jstudio chunk, which I haven't gotten around to digging into yet. JPTC deals with particle effects. It's actually pretty simple. Here's a sample entry: 00 00 00 74 4A 50 54 43 00 00 00 xx xx xx xx xx xx xx xx xx xx 00 00 00 02 00 bb bb 80 00 00 34 00 07 06 18 yy yy yy yy yy yy 00 00 00 0B 06 38 zz zz zz zz zz zz zz zz zz zz 00 00 00 04 06 42 00 00 00 01 00 04 08 99 aa aa aa aa 00 04 05 C2 00 00 00 00 02 00 00 5E 80 00 00 10 00 04 04 02 00 00 00 00 00 04 05 E2 00 00 00 00 02 00 00 08 00 00 00 00 Where: X = Unique ASCII ID of the entry Y = Actor within STB file associated with particle effect Z = Bone in actor to attach the effect to A = Particle effect ID B = Delay before effect is rendered I was able to attach a particle effect to Grandma by simply changing Y to "Ba1" and Z to "neck:" There are probably more variables in there, such as what particle bank to call from.