Airikita

I agree with the ORI method, although it depends on if you want to go up to 8000 or higher, lol.

Good job at finding it, saves people time to dig for it themselves. I archived this immediately.

Really cool concepts, I love how you incorporated different themes, and none are out of place since Mario games generally switch between themes and worlds. The Actraiser set gets me, as I loved Actraiser so much! The 2nd one was so gorgeous, and it's sad it's such an obscure game. My SNES died, and I gave it up. Hopefully someone is enjoying it as much as I did.

Yeah it is a bit odd, huh? It's not like it's creating the position factor before the texture. But perhaps the texture has to be created before positioning it.

Hello, and welcome! I hope you enjoy your stay, and don't be afraid to ask questions~ <( ( ^ w ^ ) )>

I think it falls back to the values scenes use in the list of scenes, such as how Kokiri Forest has this entry: 0288D000 0289E240 01A4D000 01A4F880 0004 0000 Then where 0004 is, that would indicate the type of animation to that map, and then whichever display list contains DE000000 08000000 or DE000000 09000000 would animate the water for that value, since that is what the scene would imply.

Sadly it won't fit the theme of the mod, and I have plans for this type of hookshot. Chain Chomp won't fit the mechanics I've uncovered. Especially when the design will fit the area it will be in:

Well yes, because the actor does affect its inline model, but when it's an external zobj like the Like-Like, I can't be sure on that, but it's possible.

Well, it works to some actors to some degree, as it is within object_rr as well. But, it could be akin to having to have a proper rendering function, such as it is with rendering matrices in some actors while others do not have the same rendering.

Water display list: From testing, removing DE000000 08000000 stops the waterfall from animating and DE000000 09000000 is what controls the pond water texture animation. These appear to be generic texture transitions, as these can be found in actor models as well (possibly Like-Likes would have this).

Currently designing a new hookshot: It will have special properties, and don't mind the extra hands for now, they're just placeholders until I move the chain and hook and pointer. I'm going through some textures to see which will fit best... It should look better with the hook.

I can see there has still been some confusions as to Epona's size in ZEY compared to MM, so here's a pic to clear any confusions up: The size was fixed earlier, and Epona is not imported from MM, she is the Young Epona that already exists in OoT resized. I figured I'd do this pic to be sure there wasn't any confusions as it seems my Young Epona mod has some optical illusions in the screenshots. On another note, I was going to work on the hookshot for Young Link, and then a glitch in Epona came up (which I thought I had fixed -.- I blame Nintendo for borking the camera code). She has also been modified to clear wider gaps:

Sorry, but that was not my intention. I have seen Nemu handle high-poly however, just not on console of course. For something like importing Twilight Princess maps and models into OoT, that was the idea of the RAM extension. Also, perhaps even OoT3D stuff can be ported to the ROM for some fun. I can also mean a special challenge in ZEY that won't be available for hardware compatibility since the console can't handle large amounts of spawns. So it might be possible to add more enemies to some areas for a harder mode, but that mode won't be available for console as mentioned. The RCP can only handle a set amount of polys (but, of course, I'm looking at a certain spot where graphics are allocated where it might be possible to move... but then it's a matter of the RCP).

I agree, however it's an idea for high-res modding. Tbh, some emulators can't handle high poly, nor the memory mapping can conflict. It is a possibility to allow mobs of enemies, but I'd have to test that. I think the hardware would crap out, and there isn't a great need for it. However, a 16Mb expansion would be a good call considering that modding a memory pack could be possible. It's just an option, but for now this hack makes boot time a bit quicker. The option of changing the RAM size is up to the modder. On hardware there is a slight noticeable difference in start-up time. Also, to say emulator hacks are not impressive is misled. I'd hate to bring up old bones, but the URA Project would have benefited from this.

They look pretty, I love the second one!

Epona now only free-jumps with the support of the Bow (otherwise she will only jump fences).

Yes, and looking at the model I exported, clamp is checked off for UV mapping (using MilkShape's Texture Coordinate Editor, I can see it's checked). Perhaps it is the converter? I also noticed sphere mapping doesn't apply either (for the metal/shine effect).

Sadly it isn't so: http://img.photobucket.com/albums/v299/airikita/wingtexturepart_zps3c9a5033.png I used a full wing from Google, and sectioned it off into 4 pieces. It also looks like an edge is still present when the conversion happens. It looks alright for the most part: Just those lines do give the effect away. Also, on a side note, the bow will use hearts for ammo to match the theme of the bow: I can also change how much health it removes.

UPDATE: Link has a new bow: I'd like to remove the black pixelated lines, but I can't seem to remove them, even when I rescale the UV mapping. Aside from that, it's a keeper~ There are other things I have implemented, such as new magic arrows: The arrows are fully functional, and useable. The beta arrows do exist, and so do the magic arrow colors it seems. Though it's not apparent since the colors are ordered for the fire, ice, and light arrows, but the colors are a few spots after the first 3 colors, by a few bytes.

JAL 80094F40 [0C0253D0] -> Deals with texture animations (water also) This deals with the F2 command in the F3DEX2 display list applied to RAM: 0xF2 G_SETTILESIZE Sets the texture coordinates and size It calculates the value applied to A2 to "slide" or "move" the rendering of the texture on the current display list loaded to RAM, referenced via a DE000000 80?????? command. --------------------------------------------------------------- More for RAM expansion: -------------------------------- 0xAAA240 -> change to 10000003 to always destroy enemies, despite RAM limitations (this allows overflow, so there is a cost) * This goes with the RAM expansion, yet be aware of limitations. Stalchildren can still be glitch-abused in Hyrule Field with Epona and spamming items, spin attacks, and song effects while destroying multiple Stalchildren. Eventually they "glitch out" by not allowing their models to be destroyed, so this fixes the problem and allows Stalchildren to be removed to free up space. -------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- Faster boot loading (for RAM) and Extended RAM: ----------------------------------------------------------------------------------------------- [ROM] 0x5DF8 -> 3C010080 AFA10008 00000000 This can also extend RAM even more than imaginable! 3C010080 is 8Mb, just change it according to how much RAM you want to use. You can use up to 90Mb for Emulators (this can bring us high-poly models if need be), but the Memory limit (in theory) for hardware goes up to 55Mb (03F00000) This works on hardware without any errors for booting, this does read from A0400000 and up this function, so I'm not sure what exactly is there... however it appears irrelevant as it's a boot-only function that loops for no particular reason. It also generates a Debug text which reads "RAM 8M mode (N64DD". On par with an earlier post of mine for Expansion RAM hack: https://www.the-gcn.com/topic/565-useful-hacks-for-mods-debug-rom/page-2?do=findComment&comment=45936 The changes can be made to push Link's file further down the RAM where you extended it to allow more space for graphics and actors. This also includes maps, and pretty much anything.

I'm sorry, but these additions are for ZEY, I'm not distributing stuff I make for my mod. I do release information that people can use, and I have mentioned where to find rupee information. Young Epona was something special, because of how that is such a big step, but a lot of the stuff I do here is not for release until ZEY is completed. Even then, ZEY modifications are for itself, but if someone wants to use my mod to make their own, well it is no longer their work.

Hey guys, this is for HUD items and value displays in particular: ------------------------------------------------------------------------------- 80089D54 -> displays counters for various items in c-buttons BF9330 - BF9330 [ROM] -> determines what item value is displayed in the Item Select menu/screen of the pause menu -> Change to FF to hide value display, or change to item # to display the value for an item of that number in that slot in the Item Select screen

Yeah, when I tested it switching the actors from Ruto's cutscene, the Sapphire did get swallowed: https://www.youtube.com/watch?v=n7svK74HdIE

Actually... maybe if the fish disappears when swallowed, then because it's a null, the cutscene thinks Link belongs there because the placeholder would be 0000 without the fish. Perhaps it's how the cutscene "loads" the references when it starts. It's different than having actors loaded in the map which are preset in the map data, where this must be loading the references to each actor present somewhere, and the default could very well be 0000 (Link).

I just said he doesn't.