43512 Posted July 15, 2014 Share Posted July 15, 2014 Nice one. Did you find that code by yourself or were you using spinout's hack as a reference? Thank you! By myself. I was originally going to take a look at spinout's, but once I found one of the offsets referencing the scene table in RAM, I surmised it'd be easy to come up with the rest. I was wrong, but, since I enjoy ROM hacking like this and figuring things out on my own, I went ahead and completed it without investigating spinout's work. Link to comment Share on other sites More sharing options...
Airikita Posted July 16, 2014 Share Posted July 16, 2014 Good job at finding it, saves people time to dig for it themselves. I archived this immediately. Link to comment Share on other sites More sharing options...
43512 Posted July 16, 2014 Share Posted July 16, 2014 Good job at finding it, saves people time to dig for it themselves. I archived this immediately. Thank you! I understand that the scene/entrance cap could become a serious limitation for someone trying to make a large-scale mod, especially due to how unobvious it is to resolve -- this solution, at the very least, isn't intuitive at all -- and how you need to be knowledgeable about assembly and such to fix it. Using spinout's ztables hack is one solution, but I wanted to determine exactly what you'd need to do to overcome it, both out of my own curiosity and out of a desire to produce sufficiently detailed documentation that someone could design a program to automate the process. Thus, I derived a solution and kept track of every last modification I had to do. I hope it'll prove useful. Link to comment Share on other sites More sharing options...
Jason777 Posted July 16, 2014 Share Posted July 16, 2014 Something that people should be aware of when following your tutorial is signedness in assembly. Thankfully, when setting that scene/entrance table offsets, you used ORI for the lower 16 bits which interprets the value given as unsigned. However, the ADDIU to set the lengths of the scene/entrance table, if given values after 0x7FFF, will be a negative number and result in FFFF being placed in the upper 16 bits of the register. Perhaps an ORI should be used in place of the ADDIU. Nonetheless, great job! EDIT: Not that anyone would use that many scenes... just food for thought, I guess. 1 Link to comment Share on other sites More sharing options...
Airikita Posted July 16, 2014 Share Posted July 16, 2014 I agree with the ORI method, although it depends on if you want to go up to 8000 or higher, lol. Link to comment Share on other sites More sharing options...
43512 Posted July 17, 2014 Share Posted July 17, 2014 Something that people should be aware of when following your tutorial is signedness in assembly. Thankfully, when setting that scene/entrance table offsets, you used ORI for the lower 16 bits which interprets the value given as unsigned. However, the ADDIU to set the lengths of the scene/entrance table, if given values after 0x7FFF, will be a negative number and result in FFFF being placed in the upper 16 bits of the register. Perhaps an ORI should be used in place of the ADDIU. Nonetheless, great job! I agree with the ORI method, although it depends on if you want to go up to 8000 or higher, lol. Ah, good point. I made a point of using ORIs as much as I could, so I'm not really sure how those ended up as ADDIUs; perhaps I should've examined my code a little more thoroughly when I wasn't drowsy. =P I'll edit the tutorial to use ORI instructions for the lengths instead, although I can't imagine having so many areas and starting positions in a mod that someone would need to expand the scene or entrance tables to above 0x7FFF in length. Come to think of it, would you even have enough space in ROM to store enough scenes to fill all of those entries with valid data? Link to comment Share on other sites More sharing options...
Airikita Posted July 17, 2014 Share Posted July 17, 2014 Ah, good point. I made a point of using ORIs as much as I could, so I'm not really sure how those ended up as ADDIUs; perhaps I should've examined my code a little more thoroughly when I wasn't drowsy. =P I'll edit the tutorial to use ORI instructions for the lengths instead, although I can't imagine having so many areas and starting positions in a mod that someone would need to expand the scene or entrance tables to above 0x7FFF in length. Come to think of it, would you even have enough space in ROM to store enough scenes to fill all of those entries with valid data? Eh, not really... there's no where near enough scenes to worry about, however you don't want to even get to FFFF because then you have entrances, which can be much more than scenes. But you know, ORI to be better safe than sorry if someone dreams up a mod with lots and lots of scenes. Idk why though... ================================ ISG Fix: ---------- 0xC1A524 & 0xC147B4 -> A2000843 (fix ISG) [for text with NPC or Signs and picking up bombs/cuccos/etc...] Link to comment Share on other sites More sharing options...
â–²ChriisTiianâ–² Posted July 18, 2014 Share Posted July 18, 2014 ISG Fix: ---------- 0xC1A524 & 0xC147B4 -> A2000843 (fix ISG) [for text with NPC or Signs and picking up bombs/cuccos/etc...] n1 Link to comment Share on other sites More sharing options...
mzxrules Posted July 18, 2014 Share Posted July 18, 2014 The entrance index is a signed value so addressing past 7FFF might not be possible without further modifications. Also, there are a handful of values at the 7FFF end used for resetting the game/exits that change their destination based on the entrance used. Edit: I just remembered why I thought the scene index was a single byte: A single byte is used to store the scene number in the entrance table, so again the limit there is 256 Link to comment Share on other sites More sharing options...
Airikita Posted July 18, 2014 Share Posted July 18, 2014 Prevent Swordless Epona glitch: ----------------------------------------- 0xAFA364 & 0xAFA3B4 -> 00000000 (Swordless Epona Glitch fix) (Equips the Deku Stick when dismounting however) 0xAFA384 -> 00000000 00000000 00000000 00000000 (full swordless Epona glitch fix) Link to comment Share on other sites More sharing options...
â–²ChriisTiianâ–² Posted July 19, 2014 Share Posted July 19, 2014 Prevent Swordless Epona glitch: ----------------------------------------- 0xAFA364 & 0xAFA3B4 -> 00000000 (Swordless Epona Glitch fix) (Equips the Deku Stick when dismounting however) 0xAFA384 -> 00000000 00000000 00000000 00000000 (full swordless Epona glitch fix) n1!, lacking the Super-Slides fix and most of glitchs will be fixed. Link to comment Share on other sites More sharing options...
mzxrules Posted July 20, 2014 Share Posted July 20, 2014 Good luck fixing this glitch: Link to comment Share on other sites More sharing options...
Airikita Posted July 20, 2014 Share Posted July 20, 2014 Good luck fixing this glitch: It is fixed in ZEY, I nulled out the equipped item when the equip item value is inactive. Quick Draw is fixed. However it is not a simple write-over the current code when fixing. You can, however, fix it at 803D4084 (Link's code) by checking if the byte relative to Link's instance at 0x0154 is 00, and set the byte at 0x0152 of Link's instance to FF if so. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ======================================================================================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Faster loading time: -------------------- Prevent AB being written to RAM/Memory: --------------------------------------- 800FDE40 -> change to 00000000 800FDEF4 -> change to 00000000 80057C8C -> change to 00000000 Faster inventory pause: ----------------------- 800C268C -> change to 00000000 -OR- 800C37F4 -> change to 00000000 More RAM space for loaded objects [More space for scenes/maps]: --------------------------------------------------------------- 80097DFC|80097E1C|80097E44|80097E6C|80097E70 -> change to 3C110020 (or higher if need be) *this is to allow more space for certain bigger files, such as Link's file, but maybe others as well 1 Link to comment Share on other sites More sharing options...
â–²ChriisTiianâ–² Posted July 30, 2014 Share Posted July 30, 2014 Faster inventory pause: ----------------------- 800C268C change to 00000000 -OR- 800C37F4 change to 00000000 Use this, remove the pause menu delay, fixes crashes, etc..0x00B36B6B: 02 -> 03 Link to comment Share on other sites More sharing options...
Airikita Posted July 31, 2014 Share Posted July 31, 2014 Use this, remove the pause menu delay, fixes crashes, etc.. 0x00B36B6B: 02 -> 03 I have, but the result is a messy blur. If you look at my previous post in here, I posted a screenshot of the console. Well, moving on, I have found out how to expand memory for scenes from a mishap: -------------------------------------------------------------------------------- More RAM space for loaded objects [More space for scenes/maps]: --------------------------------------------------------------- 80097DFC|80097E1C|80097E44|80097E6C|80097E70 -> change to 3C110020 (or higher if need be) Turns out this is the function that will allow more space in maps, but keep in mind the GDLT is currently still limited, but I am working on that currently. It is possible to remove the function that mirrors the GDLT, and double the capacity for the video memory, but that will have to be tested. 2 Link to comment Share on other sites More sharing options...
Recommended Posts