Jump to content

Useful hacks for mods (Debug ROM)


DeathBasket
 Share

Recommended Posts

Most people like to mod the MQ debug ROM so here's a few useful things you can do:

 

 

Make file 1 into a 'normal' file

1. go to B20434 in ROM and write 00000000 over the four bytes there.

2. go to BDF648 and change 15C0001B to 1000001B.

3. go to B20488 and write 10000002 (cutscene fix)

 

 

Disable noclip (when you press L+dpad-right)

go to C1EC04 and change 11E00080 to 10000080.

 

 

Disable map select

go to B96A00 and change the next 0x1C bytes to something. (I haven't been able to remove it without a crash but it can be replaced by the title screen or file select screen...)

go to B3D954 and write 10000009

 

Stops the overlay from ever being loaded. If you need it for any reason then don't use this and write some other code to get around it.

 

 

 

Disable debug camera

1. go to AD0AA0 and change 3B2E0001 to 00007021 (fixes controls).

2. go to AD0AEC and change 11200022 to 10000022.

 

 

Disable item debug (pressing L at start menu)

go to BEEC20 and change 24190001 to 24190000.

 

 

Fix the ending scene

go to B33FF8 and change 1521 to 1000.

 

I was told the ending scene is broken because MQ tries to load a video of the ending instead of the cutscenes themselves. Anybody know anything about this? It certainly tries to do something different for scene 0x5A cutscene 2 anyway.

 

 

 

If anyone has anything else or any improvements on what I've posted then please post them.

  • Like 3
Link to comment
Share on other sites

This is pretty cool, this kind of stuff will basically be put on after a mod is complete so it will seem as if you are playing a normal OoT ROM, correct?

 

That's the idea, but you could also use the leftover space from things that are no longer run to write your own code.

Link to comment
Share on other sites

  • 1 year later...

I have it linked in my tutorial thread, but on a side note due to DB and me trying to figure this out:

 

The new file starting offset is at 0xB1F774
24 0C XX XX
X= exit list number

To make the game start out in a cutscene from another part of the game, use the first exit number in the list (http://wiki.spinout182.com/w/Debug_ROM:_Exit_List).

For example, if you want the game to start out in Kakariko Village at the burning village cutscene, then set the offset to "24 0C 00 DB"

To make the cutscene play, you must go to the cutscene offset which is at 0xB20468 3408 FFFx
 
We can see in the debug rom that cutscene 0 is the burning village scene. So change the FFFx to FFF0. If you don't want to use a cutscene, then change it to 0000.

And there you go, the game starts you in the village as it's burning. And then you can edit cutscenes/text from there.

Video in action:

 

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

Well this might be old news, but Link's Primary Data for File 1 begins at 0xBA1740 in the Debug Rom.

 

For all other files it begins 0xBA1680, I believe.

 

11 Lines compose the basic data, from what I could tell, 

 

If a map hasn't been made of the contents of 0x15E660 (Link's Primary Data in RAM) I'll get to that soon enough and edit this post.

Link to comment
Share on other sites

Sorry for the wait, here's the 15E660 map to my knowledge...

 

15E660 - ??

15E664 - Age Byte

15E668 - ??

15E66C - Possibly area shading byte (as if caused by time of day?)

15E670 - ??

15E674 - ??

15E678 - ??

15E67C - ZELD

15E680 - AZ

15E684 - ??

15E688 - ??

15E68C - Current Max HP (Every heart is a value of 10)

15E690 - Current HP (two bytes) / Current MP (two bytes)

15E694 - Current Rupees (Two bytes)/Giant's Knife remaining strikes before breaking. (Two bytes)

15E698 - Timer of sorts (continually counts up) (two bytes)/Magic Flag (0100) (two bytes)

15E69C - First byte is Double Magic Flag (when combined with the Magic Flag) , last two are a check to see if the player has the Biggoron's Sword rather than the Giant's Knife (Flag 0100)

15E670 - 15E6C4 - ??

15E6C8 - Currently equipped Item on B and C-Button Items.

15E6CC - ??

15E6D0 - Currently Equipped Boots/Tunic/Shield/Sword in that order (two bytes, four half-bytes)a 

15E6D4 - Inventory - Deku Stick/Deku Nuts/Bombs/Arrows  (one byte)

15E6D8 - Fire Arrows/Din's Fire/Slingshot/Ocarina

15E6DC - Bombchu/(Hookshot/Longshot)/Ice Arrow/Farore's Wind

15E6E0 - Boomerang/Lens of Truth/Magical Beans/Megaton Hammer

15E6E4 - Light Arrow/Nayru's Love/Bottle1/Bottle2

15E6E8 - Bottle3/Bottle4/Adult Trade Item/Child Trade Item

15E6EC - Deku Stick Ammo/Deku Nut Ammo/Bomb Ammo/Arrow Ammo (one byte)

15E6F0 -  Placeholder Ammo Slot?/Placeholder Ammo Slot2?/Slingshot Ammo/Placeholder Ammo Slot3?

15E6F4 - Bombchu Ammo/Placeholder Ammo Slot4?/Placeholder Ammo Slot5?/Placeholder Ammo Slot6?

15E6F8 - Placeholder7?/Placeholder8?/Magic Beans/Placeholder10? (Now this is interesting! I had no idea that every item up until Megaton Hammer had a possible ammo slot? Now I wonder how difficult it would be to attach it to them properly...)

15E6FC - Current Equipment Inventory (Boots, Tunics, Shields, Swords, in that order, (2 bytes, 4 half-bytes)

15E700 - Current Secondary Equipment Inventory (Bomb Bags, Goron's Bracelet, etc) This section is a Mess, and I can barely make heads or tails of it.

15E704 - Current Quest Item collection (You may refer to the list in the Spoiler...)

 

 

Ignore the Rom Values, they're for something else and would be dangerous to change anyhow.ROM: 0xB9E2C0 - 00000001 Forest MedallionROM: 0xB9E2C4 - 00000002 Fire MedallionROM: 0xB9E2C8 - 00000004 Water MedallionROM: 0xB9E2CC - 00000008 Spirit MedallionROM: 0xB9E2D0 - 00000010 Shadow MedallionROM: 0xB9E2D4 - 00000020 Light MedallionROM: 0xB9E2D8 - 00000040 Minuet of ForestROM: 0xB9E2DC - 00000080 Bolero of FireROM: 0xB9E2E0 - 00000100 Serenade of WaterROM: 0xB9E2E4 - 00000200 Requiem of SpiritROM: 0xB9E2E8 - 00000400 Nocturne of ShadowROM: 0xB9E2EC - 00000800 Prelude of LightROM: 0xB9E2F0 - 00001000 Zelda's LullabyROM: 0xB9E2F4 - 00002000 Epona's SongROM: 0xB9E2F8 - 00004000 Saria's SongROM: 0xB9E2FC - 00008000 Sun's SongROM: 0xB9E300 - 00010000 Song of TimeROM: 0xB9E304 - 00020000 Song of StormsROM: 0xB9E308 - 00040000 Kokiri EmeraldROM: 0xB9E30C - 00080000 Goron RubyROM: 0xB9E310 - 00100000 Zora's SapphireROM: 0xB9E314 - 00200000 Stone of AgonyROM: 0xB9E318 - 00400000 Gerudo Membership CardROM: 0xB9E31C - 00800000 Skulltula Tokens (appearing on Subscreen)ROM: 0xB9E320 - 01000000 Nothing?ROM: 0xB9E324 - 02000000 Nothing?ROM: 0xB9E328 - 04000000 Nothing?ROM: 0xB9E32C - 08000000 Nothing?ROM: 0xB9E330 - 10000000 One Piece of HeartROM: 0xB9E334 - 20000000 Two Piece of HeartROM: 0xB9E338 - 40000000 Four Piece of Heart (Glitched)ROM: 0xB9E33C - 80000000 ??? Piece of Heart (Glitched)

 

 

I hope this will help some aspiring hackers and modders to better understand this area. Next time will be a post on another important RAM section at 15FA00. 

 

EDIT: Added Biggoron's Sword identifier.

 

EDIT: Added Double Magic Flag - 15E69C

Edited by Three_Pendants
  • Like 1
Link to comment
Share on other sites

http://wiki.spinout182.com/w/Ocarina_of_Time:_Save_Format

 

The first 0x10 bytes affect the entrance table lookup. 

 

15E660 is the base entrance index. 

15E668 is what I call the cutscene entrance offset, default is 0000. If set to FFF0-FFFF, it will play whatever cutscene is being pointed to by the cutscene pointer. If set to those values while the scene is loading, it will cause a cutscene defined by the 0x17 command to play.

15E66C is game world time.

 

Somewhere near 15E6C8 should be the child and adult buttons. Also, after 15E6C8 is C item slots, which determine item highlighting and what inventory slot should be written to when a bottle item's contents updates.

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 months later...

Someone asked if I could remove the Button Input Display at the bottom right the other day and decided to look into it now.

To disable it, change the value of the halfword located at RAM address 0x80211A42 to any value except 0x0000, the game compares this value to the R0 register to decide if it should branch past the button input display.

To disable it permanently change the branch instruction at RAM address 0x800C4790 or ROM address 0x00B3B930 to "BEQL R0, R0, 0x800C47AC" or 0x50000006 in hex.

I looked this up in just a minute or two, and I haven't properly tested other debug features and such after doing this, but I believe that it will only affect the button input display.

 

Figured that this may be useful for mods.

Edited by CloudMax
  • Like 2
Link to comment
Share on other sites

After 8015E660 are any "stored" value for the save file later. I mean, there's a high chance of flags for bosses being stored in there (and they surely are stored) and you can alter any value that can be saved if you look for a 3CXX8016 - 24XXE660 pattern (with possible fillers in-between) for any actor file, and search for a result.

 

Perhaps you can prevent the value from being stored by using Nemu to breakpoint the spot, and get Gohma's death sequence where the value would be stored, or prevent her from dying after you killed her (which is what I did, that way you can use her flag storage for something else if you want).

 

That is also the first step to making Gohma a regular enemy.

Link to comment
Share on other sites

After 8015E660 are any "stored" value for the save file later. I mean, there's a high chance of flags for bosses being stored in there (and they surely are stored) and you can alter any value that can be saved if you look for a 3CXX8016 - 24XXE660 pattern (with possible fillers in-between) for any actor file, and search for a result.

 

Perhaps you can prevent the value from being stored by using Nemu to breakpoint the spot, and get Gohma's death sequence where the value would be stored, or prevent her from dying after you killed her (which is what I did, that way you can use her flag storage for something else if you want).

 

That is also the first step to making Gohma a regular enemy.

This doesn't make much sense. Gohma is considered dead when the clear trigger for the boss room is set on. The devs wouldn't write directly to the specific scene save data (wherever the proper spot is within 15E660 - 15F9B0) because that would involve hardcoding every flag. Instead you have a spot that holds the switch, clear, chest flags for the current scene (well, for permanent flags at least). Whenever the scene changes the values stored here are copied into the save data of the scene being left, then the flags from the save data for the next scene are copied over here, meaning that any changes done directly to the save data will be lost when the scene changes, and that no actor will check this location directly since the flags stored there aren't being actively updated.

Link to comment
Share on other sites

I have no idea if this is already common knowledge, but I looked up where the debug feature for skipping cutscenes with start was located.

0x800652FC in RAM and 0x00ADC49C in ROM. There's a branch there which branches when the start button isn't pressed.

Simply change this branch command to "BEQL R0, R0, 0x80066F70" or 0x5000071C in hex and it will always branch, preventing you from skipping cutscenes with start.

This should help out for mods where skipping cutscenes will prevent players from progressing, or if you simply don't want people to skip the cutscenes.

You'll no longer have to help all the people asking why they spawn in spirit temple when they start playing. :)

 

I guess you could also write an ASM hack at the specificed location to only allow players to skip specific cutscenes and stuff like that. (or manually give the player the stuff they'd miss by skipping a cutscene)

  • Like 3
Link to comment
Share on other sites

I have no idea if this is already common knowledge, but I looked up where the debug feature for skipping cutscenes with start was located.

0x800652FC in RAM and 0x00ADC49C in ROM. There's a branch there which branches when the start button isn't pressed.

Simply change this branch command to "BEQL R0, R0, 0x80066F70" or 0x5000071C in hex and it will always branch, preventing you from skipping cutscenes with start.

This should help out for mods where skipping cutscenes will prevent players from progressing, or if you simply don't want people to skip the cutscenes.

You'll no longer have to help all the people asking why they spawn in spirit temple when they start playing. :)

 

I guess you could also write an ASM hack at the specificed location to only allow players to skip specific cutscenes and stuff like that. (or manually give the player the stuff they'd miss by skipping a cutscene)

Very well done! :D Only lacking how remove the Cutscene Control with D-Pads Keys and the Controller 1 will be normal like OoT 1.0.

Link to comment
Share on other sites

Pro tip: Just mod V1.0  :D

I totally would, if it wasn't for the fact that everyone except you mods on the debug rom. <.<'

I myself initially modded 1.0, but switched to debug because that's the version my editor is going to support, and it would be dumb for me to have the editor for 1 version, and the rest for another.

I do not really see the point in using the debug rom, but I'm inexperienced in a lot of things, so there's probably some specific reasons I'm not aware about?

The only reason I can think of would be printing text on the screen, which I believe only has been achieved in the debug rom because the stack pointer hasn't been figured out or something like that. (this may not be the case anymore, I'm not sure)

But I've yet to see a mod that actually prints text on screen anyway, so yeah, that's not a valid reason either.

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

Double-posting.. but some people has been asking for this earlier.

This will make it so that you can't regain control during cutscenes by pressing D-Pad Right.

 

Change ROM address 0xADF480 from 0x55200004 (BNEL T1, R0, 0x800682F4) to 0x50000004 (BEQL R0, R0, 0x800682F4)

Rather than only branching when d-pad right isn't pressed, it always branch. This is located at 0x800682E0 in RAM.

 

It shouldn't be necessary to disable the commands to reset the cutscenes since those only work after regaining control as far as I'm aware.

  • Like 1
Link to comment
Share on other sites

This doesn't make much sense. Gohma is considered dead when the clear trigger for the boss room is set on. The devs wouldn't write directly to the specific scene save data (wherever the proper spot is within 15E660 - 15F9B0) because that would involve hardcoding every flag. Instead you have a spot that holds the switch, clear, chest flags for the current scene (well, for permanent flags at least). Whenever the scene changes the values stored here are copied into the save data of the scene being left, then the flags from the save data for the next scene are copied over here, meaning that any changes done directly to the save data will be lost when the scene changes, and that no actor will check this location directly since the flags stored there aren't being actively updated.

Don't see how that doesn't make sense, because the save data is massive, and one byte could store multiple flags if it's bitwise. If you look further down, the save data is more massive than you think..

 

Bosses have their own flags, and yes it's hardcoded in a relative sense.

 

The bosses check the save data. Seriously, you're not making any sense, I wasn't referring to scene data, I was referring to boss flags. You can't battle a boss if you actor hack them to a map if you defeated them in the dungeon, because the bosses check that flag. I was saying to REMOVE the flag check to force Ghoma to be an enemy without her dying and spawning a warp portal every time you see her.

 

 

EDIT:

------

http://wiki.spinout182.com/w/Save_Format

 

"The structure for the scene related save data. Located at offset 0xD4 into the save file. Each record is 0x24 bytes long. There are believed to be 110 records, one for each scene."

 

In any rate, flags are read through the save data, and bosses don't work once they're killed in a dungeon even if you hack them outside of the map.

Link to comment
Share on other sites

I noticed that this isn't here:

 

Subscreen delay fix:

0x00B36483: 0xF0 -> 0x00

 

Subscreen delay fix, with working Item Debug:

0x00B3647B: 0x40 -> 0x00

0x00B36483: 0xF0 -> 0xCA

 

Actually the pause menu delay doesn't exist at all on a console and pausing on the debug version is much faster than other versions. Emulators are pretty bad at handling the pausing in both OoT and MM. What does this code actually do?

Link to comment
Share on other sites

Actually the pause menu delay doesn't exist at all on a console and pausing on the debug version is much faster than other versions. Emulators are pretty bad at handling the pausing in both OoT and MM. What does this code actually do?

Seems to remove the blur effects... works fine on console, but doesn't look like it's safe:

20140210_185138_zps37a16753.jpg

Link to comment
Share on other sites

I think Air figured out her mistake, but I will address the points she brought up anyway for others reading:

 

Don't see how that doesn't make sense, because the save data is massive, and one byte could store multiple flags if it's bitwise. If you look further down, the save data is more massive than you think.

It's not. While saves are 1450h bytes long, the checksum is located at offset 1350h, which should mean that the only data saved is stored between offsets 0000 and 1350 since that data is verified by the checksum. 15E660 + 1350h = 15F9B0 so the range I posted isn't wrong.

 

Bosses have their own flags, and yes it's hardcoded in a relative sense.

 

The bosses check the save data. Seriously, you're not making any sense, I wasn't referring to scene data, I was referring to boss flags. You can't battle a boss if you actor hack them to a map if you defeated them in the dungeon, because the bosses check that flag. I was saying to REMOVE the flag check to force Ghoma to be an enemy without her dying and spawning a warp portal every time you see her.

 

In any rate, flags are read through the save data, and bosses don't work once they're killed in a dungeon even if you hack them outside of the map.

When you defeat a boss, you set a clear flag which is part of the scene save data. There is no separate flag set for determining if a boss has been defeated. Furthermore, bosses like Gohma do not check the save data, but rather the "local" set of scene flags (located near 1CA1D8 in V1.0, so somewhere similar in the Debug Rom.

 

It works like this:

- Actors interface with the "current" scene flags. Allows for actors to be re-used in different scenes/scenes can be re-ordered.

- Current scene flags are copied into a specific spot in the save data based on the current scene number.

- Copying into the save data occurs either when saving or scene reloading are triggered

- Since the current scene flags aren't copied over every game tick, the perm scene flags located in the save data aren't always up to date.

Link to comment
Share on other sites

Actually the pause menu delay doesn't exist at all on a console and pausing on the debug version is much faster than other versions. Emulators are pretty bad at handling the pausing in both OoT and MM. What does this code actually do?

When you enter in the Pause Menu, this load something like a Black Screen for the Inventory Debug:

Note: This happen the same thing on the Bootup of the ROM, and is for this reason why you can't see the N64 Logo when you load the ROM.

 

 

snap0065.jpg

 

 

 

So, if you remove this, the Pause Menu will load more faster, but the Inventory Debug will not work and you will get this:

Note: Obviously, you have the Inventory Debug disabled in your released mod... :P

 

 

 

snap0066.jpg

 

 

 

So, to make the Inventory Debug functional again (Just in case), you can try the other method and you will get this:

 

 

 

snap0067.jpg

 

 

 

Btw, if you are using a emulator & Jabo D3D, you need put the Direct3D Clear Mode: Always, and the glitched textures will be fixed.

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.