mzxrules

the gi_object/scene title card block is not part of Link's instance, though one is spawned per instance of Link. There's a separate memory block allocated for it. Also, the block size is 0x3010 in the Debug Rom.

The rice video plugin dumps textures, but doesn't seem to dump them in their raw form. Cloudmax's Texture Explorer lets you document where textures are within an n64 rom, and has a pretty well filled out profile for Ocarina of Time (Debug). It also has the ability to search for textures, but this is slow as hell. I think someone might have also ripped all of OoT's textures before, but don't know.

Did you actually modify Link to load more space for GI models (and if so, what line of code for documentation purposes?), or are you just letting the system overwrite unicat

how big is the file size for the gi model? If I remember my GIM glitch testing I think the limit without expanding is 0x2020

So I was poking through different variables within the Global_Context on NTSC 1.0 when I noticed that a section that manages controller input was reacting whenever I "plugged in" a controller into the 3rd slot, but not slots 2 or 4. So I booted up Nemu to see what (if anything) was reading input from controller 3. It turns out that ovl_En_Mag (Actor 0171) contains code that checks for a sequence of button presses that when pressed completely wipes out all save data. This code is useful for clearing out corrupt save data that would otherwise be impossible to delete without opening up the cartridge. I call it "Resetti no Forgetti" To activate the code, press D-Up, D-Down, D-Left, D-Right, Start, B, C-Down, L, C-Right, C-Left, A, C-Up, R, Z in sequence on controller 3. After each correct input you have 16 frames to press the next input in the sequence, or else the code will not work.

I prefer the boomerang primarily for it's homing capabilities, but also because using magic arrows like that affects visibility considerably.

I don't know enough to help, however I can say that some of these oddities are very similar to that of a recent series glitch we discovered called GIM and GIMME

almost all of that (in the screenshot) is on oot.cloudmodding.com, some of it I've improved. I'm pretty confident that my actor documentation (if you mean spawns) is better than anything anyone else has

can someone test this on a clean rom?

just send me your rom

I haven't looked into MM much so I don't know how to properly unpack these files/give them their own mapped rom space (if that's even possible). Also, when specifying an address range, we typically write the end address as being one more than the last byte within the range (non-inclusive). This allows you to easily compute the size of the range of values.

open the rom in a hex editor. Search for the string "Yaz0" no quotes. If you can find that string, then there are still files left that are compressed.

I haven't tested all of the Z-Rotation parameters of type 3 yet so at the very least there's more to be found. If type 3 has no walk into, you could still just use type 2 to achieve the same effect (not sure if it works if no item is set, but you can just as well give a rupee). I think you're confused by my notation. & xxxx is meant to be interpreted as a mask that captures what bits make up a variable that has a non-standard bit length. I created it because when I first started working with the existing actor variable documentation, the notation used made it hard to see the underlying values that the developers were setting. I've gotten some flack for it not being the most readable form, but I like it because it's super concise since shift operations are implied. Basically a mask of & F800 means that the value captured is the leftmost 5 bits, and has a range of 0-1F. You can easily see this if you plug it into something like Window's calc when you set it into programmer mode: F 8 0 0 1111 1000 0000 0000 The 1s show what bits to capture, while the number of 0s to the right of the rightmost 1 adds up to the number of shifts to perform to read/insert the value (11 in this case). So & 003F isn't meant to be a boolean state, but rather the standard range for switch flags (0-3F). Also, every modder should totally be using this page: http://wiki.cloudmodding.com/oot/Actor_List_(Variables)

bleh ovl_En_Wonder_Item is completely invisible, and has no object dependencies (unless you're using type 8 since it spawns a hylian soldier to bomb you). In addition to that, wonder item sets a switch flag rather than a collectible items flag, even though it drops items. If you're not familiar with either, basically there's a set of flags per area that every actor has access to that actors can read or write to in order to preserve their state or interact with one another. Switch Flags and Collectible Flags are two different subsets of these flags, where switch flags are used for nearly everything, while collectible flags are used for just item drops. Since wonder item is invisible, can be used anywhere, and sets a switch flag when triggered, there are probably a lot of creative things you can do with this actor with making puzzles. In Master Quest, Nintendo used them for cow switches by placing a cow down somewhere, then putting a few wonder items around it to give the appearance that shooting the cow triggers the switch on event.

Today I solved much of the mystery of ovl_En_Wonder_Item, actor 0112. It is truly a wonder item, and quite possibly the most versatile puzzle element that nobody has fully understood... Actor 112 & F800 = Type - 02 = Invisible, free collectible - 03 = Invisible Collision Box, drops collectible (see Z rotation) - 08 = Bomb window? & 07C0 = Items Table located at DE970C NTSC 1.0 - 00 = 0C - 01 = 06 - 02 = 0E - 03 = 0F - 04 = 03 - 05 = 08 - 06 = 09 - 07 = 0A - 08 = Green Rupee - 09 = Blue Rupee - 0A = Red Rupee - 0B = 12 - 1F = No item? & 003F = Switch Flag Z Rotation - Additional parameter //When type = 2 this is the number of collectibles spawned //When type = 3 this sets the type of interaction that triggers the drop // 00 = Drop on Sword Swing hit // 01 = ? // 04 = Drop on Slingshot Seed/Arrow hit // 06 = ? As you can see, the lesser known functionality to this actor is that it provides it's own collision, sets a switch flag, an can be triggered through a variety of different methods, meaning you can now create more weird "cow" switches

lame. I liked the old pic. made it look like the stalfos was wearing a cape

So you need the right scene number and 1/2 object files loaded that aren't the standard 2 or 3 object, or is 2 or 3 required as well? Or maybe scene number isn't a factor? Also, found the documentation for the doors. Should add extra info on how certain door variations don't exist for all models. http://oot.cloudmodding.com/wiki/Tutorial:Modification_and_Addition_of_Switches#Alternate_Door_Skins

Figured out what the 05 and 06 cutscene commands do. They position the camera relative to Link, and are affected by Link's Y Rotation. Been investigating/documenting actor 008C (ovl_Demo_Kankyo) recently. When it's variable is set to 000D, it becomes the door of time and spawns actor 0070, which is the door's collision model. I located/documented the starting offsets for all the warp song cutscenes within it. This is how I figured out the purpose of the 05/06 cutscene commands Glitterberri mentioned that the actor lists a dependency of object 00B6 (object_gi_melody), a.k.a the Get Item Music Note. Based on this, it appears that the actor should spawn a music note when it's variable is set between 0008 and 000C, but nothing is displayed and I don't have the tools to trace through the draw routine. Added some documentation on actor 0015 (En_Item00). Not sure if the random drop table is part of that actor, but it fits thematically so I put it in.

The aiming when jumping off Epona looks really rough. Also I've noticed that Epona "slides" when running into a surface she can't traverse (it's very noticeable at 3:08 in the video). Hopefully these will be fixed

The code for the debug rom lands in the same space. Leaving the code on will definitely still cause errors, just different ones than the 1.0 since the file sizes and instance sizes are all different.

I would need to know the code used.

I'd like to question some of that... particularly all of it since it came up in the irc today. As it was explained to me, to trigger the oddities with the DD shown above, you would need to go to the file select, select the first file, activate this code... 811E4EC0 0022 ...then play through different parts of the game. I have no problem achieving a lot of the same results you do with it activated when I've had it active in the market, Ganon's Castle, and I stopped bothering to check things. The problem is the code itself, and the assumption that the code is proof of dummied out dd features within the game. When the main game is running, 1E4EC0 falls within a space I call "Actor Space". It's a block of ram allocated to actor files and instances. The starting address is always the same, beginning at 1DAA00 with a doubly-linked list node that points to the Link instance (at 1DAA30) and ends a little before where the room file is located (typically around the 20-28xxxx range). This means that the code is modifying "random" actors. The more amusing part is the second value in the code. Because the code above ends with a 0, if it ends up modifying a mips instruction within an actor file, it will change it to (and I hope this is right because I didn't bother to look it up myself)... sll $0, $v0, xxxx ...which is essentially a nop since the zero register can't be modified. This is what happens in the Back Alley and the Market plaza, since it happens to overwrite the overlay file for actor 016E: ovl_En_Hy, Market NPCs (just in different places due a different number of door instances existing).

If they're adding fishing... where will it take place?

Ok, was just wondering if you knew anything extra. What I've observed is that rotation is stored as a byte rather than a short in MM, such that one unit = 2 degrees of rotation. Pretty sure that the rx, ry, rz variables are at least stored at the same offset into the data though.

What's incorrect is how that information is documented in StageDescriptions.xml. By numbering things in order of existence, the documentation will break if the player adds (for example) a night scene setup to Link's House without the location of the other scene setups changing.