Sage of Mirrors

Edited my previous post with something I found.

Yeah. I was able to play some of it- the tgc is zz_marioTaiken5.tgc. It's largely the same as the retail version. Found a difference! These enemies retain their flower heads when jumping towards you in the final.

It's... just a demo though. Seems to have everything that the normal version has... I'm downloading a .tgc converter/extractor, so maybe I can get in and actually play some stages without dolphin crashing itself/my computer...

I'm downloading it now. What is it, I wonder?

Well, It would basically be what I did with Wind Waker when I first tried to get the beta maps to work- move the model and its resources over something that you can see clearly. But now I've seen that SMS stores its data in a very different way than WW- it has no outside resources. Every level file is self-contained, and SZS-d to boot. Now, Wind Waker can read de-ya0zed .RARCS just fine. Not sure how SMS would react to them. I can't do it right this second, but I'll go a bit more in-depth to what I'm thinking would work a little later.

Strollin' Stu is actually still in the game's files- it loads in one of the debug rooms, but then falls through a wall. I thought about trying to port it to other maps (IE in place of Petey Piranha), but I never got far with that idea.

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. 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.

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...

Oh, and OK. I understand that. Hey, Xdaniel? What version of the ISO are you using? PAL? I'm using a US ISO and the only entry I can find with 0x0322 has CF0F before it.

Edit: Ha ha, didn't notice the new page.

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.

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 00For 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 00xx 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 00xx 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.

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? 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: 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...

They way Link's eyes are rendered reminds me of Eve from WALL-E...

Been playing around with the audio recently. I've learned that the .afc files in the Stream folder are tracks played during cutscenes and the title screen. I believe that the .bms files held in the JaiSeqs.arc are the tracks played in playable areas of the game; these seem to use the .aw files, which store sound files like enemy voices and even instruments (there's a program to extract them, but sadly there isn't any documentation). The game can only use files from a .aw that it has loaded (duh), but I'm not sure how it decides which ones to load; I'm looking into the .dzr and .dzs files to see if sndpath has anything to do with it. Edit: In the file called d_a_tag_event.rel: Bk.mo2.dragon.SUPERELF.fairy_flag_on_Jmp.fairy_Jmp.BEAST_GATE2SUPERELF! lol. Must mean the Fairy Queen. Wonder what this file does? The rels have no ASCII, aside from the rare things like this. Maybe they're actor scripts?

Looks like Old Man CNJHWRUT3IFJY! I've actually been on a quest of my own. I'm trying to figure out the structure of .rarc files so that I can add the sky model from Hyrule (the one that looks like the surface) along with its .btk to Outset's archive to see if I can make other maps have it. I was actually kind of miffed when I found out it was an actual model and not a set of values in the .dzs XP

Interesting fact of the day: If you don't have the bow when you start the Gohdan fight, he sneezes out green rupees instead. Weird. I was messing with the exits, and I made the exit to one of Outset's islands the Tower boss room. Now I'm going to try replacing room19 with the boss room. It seems that stage.arc files (found in the same folders as the map arcs) hold the data for misc stuff that doesn't fit into the .bdl or the .dzr, like doors. But I've also found another file in the stage.arc called stage.dzs. It has the same format as the dzr (Chunk headers that give the number of individual blocks and the offset of the first block, followed by the actual information). These have unique headers, and the headers in SirenB's stage are as follows: -STAG (No idea, contains one data segment) -RTBL (No idea, contains one data segment) -SCLS (This one doesn't make sense. It has two exits, one that is headed to the main Siren folder and one that's directed to itself, the SirenB folder. Huh???) -FLOR (Literally the number of floors? Inside Forest Haven has only one of these, while TotG has 4 and Forbidden woods has 5. Might be, as a quick look-up of the two dungeons shows that they have the same number of floors as they do segments in the FLOR chunk) -TGDR (Unknown, has one data segment) -MULT (Unknown, one data segment) -DMAP (Unkown, one data segment) -EnvR (Unkow) -Colo (Lighting/time of day) -Pale (Fog) -Virt (Fade distance, I assume. Makes the surroundings gradually fade to black, while keeping geometry visible) -RCAM (Unkown, one data segment) -RARO (Unkown, one data segment) There are also some misc. stuff that's I've come across: -EVNT (Cutscenes?? The data here has stuff like 'meet_deku,' 'getperl_deku' and 'BOSS_WARPOUT' for Inside Forest Haven) -LGHT (Gee, I wonder if this is Light? ) -PATH (No idea.) -AROB (No clue!) -PPNT (No clue) I'm thinking that most of these (such as EnvR and Colo) might deal with environmental things, like fog and particles such as the ashes in Dragon Roost Cavern and forest debris in both the Forbidden Woods and Forest Haven (might be prudent to cross reference those two to see if they have anything similar; might lead to knowing which header controls those particles). No clue what the others could be.

I still can't believe that I was able to make room19 to load. I feel excited! Now I'm trying to figure out a way to see it in it's own group, with correct environment settings and whatnot. I'm thinking an AR code, but it might also be possible to see it through the debug menu that's been discovered. I'm also looking to see room20 in M_dai, a beta version of the first room in the Earth Temple.

Heh. It uses 0x0A to determine line breaks, it seems. Argh! It's midnight on a school night! How terrible is that? I need to go! (At least I'm a hacker now...!) It's morning, so I'll add one more thing: 4C 69 6E 6B 00 00 00 00 FF FF 00 14 05 00 00 00 46 20 84 00 C6 27 B0 00 00 56 80 00 FF 00 FF FF These are the values for the PLYR I put in room19. Here's what I came up with when figuring out positions: -0x46, 20 and 84: Z (Up and Down); changing 46 makes the actor move a very large amount, while chaning 20 makes it move only a little. Changing 84 is an even smaller change. For this, the format may be that the 17th, 18th and 19th bytes control up and down position. -0xC6, 27 and B0: X? (Left and Right): Same format as above- first moves a lot, second a little, third even less. Might generally be 21st, 22nd and 23rd bytes. (Changing the 00 between Z and X didn't do anything, so maybe it's a way for the game to determine what's what.) -The second 0x00 after 0xB0, the 0x80 after 0x56 and the 0xFF after the second 0x00 control rotation; changing 0x00 rotates the object backward and forward, changing 0x80 spins it left and right, 0xFF spins clockwise and counterclockwise. 0x56 and the second 0x00 don't change anything. Might be the 25th, 27th and 29th bytes for all files. Now, I have to go to school, so I'll finish this later. Right now, though, I can't seem to find the values for Y (forward and backward).

Yellow is the chunk info, red is the rest. That's how it turned out for me. Edit: Oh! I also found where the text is stored! It's stored in bmgres.arc in the res/msg folder and starts at 0x1A309. Huh. One odd thing I've found is that "This is but one of the legends of which the people speak" is sandwiched between Medli's text. Wonder why? No! No, wait! The full line says, "This is but one of the legends of which the people speak... Uh, were you listening to that? Oh, how embarrassing." Unused Medli line for when you through her into a wall the first time you're in Dragon Roost??? Hmph. Then again, looking at how chopped up the text is, I guess it could be randomly stuck in there. :/

Huh? The file, after I added everything (The PLYR chunk and the data related to it), the file for me was 0xBE long?

Another quick question: After I add the new PLYR data at where I'm placing it (starting at 0x9F, the end of room19's dzr file), do I need to fix anything again? Or was the fixing at the start of the process only necessary because we added data in the middle of the file? Edit: It worked! Wind Viewer recognizes the addition! I copied the data from the E3 outset file you provided in the program's folder, so it's not positioned correctly. Also, room19's dzr has an exit header. That exit? Yeah, the destination map is SirenB. What's in SirenB? The tower's boss room. I think this means that room19 was meant to be a room you'd visit after beating the boss.

Oh! I see! So, to add PLYR to the file, I need to add it to the list, give it its own pointers and fix the other pointers on the list? Hm. You would make the pointer for the PLYR in your description 0x000019AC because the new information relating to PLYR would start at that offset, right? And we're fixing the other chunks for the addition of the PLYR header and offset? Final question. 0x00000001 and 0x00001974. Is this where the game looks for the information relating to the chunk header? So it would look from 0x00000001 to 0x00001974? Or does the information start at 0x00001974? Oh! Oh, I get it now! Reading the OP again, I see it! The first offset is the number of things related to the chunk header, and the second is where the data for that header starts!

Ah... XDaniel? I regret this, but I'm not quite understanding what you're talking about with 'chunks.' I understand offsets, just not the rest.Would it be possible for you to give a bit more simplified explanation? Also, I'm going to try finding a .dzr to replace room19's original (think I'll replace it with room20's...) and see if that's what the problem is. If it is, it would be even more worth it to figure out the X/Y/Z positioning stuff. Then we could edit one of the .dzrs to have a PLYR that's positioned inside the model of the room. Edit: YEAH! I replaced the .dzr file, and the room loaded! But... Link fell to his death a second after it loaded, so I didn't see anything XD Oh well. It's still a plus!

I think I might've just found why Room19 in Siren doesn't load. It has no PLYR actor in its DZR! Is there any way to get one in there?