Sage of Mirrors

I've been looking into how general objects are placed, and I believe that I've figured it out. While room models are stored in rootIwamotomap2, there is another file by the name of map2 rootMap. This .szp file contains many different files, including effect models available to the set of rooms and path files. However, there is also a set of files in the folder "jmp" all ending in -info. "enemyinfo," for example. There are a TON of these. The most notable, I assume, would be "enemyinfo," "characterinfo," "roominfo" and "furnitureinfo." characterinfo seems to deal with cutscene and event actors. The file for the main rooms of the mansion (since almost the entire mansion is considered one map) begins with a header 0x13C bytes long. I'm still looking into it at this time. There are many entries after the header. These entries are 0xB8 bytes long, and begin with the name of an archive in rootmodel. I'll use what I believe to be the first ghost in Event01 as an example. ASCII: demobak1........................----............................(null)..........................demo_obake.........................#..........................XbÂÅaHDV±ìÅ.éš....AÙš.... Hex: 64 65 6D 6F 62 61 6B 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2D 2D 2D 2D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 6E 75 6C 6C 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 65 6D 6F 5F 6F 62 61 6B 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 62 C2 C5 61 48 44 56 B1 EC C5 1F E9 9A 00 00 00 00 41 CD 99 9A 00 00 00 00 Here, the first few bytes in ASCII are "demobak1." We also see the text "(null)" and "demo_obake." demo_obake is the name used in the actor instruction for the first ghost; decompressing demobak1 reveals animations using the name scheme "y_tdmxx." Animations using this same scheme are used in <ACT> portions of <ACTOR> for demo_obake. Thus, demobak1 is the object name while demo_obake is the name used for events. More information to come.

I've been looking into Luigi's Mansion recently. I've found out a few things, but that's just it- a few. Luigi's Mansion is so different from both SMS and TWW that most of the models and animations are in a different format. Now, Luigi's Mansion uses YAY0 (.szp) encoding on all of its files. The program ArcExtract can decode YAY0 and unzip whatever archive type LM uses, but a stand-alone YAY0 extractor I have doesn't seem to work, as it spits out some kind of file that looks nothing like an archive to me. Because of this issue, no custom files can be put into the game at this time. Just wanted to make that clear for everyone. Cutscenes and events are stored in root\Event. They're .szp files with the naming scheme "Eventxx," where x is the number of the file. There is Event01, Event02, Event03, ect. When unzipped using ArcExtract, there are typically two folders- "message" and "text." "message" contains a .csv file holding all the text for that cutscene, and "text" contains directions in a .txt file. Other files, however, can also be found in certain archives; these files, .cmn and .lig, are not contained in a folder and deal with camera movement and lighting, respectively. The .txt files are named for their event. Their structure is pretty simple, and thus they are somewhat easy to understand. Instructions are contained within < and >, while arguments are normally placed within ( and ). There are also at least two different ways to indicate a new section, which are the equal sign (=) and dashes (-). Almost all instructions are placed between the instructions <FRAMESTART> and <FRAMEEND>, which seem to denote different scenes. There are often instructions before <FRAMESTART>, however. Some of these are: <MENUOFF> Disables the ability to call up the pause menu. <FULLSCREEN> Disables the HUD. <FLAGON>(xx) Sets a flag, where xx is the flag number. <BGM>(xx) Sets background music, where xx is the music index. It's possible that this index is the sequence's index into the game's JaiarcS. <LUIGISTOP> This one is less clear, but it's likely that it disables movement, makes Luigi stop where he is, or both. <NECKOFF> I have no idea what this could be, but its possible that it could disable use of the vacuum. <NOWEAPON> Disables vacuum? It's only found once, at the start of the event where Luigi meets Prof. Egadd. Following <FRAMESTART>, there a multitude of different instructions. <ACTOR>"xxxxx" This is an essential one. x is the name, in ascii, of the actor it calls. Since there is nothing previously declaring actor names in the .txt, I assume that names are stored elsewhere. <ACTOR> is the root of a few other instructions, as well: <ALPHA>(xxx) Determines the visibility of actors. x is a number between 0 and 255. 0 is invisible and 255 is completely solid. This is probably used primarily for ghosts, though it could also be used for some cool effects. <MASKOFF> Disables... masking? A note in Japanese relating to <MASKOFF> references disabling a shadow; because ghosts normally make a pulsing light below them on the floor, this might be what it disables. <SHADOWOFF> Disables shadows. <COLOFF> Unknown. Maybe it disables collision? <POS>(xx)(yy)(zz) Assumedly moves an actor to the specified (x,y,z) coordinates. <ACT>"xxxxx" This is the most important instruction related to <ACTOR>. x is the name of an animation to be played in ASCII. <PATH>"xxxxx" Not currently known. Other instructions include: <WINDOW>(x)<COLOR>(y)<SPEAK>(z) Opens a text box, sets the background color and calls text to be displayed. It is currently unknown how the text is indexed. <CHOICE>"xxxxx"(y)"zzzzz"(a)<LISTEND> This is a bit complicated. It controls dialogue options, with x and z being names of the variables in ASCII. y and a are the text indexes of the options. There can be more than two variables. <ANYKEY> Found often after <WINDOW>. It probably tells the game to wait for the player to press a button before moving the text along. <CHECKFLAG>"xxxxx" This checks a flag, the name of which is in ASCII and goes in x. There can be multiple flags to be checked. <CASE>"xxxxx" Seems to have multiple uses. It works with <CHECKFLAG>, working like an "if, then" statement. In this use x is the flag that makes it run. It also works with <CHOICE>, where x is the name of the variable. <WAIT>(xx) Pauses the script for x amount of time. <RANDOMJMP>"xxxxx" Despite its name, this isn't random. It jumps to the <CASE> instruction specified in x. <CAMTARGET>"xxxxx"(yy) Moves the camera towards the actor in x. y is an unknown variable, but might have to do with the distance between the camera and the actor. <SE>(xx) Plays a sound effect. x is the index of the sound effect. <FLAGON>(xx) Turns the flag specified in x on. <FLAGOFF>(xx) Turns the flag specified in x off. <COUNTJMP>"xx" This instruction is ambiguous. x is a number, and there are often other numbers with it. It can be used with <CASE>. <WARP>(xx) Warps the player to another room specified in x. <GENON> It might be a flag that determines if you can capture a Portrait ghost. Note that, according to google translate, the word for "vacuum" in Japanese begins with the the letters "gen." <CLOSEWINDOW>(xx) Closes a window, obviously. x is unknown. <ALLSTART> Might have to do with ghosts. Specifically, the vacuumability of Portrait Ghosts. <HLIGHTON> Turns the flashlight... on? A Japanese note near this instruction references turning the flashlight off. <HLIGHTOFF> Turns the flashlight... off? <TIMEACTIVE> Unknown at the moment. <GCAMERA>"xxxxx" Calls a .cmn file, named in x. <GCPATHLIGHT>"xxxxx" Calls a .lig file, named in x. <LEVSE>(xx) More sound effects, but it's unknown why it has two instructions. So, for instance, a cutscene in which a golden puncher ghost talks to Luigi would look something like this: <MENUOFF> //Disable menu accessibility <NECKOFF> //Disable Vacuum accessibility <FULLSCREEN> //Disable HUD -------------------------------------- <FRAMESTART> //Start of the sequence <ACTOR>"demo_obake"<ALPHA>(180) //Sets Ghost's opacity <ACTOR>"demo_luigi"<ACT>"L_TDM01" //A Luigi animation (this one's a placeholder) <ACTOR>"demo_obake"<ACT>"H_TDM01" //A Ghost Animation (this one's a placeholder) <WINDOW>(0)<COLOR>(1)<SPEAK>(1) //Dialogue box <ANYKEY> //Wait for the player to press a button <WINDOW>(0)<COLOR>(1)<SPEAK>(2) //Another dialogue box <CHOICE>"scared"(1)"notscared"(2)"huh"(4)<LISTEND> //Start dialogue tree <ANYKEY> //Wait --- <CASE>"scared" //If the player chose the "scared" option... <WINDOW>(0)<COLOR>(1)<SPEAK>(6) //The ghost says something... <SE>(4) //Laughs... <WAIT>(5) //Waits... <ACTOR>"demo_obake"<ACT>"H_TDM01" //Starts to disappear... (animation not real) <ACTOR>"demo_obake"<ALPHA>(0) //And its opacity is set to 0 <NORMALSCREEN> //Returns HUD <MENUON> //Allows menu access <NECKON> //Allows Vacuum <FRAMEEND> //Ends scene <END> //Ends instructions Note this this could be horribly wrong, and would probably need to be revised if it were to actually be placed into the game. This game has a ton of secrets to unlock, but I feel confident that we will discover them in time.

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.

I've probably posted this before, but meh. We need some stuff here. Event_list.dat. We've figured out that it's how the game handles less important cut scenes, such as what occurs when a Redead attacks you. Event_list controls camera movements and animations at the least, and it might control things such as item acquisition; however, it does NOT (from what I've seen) control text. The file itself starts with a section of entries. These entries are B0 bytes long. They each begin with a name in ASCII, which seems to have 20 bytes allotted for it; this name can be referenced in a DZS file under the EVNT heading to be used in-game. The next 5C bytes are allocated for instruction index numbers (see below); each index number uses 4 bytes, and any unused space is nulled with FF bytes. The instructions in this section seem more related to animations and control lock-out, but it needs more investigation. The 18 bytes following the last section are more index numbers. These instructions seem to be geared towards camera movement, but again, more investigation is needed. Unused space is nulled with FF. The remaining 1C bytes are 00, with no functionality. Beneath the index of entries, there are several sections of instructions. Like the ones above, these instructions begin with an ASCII name. Each instruction has an index number, starting from 0. This number is 25 bytes from the start of the instruction, and has 4 bytes allocated for it. The bytes after the index number seem to be more index numbers, seemingly for the section below. Those instructions are more specific, and each has an index number. Those have MORE numbers, for the section below them. I don't know how far this goes; at some point the instructions disappear and are replaced with ASCII-less bytes, possibly machine instructions. After that, there's an odd section that leads up to the end. It has ASCII such as @PLAYER, @STARTER and @TALKPARTNER. I have no idea what this is for. The file ends with a list of the .stb files used. So. Can anyone spare me some help in figuring out what the indexing is all about? I can't figure it out.

Not Wind Waker, but interesting nonetheless: The top image I ripped from Twilight Princess. The bottoms is for comparison. Looks like they planned to have a Mirror Shield in Twilight Princess! That, or this icon was used in some kind of test. Most likely the latter.

New video! This one of Chrono Trigger's Zeal.

Well, would you looky here... This is what Tetra says before she and Link go off in search of a new Hyrule. It's shown in the .thp, but that's obviously a recording- that means that this text is unused! I took a look, and there are two Demos that aren't used- Demo37 and Demo46. These are the ending (Link and Tetra on the surface, seeing Tetra's ship) and the epilogue (Link and Tetra leaving). So this proves without a doubt that they intended to handle the end and epilogue in the same manner as the rest of the cut scenes before something happened that made them change it to a .thp. I wonder what it was? What's more is that the JMSG entry in the epilogue's STB points... to Niko's explanation of the first platform puzzle. Maybe the text was moved at some point?

Hmm... that Dark Link person over on Jul introduced me to Framework.MAP. It seems to be a map of where EVERYTHING related to gameplay is stored, both somewhere (the .dol?) and what I believe to be RAM ('Virtual Address?'). With this information, I think we could begin making assembly hacks. Theoretically, anyway. Kargaroc, where did you get that build of Dolphin that has a disassembler built in? Can I get a copy to test if these locations are correct? There isn't a 'Framework.rel' and I'm not entirely sure that these commands are in the .dol.

Here's Deku Palace. I did more with the MIDI this time; I made it longer and added some parts. Still nothing too major.

I got Reason a few weeks ago, and I decided to try my hand at something with it. I found a MIDI on the Internet and picked the instruments. It's nothing too big. I thought it would be nice to just get my feet wet with the program. I might do some more songs later on... How'd I do with this one?

So, here's what I've gotten in the realm of collision. I found a three-byte section that I thought was water collision in the .dzb for the room of the Tower of the Gods. But... it wasn't. It didn't do anything water-related. These are the only things it affected, oddly. I replaced all instances of C5 7A 50 with C5 9C 40. I don't know how this will help (if at all), but I'm worn out for now.

I really like that version of Dark Beast Ganon. The instruments you chose go with it very well.

Uh-oh... where's the pink-haired elf when you need her? This is actually running on the Wind Waker ISO. I replaced the Nintendo logo in Logo.arc and got this. Since the game overlays a red pallet onto it (everything white is red), I picked this guy's insignia to test. I think a modified version will become sort of my Youtube emblem. It could use some repositioning, but it's a nice way to end the day- with no hanging. Also, props to whoever knows what I'm referencing. Wait, I take it back. THIS is the screenshot of the day for me.

Cool! You'll have to give links to the stuff you used. I think editing AI will be a large part of hacking for, say, items (which I think I have a couple ideas for...)

From looking at Event_List. dat files, here's what I've got figured out: 00 00 00 40 00 00 00 60 00 00 42 40 00 00 01 5E 00 00 AF A0 00 00 04 57 00 02 0A D0 00 00 05 2D 00 03 56 10 00 00 04 C6 00 03 69 28 00 00 02 37 00 03 72 04 00 00 07 D8 00 00 00 00 00 00 00 00 Every 8 bytes is a 'pair.' That is, the first four bytes are an offset to a section, and the second four are the number of individual entries in it. The first pair point to the start of the 'header' section. EVNT from the .dzs files use the names of these headers to do events, but I'm not sure exactly what they do. There aren't any offsets in these headers (which are 0xB0 long), so I'm guessing that the engine might use some sort of indexing system to get the data related to these headers. The second pair refers to what seems to be a large part of the file. This section contains entries 50 bytes long with names like CAMERA, TALKMAN, MESSAGE, TIMEKEEPER, DIRECTOR, PACKAGE and ALL, various actor names (Link, Bomb, Ship, ect.), and misc. stuff like 'Fire' and 'Zenfire.' Again, these have no offsets, so whatever the game uses these for it must use an index system. I have no idea what they could be for; instructions for the events, maybe? The third pair marks a similar section to the pair above; entries here are still 50 bytes long, but have different names- I've seen WAIT, NEXT, COUNTDOWN, PAUSE, UNITRANS, MES_SET and TALK often, along with several others. No clue what they're for. More detailed instructions? The fourth pair goes to yet another set of entries, these only 40 bytes long. They seem like the actual event commands- they use names like Stage, RoomNo, Layer, Startcode, MsgNo, Trim, Fovy, RelActor, RelUseMask, Center, Eye, Timer, TransType and BGCheck. Some of them sound camera-related. The fifth pair introduces a different section. This has no ASCII. I'm guess this is either assembly or camera directions. Entries here are 4 bytes long. The sixth pair is the same as the fifth- no ASCII. But this section is a bit more spread out (has more bytes that are just 00). Entries are also 4 bytes long. The seventh and final pair indicate an... odd section. I have absolutely no clue what this is for. Some ASCII here includes (repeatedly) @PLAYER, @STARTER, @PARTNER, @TALKPARTNER and VISTA, with names of room folders, .stbs (some that don't exist, even) and other oddball things, like --or, --on, --tt, --oo, --oc and op, scattered around. There's probably some structure to this, I'm just not seeing it right now. This section is an exception to the the offset-entry number pair- in this case, the seventh pair indicates offset-length. And there we have it. Stuff to look into, for sure, but now the main structure's documented. I have just confirmed my suspicions- in each header, there are groups of 4 bytes that point to instructions in the second section of the file by their index. These bytes point to camera directions, Link's animations and possible other things, like player control and NPC animations. Here's an example: The ID for Link's 'Looking around' animation, which normally plays here, is 1D (and 62, I believe, though 1D might be a neutral pose). In the same .dat, the ID for Link's 'Telescope get!' animation (which comes with the telescope, apparently) is 1D7. By replacing only those two IDs, we change the animation Link does during this event- though, after his animation ends, it waits for Aryll's command to look out at their house, which never comes. Now, camera and NPC animation is controlled in the same way. Text... I haven't gotten to that part yet, but one of the IDs in AJ_SPEAK leads to TALKMAN, which at some level holds the text pointer. I hope. Speaking of levels, that's how Event_Lists work- The headers are the highest level, while op codes (I think?) are the lowest. Each entry at the second level has an index and IDs that lead to other entries in the third level, then that entry has an index and IDs to the fourth level. Then we get to the fifth level. At that point, you get a pair of bytes that probably translate to an op code and extension. What the sixth and seventh levels are for... I'm not entirely sure. Each header has a 'top' section, where most of the IDs I've seen are, and a 'bottom' section made up of 10 bytes boarded on either side by multiple FF values. I wonder if these ten bytes go to the sixth level?

Cool! I could see a few applications for that... I also found something out. There a plethora of entries called 'kusax#.' Now, I found out that 'kusa' means 'grass' in Japanese, so I think it's obvious what they are now. The number differs from entry to entry, so I'm thinking that the number is how many pieces of grass are in a group. Theoretically, we might be able to change that number in-game by changing the name, but I haven't tried that yet.

Well, I'm pretty sure STAG sets room properties, like item usage. I'm sure it might control some other things, too... SCLS is definitely an exit list. There's only exits there. There's a thing called EVNT? I'd better look at that! By the way, Xdaniel, your release of Wind Viewer isn't going to waste! I've done a small little thing to demonstrate what it can do. I just haven't gotten around to filming it yet. BINGO! I've JUST discovered what event_list.dat is for! It... well... holds events! Events like camera movements, animations and text boxes that are too common to need an STB. Watch this: I replaced the data under the heading AJ_SPEAK (the event that makes the old man on the balcony shout out to say 'L-Target Me!') with that of the heading called DEFAULT_RD_SCREAM (or was it 'ATTACK?'), making the game react as if Link had been within reach of a Redead's scream. I usually do this stuff without sound, so I'm not sure if the scream itself plays; I'll look into that in a moment. Now, the petrified effect doesn't end. I'm pretty sure this has something to do with the fact that the Redead's AI controls this stuff... Now, there's three sections within the Event_List.dat; a section that has the names of events within it (eg. AJ_SPEAK), a section that probably contains what these names go to and a third section with a purpose that I don't know yet. I think this is a pretty nice development! Maybe cut scene stuff ISN'T in the .stb, after all...

I remember having a dream or two about beta WW stuff. One was that I found this test area with Jabun. He was just repeating his 'rising from the ocean' animation, but when I jumped into the (clear) water, he started chasing me (Link, that is) around like an enemy. Then he suddenly opened a portal from Metroid Prime 2 and threw Link into Sanctuary Fortress. Weird. Then there was another thing I don't quite remember... all I remember thinking during the dream was, 'Wow, I need to tell those guys (you all here) about this!!'

YES. This is completely awesome in every way! You may or may not see an example of what a hack could look like sometime soon...

If you look at it, the symbol resembles the Shadow Sage's emblem: Could the original Shadow Medallion have been black? Or maybe the purple just doesn't show up well with that quality. The medallions seem to have become a little rounder than before, too. You know, from that video, I think the order of the Sage emblems was changed in the Chamber of Sages. Here's what I think it is in that video: ----------Shadow Light----------------Water (Ice) Forest--------------Spirit ------------Fire ...but as we all know, that order is this in the final:

bb_player_view_check__FP8bb_class I'm pretty sure that this entry in the Kargaroc's .rel (found with the .map) is what checks if the Kargaroc can see Link. Perhaps I can do something with this.

Hey, I have a question. .map files document .rels, right? Does that mean that we can use .map files to tell what's in .rel files? SRS (0010 1000 0000 0000) ADDR (0100 0000 1000 0010) LOOP (0000 0000 0100 0000) ANDC (0011 1100 0110 0000) NOP ORR (0011 1000 0110 0011) NOP NX (1000 0000 0110 0011) NOP MULX (1010 1000 0000 0011) LOOPI (0001 0000 1101 0110) SRS (0010 1100 0000 0000) DAR (0000 0000 0000 0110) ADDR (0100 0001 1000 0010) DECM (0000 0000 111 1000) ANDC (0011 1100 0110 0000) NOP This... is the first 24 bytes of a section in Gohdan's .rel that its .map labels as (and I quote) 'bom_eat_check__FP9bst_class,' meaning that the section this is from is, going by the name, a check for whether or not you've thrown a bomb into Gohdan's mouth after hitting both of its eyes. However, I have NO idea if this is actually right. This could all be a bunch of gibberish, for all I know. However, some if it does make sense; SRS, for example, is supposed to store a value to 'register 18' (whose purpose isn't known). If I interpreted the format of that particular opcode right, that SRS code stores 0000 0000 to the 18th register. That ADDR that comes next adds that exact same register ($18+S, where S is 0 in both opcodes) to one of the accumulators (which I don't completely understand as of yet). Alright, I think that I've come to understand that the accumulators are where the Gamecube stores the results of arithmetic. Then it loops that until, one would assume, both of Gohdan's eyes are shot and he falls, triggering the ANDC, which preforms an AND operation on the same accumulator that the ADDR wrote to. While I don't really know what this is, from my perspective, this seems correct. Can any of the other, more opcode/ASM-savvy people here confirm if this section could be part of a check? Or maybe even if it looks right? :S

Ooh! Can I make an icon to go with Wind Viewer, XDaniel? You know what, I made one anyway. What do you (guys) think?

I was able to both block the sun and get the movement by adding the model and btk into Outset's .arc. It's black and white probably because it's only set to turn blue when you get the Master Sword. I wonder if there's a way to force it to its colored version. Going out of Outset's square leads to the model simply disappearing. I'm wondering if there would be any kind of bump when switching between two islands with that model.

AHA! With that packer, Kargaroc, I've done what I've been wanting to do for a while- port the 'Underwater' effect to other maps! I replaced 'vr_sky' in sea's stage. ...ahem. However, there are two things: -The regular sun is still there; I'll have to see if I can change that with the STAG .dzs entry. -The regular model in Hyrule shimmers. This one... doesn't. It looks a bit odd. I think we can confirm now that .btk files have to do with... texture animation? At least animation-like effects.