SunGodPortal's Burning Questions

Does anyone know which byte controls what song gets played when falling into or through room 16? Is that info stored in the room header and if so, could any room be set to play any song if fixed by editing this data via hex (since HM does not seem to do this)?

PS: I tried changing the song attached to the room's entrance (36) but I'm guessing that only applies in this case if entering the room traditionally. Changing the song attached to the entrance in this case does not appear to make any difference.

EDIT: I've skimmed through the vital dungeon hex data doc, so I'm guessing there isn't a place for the music to change via header info. Also, the way that the "dungeon properties" is set up in HM (I'm guessing "boss room" is largely so that it will know when to change the music) also suggests that this data is not a part of the room header. It would be cool if there was a solution similar to the one that fixed the holes in BCvsG, where I could simply expand and edit a list via hex.

SunGodPortal wrote:Does anyone know which byte controls what song gets played when falling into or through room 16? Is that info stored in the room header and if so, could any room be set to play any song if fixed by editing this data via hex (since HM does not seem to do this)?

PS: I tried changing the song attached to the room's entrance (36) but I'm guessing that only applies in this case if entering the room traditionally. Changing the song attached to the entrance in this case does not appear to make any difference.

EDIT: I've skimmed through the vital dungeon hex data doc, so I'm guessing there isn't a place for the music to change via header info. Also, the way that the "dungeon properties" is set up in HM (I'm guessing "boss room" is largely so that it will know when to change the music) also suggests that this data is not a part of the room header. It would be cool if there was a solution similar to the one that fixed the holes in BCvsG, where I could simply expand and edit a list via hex.

Yes, this is the boss theme, but note - there is no way to edit this with HM. This is ASM based, since normally the music of the entire dungeon gets "scrolled" through the entire dungeon - here it changes (since the Ganon music is slightly different).

The ASM altogether:
-fall into Ganon pit= play boss music variation1
-end of Ganon's monologue (start of the fight)= play boss music variation2
-fall down to room 16= play boss music variation3 (the same music if you would enter this cave normally throught the entrance)
This can not be edited with HM and this info on how to edit the above is not in any of the documents (you are basically trying to achieve something new/undocumented).

This can not be edited with HM and this info on how to edit the above is not in any of the documents (you are basically trying to achieve something new/undocumented).

I'll keep the concept I had in mind (because it would be good for atmoshere), but I guess I won't need it for now.

The dungeon I was building that had the player dropping through this area has just turned upside down (going up then down, instead of falling down then climbing up) because that direction works better with the concepts I have in mind (based on the Ice Dungeon).

Overworld areas always blank-out

Remember how when you enter/exit Area 00 or 40 you'll get a "blank out" before going into the next screen? This actually does good when going say, from a brown grass area to a green grass area, or go from a non-raining bg to a raining bg (the swamp in dark world is a good example, if you have joined that screen with the other screens and don't feel like getting rid of the raining overlay.) Well here's how to make it always blank-out.

02AAE3EA
02AAE4EA

Enter these 2 codes, or if you want them permanently, just hack these codes into your rom.

rom with header offset: 12CE3 and 12CE4 - change to EA

Would this sort of transition allow for non-compatible GFX sets to be used in connecting overworld areas without graphical glitches when walking from one to another?

SunGodPortal wrote:

Overworld areas always blank-out

Remember how when you enter/exit Area 00 or 40 you'll get a "blank out" before going into the next screen? This actually does good when going say, from a brown grass area to a green grass area, or go from a non-raining bg to a raining bg (the swamp in dark world is a good example, if you have joined that screen with the other screens and don't feel like getting rid of the raining overlay.) Well here's how to make it always blank-out.

02AAE3EA
02AAE4EA

Enter these 2 codes, or if you want them permanently, just hack these codes into your rom.

rom with header offset: 12CE3 and 12CE4 - change to EA

Would this sort of transition allow for non-compatible GFX sets to be used in connecting overworld areas without graphical glitches when walking from one to another?

Yes. In fact this is the only way for you to add any gfx anywhere without testing transitions. The transit visible area must otherwise contain compatible gfx or neutral gfx (like tree, which is used everywhere). You can even add overlays, like fog and rain and the transition will be ok. The downside of this is that if having small areas the game will be constantly blanking out.

If you are ok with blankout at every transit, than implementing this is definitely a smart choice, since you don't have to worry about how to place gfx sets. It will even reset the palettes, so you also don't have to worry about sprites and their pals.

(for instance see how in the Alttp the small armos statues outside are "trapped" into that eastern area, so they can never reach the transit to green area with soldiers, due to conflicting sprite gfx and sprite pal - and the area with new bird statue gfx is also moved away from the transit).

By the way, Super Metroid had the same gfx problem, so as you might know all transits in SM are "blanked out" only the neutral gfx (door) is preserved in SM at transit.

Awesome.

The downside of this is that if having small areas the game will be constantly blanking out.

Shouldn't be too big of a deal. Each area will be packed with stuff because of the urban theme so it shouldn't get too annoying if the player doesn't have to wander all over the place. I'd like to also make more use of connection tunnels and whirlpools.

Note: I discovered that the addresses above as well as many others in that section of the compendium were for a headered ROM despite saying "All hex offsets are for a NON-headered rom!". LOL

(for instance see how in the Alttp the small armos statues outside are "trapped" into that eastern area, so they can never reach the transit to green area with soldiers, due to conflicting sprite gfx and sprite pal - and the area with new bird statue gfx is also moved away from the transit).

Hmm. Cool. I never really thought about that before.

By the way, Super Metroid had the same gfx problem, so as you might know all transits in SM are "blanked out" only the neutral gfx (door) is preserved in SM at transit.

Ah. Super Metroid. I'll never forget the summer when I worked and saved up my money and bought it with my own hard-earned cash. The PS1 and N64 were already in so I managed to get it brand-new for $30. I figured it had to be cool since I liked the original on the NES but it was a million times better! Best purchase ever...

Note: I discovered that the addresses above as well as many others in that section of the compendium were for a headered ROM despite saying "All hex offsets are for a NON-headered rom!". LOL

That's because Euclid was using a headered rom for a while and made some hex founds based on headered rom. And in the Compendium we decided to go for a non headered rom in all cases, but never updated all addresses. I believe some of them are actually Snes addresses.

Link's Awakening-style key blocks

I was just reading this thread and was rather confused. After reading the entire thing I'm left wondering if it works properly and whether or not anyone figured out which GFX needed to be edited. I'd really like to use this in the BCvsG redux.

^^Puzzledude made the gfx edit for this and yes it works!

But sometimes in my hack its buggy as when I add a chest in a room that spawn with a key in it, I have to leave the room and then return for them to open. But if I collect a key in a room and then go in another room with those, they work perfectly.

Okay. Cool. So I just need to make sure that I don't get the key in the same room as the lock?

I was especially confused about was which graphic to edit after reading all of the posts. Would it be one of the shadow graphics? If I remember correctly, this appears many times in the bin.

I actually forgot where I have the gfx blockset for this, but putting it to a shadow was no good. The actual free space to use is (if I remember correctly) bellow the big chest (2 spaces horizontally) and the odd white jar (never used), 2 spaces vertically, right of the small chest gfx. It definitely needs to be in this gfx blockset though.

And it was originally meant to be for the 3rd big key, which I'm going for in GoT. One for big chest, one for big key door and 3rd for all the key blocks. For this to work with small keys might cause problems, even if you change rooms - for some odd reason.

Couldn't the lock from the cell be used without this hack since it is separate from the bars? Then a person would only need to change the lock graphic to something that would look good on both the cell and the floor (if that step is even necessary).

SunGodPortal wrote:Couldn't the lock from the cell be used without this hack since it is separate from the bars? Then a person would only need to change the lock graphic to something that would look good on both the cell and the floor (if that step is even necessary).

That's exactly how I use it, this ASM simply implements the small key. In both cases the lock from the cell is used. But in my case, you just need to hex edit the check for the big key to compass/map and then change the gfx of map to 3rd big key and the lock into a key block.

But this ASM is needed if you decide to use the same block for small keys (intead of big key, compass or map) to open it.

Okay. That makes sense. If the locks still used the Big Key they wouldn't be nearly as useful.

Does anyone know if the music editor is safe to use? I don't actually want to add new music, I just want to alter the existing note values to change some of the songs from major to minor.

I figured it would be cool to change the tonality of certain pieces (like the village theme) to give them a "darker", more depressing vibe.

It's rather stable if you wanna do such tiny changes as I did the same, but its also easy to corrupt your songs if not careful enough, so make sure to make a backup of rom before editing those

When I first saw the topic, I thought this was about pyromaniac questions. I was so wrong.

હેદρમ wrote:It's rather stable if you wanna do such tiny changes as I did the same, but its also easy to corrupt your songs if not careful enough, so make sure to make a backup of rom before editing those

So a buggy mess like most of Hyrule Magic? Perhps the author doesn't want to release the source code because it's so bad.

Perhps the author doesn't want to release the source code because it's so bad.

+

It's rather stable if you wanna do such tiny changes as I did the same, but its also easy to corrupt your songs if not careful enough, so make sure to make a backup of rom before editing those

Ok. I'll do the safe thing and work on that in a seperate ROM.

When I first saw the topic, I thought this was about pyromaniac questions. I was so wrong.

I'm having a problem with room 64. I've changed it from this:



to this:



In the original, you come up the stairs onto BG2 despite the action of the previous floors being on BG1. Now that I've changed everything I'm coming into the room on the wrong BG layer. I need to exit the stairs onto BG1. How can I fix this?

Note: The cell bars were taken out temporarily while I was troubleshooting. They will likely be put back once I figure this out. I did manage to make it into this room on the correct BG layer by using the 12E stairs, but having the corresponding stair type in the floor below prevents the normal stairs (like 138) from working in another part of the quadrant.

In the original, you come up the stairs onto BG2 despite the action of the previous floors being on BG1. Now that I've changed everything I'm coming into the room on the wrong BG layer. I need to exit the stairs onto BG1. How can I fix this?

That's because the original settings are: Stairs1 or 2 (I don't know which, probably 2= lead to room 64, on Plain 2. Now simply change the 2 to Plain 1, which is actually the BG. It's a one byte change in hex actually. Every staircase between rooms (or holes between rooms) can be set to lead to both BGs.

That's because the original settings are: Stairs1 or 2 (I don't know which, probably 2= lead to room 64, on Plain 2. Now simply change the 2 to Plain 1, which is actually the BG. It's a one byte change in hex actually. Every staircase between rooms (or holes between rooms) can be set to lead to both BGs.

OMG!

I can't believe I forgot how easily that could be configured since it's right next to the stair/room number... I just changed that the other day in another room. I guess all of this can be a bit too much to remember sometimes since I'm tackling an entire game alone.

SunGodPortal wrote:

That's because the original settings are: Stairs1 or 2 (I don't know which, probably 2= lead to room 64, on Plain 2. Now simply change the 2 to Plain 1, which is actually the BG. It's a one byte change in hex actually. Every staircase between rooms (or holes between rooms) can be set to lead to both BGs.

OMG!

I can't believe I forgot how easily that could be configured since it's right next to the stair/room number... I just changed that the other day in another room. I guess all of this can be a bit too much to remember sometimes since I'm tackling an entire game alone.

Yes, also the same thing can be said for entrances. I was once lost here, and then found that the "ladder" simply needs to be put to 0 and some other thing to 1 and it was all ok. Since one dungeon enters into BG2, which can be a problem if you change the room to normal.

1) Do the shields have different hit boxes or do they just have different GFX and defences?

2) Is there a way to fight blind without having to first blow a hole in the floor for light to shine through?

3) Is there a specific byte that determines what boss the girl from Gargoyle's Domain (dark world dungeon 4) transforms into? Or is the code more complex than that?

SunGodPortal wrote:1) Do the shields have different hit boxes or do they just have different GFX and defences?

2) Is there a way to fight blind without having to first blow a hole in the floor for light to shine through?

3) Is there a specific byte that determines what boss the girl from Gargoyle's Domain (dark world dungeon 4) transforms into? Or is the code more complex than that?

1) They just have different gfx and defences. For instance small shield could also block the shooter's beam if it was programed that way.

2) Blind is a special boss, which needs the maiden and light.

3) and 4) It's actually one complex ASM I would say, since as you can see in PW and GoW hack, this was not touched at all, and you always need that light. I don't know if you can even insert Blind as a separate boss sprite. I forgot if this "girl" is actually the "blind" sprite (it should be so, and then the sprite reacts on light).