Various glitches in my nearly complete hack

So I recently finished a hack, and I'm left with a bug that occurs in rooms 288 (Entrance 84) and 295 (Entrance 83).  When you move from the southwest to the northwest quadrant in room 288, the scrolling transition doesn't stop.  It remains stuck in an infinite loop  The same issue occurs when you attempt to exit both rooms.  I believe I've managed to narrow the issue down to the entrances as opposed to the rooms themselves.  If I assign a different room to either entrance, the scrolling bug still occurs.  However, if I assign different entrances to the rooms, the scrolling bug stops.  Moreover, I don't think it's a coincidence that this bug just happened to occur in the last two entrances.  As far as I can tell, it doesn't occur with any others.

The bug isn't present in the backup where I made my initial Hyrule Magic save, nor does it occur in the following backup I made after I edited the dungeon headers.  This bug occurred after editing my first dungeon room (room 181).  I don't know if the entrances themselves are simply corrupt, or if Hyrule Magic partially moved the code upon expansion into another bank (if that makes sense).  However, my presumption is that the entrances are corrupt because Hyrule Magic had already expanded the ROM several backups prior.


Another issue that I'd like to fix is a bug that occurs in the watergate room.  When you pull the switch to open the gate, this happens:



When you exit and return to the room, it looks as it should.  I'm guessing this is due to corruption in the programming of the flowing water when the gate opens.


Finally, here's a list of the various other bugs I've encountered thus far:

-When you return to the Swamp Palace; the key door in room 40 is locked again, but the chest is still empty.  As far as I can tell, this glitch only occurs after you save and quit.  While testing the issue, I was able to leave the dungeon and return.  I was also able to save and continue.  

-Some switch doors don't close properly.

-There is a sprite spawning issue in room 19.  Half of the enemies are missing though I found a temporary solution.  For some reason, one more Hokkubokku/Fuzzystack will spawn if there's a pegswitch in the room.

Unfortunately, I'm not quite sure where to begin in understanding the culprit for the latter three bugs, but I'm much more concerned with fixing the scrolling and watergate issues before releasing this hack.

I'm guessing these are issues that some folks here are already familiar with (especially the watergate glitch which I've never been able to avoid), but I thought I'd do my best to assess them in case nobody has.  So with that said, can I open the ROM in HxD, and replace the Hex values with those from a clean ROM and if so; how do I find what I'm looking for (namely the scrolling and watergate bugs)?  My hex editing skills are limited.

Sorry for the long post...

I remember that I already traced a scroll bug and fixed it with a 2 byte change. Don't remember the thread, but I think Puzz can help you out, along with most other bugs, as they seem to be HM related.

If you still need further help, I could try tracing the asm; this however would need you to send me your hack.

So I managed to find the thread you posted the bug fix in:

https://www.zeldix.net/t681-we-re-back-on

Not only does it fix entrance 84 (ice cave); it also fixes entrance 83!

Thanks for the help!


At this point, the only goal I have left before releasing this hack is the watergate.  Although it's only an aesthetic issue, it's very unpleasant.

So I recently finished a hack, and I'm left with a bug that occurs in rooms 288 (Entrance 84) and 295 (Entrance 83). When you move from the southwest to the northwest quadrant in room 288, the scrolling transition doesn't stop. It remains stuck in an infinite loop The same issue occurs when you attempt to exit both rooms. I believe I've managed to narrow the issue down to the entrances as opposed to the rooms themselves. If I assign a different room to either entrance, the scrolling bug still occurs. However, if I assign different entrances to the rooms, the scrolling bug stops. Moreover, I don't think it's a coincidence that this bug just happened to occur in the last two entrances. As far as I can tell, it doesn't occur with any others.

The bug isn't present in the backup where I made my initial Hyrule Magic save, nor does it occur in the following backup I made after I edited the dungeon headers. This bug occurred after editing my first dungeon room (room 181). I don't know if the entrances themselves are simply corrupt, or if Hyrule Magic partially moved the code upon expansion into another bank (if that makes sense). However, my presumption is that the entrances are corrupt because Hyrule Magic had already expanded the ROM several backups prior.

What happens here is that Hyrule Magic puts the scroll in a room from a standard to the value FF, which is way to much, and the result is an infinite scroll. This is fixable in hex, like you already did.

When you exit and return to the room, it looks as it should. I'm guessing this is due to corruption in the programming of the flowing water when the gate opens.

This is a known bug, but I never actually looked into it. The debug method is similar - trace to see what's loading wrong, do the same when the switch is pulled in original and bring back the old value with hex. I solved this by removing this room altogether.

-When you return to the Swamp Palace; the key door in room 40 is locked again, but the chest is still empty. As far as I can tell, this glitch only occurs after you save and quit. While testing the issue, I was able to leave the dungeon and return. I was also able to save and continue.

-Some switch doors don't close properly.

-There is a sprite spawning issue in room 19. Half of the enemies are missing though I found a temporary solution. For some reason, one more Hokkubokku/Fuzzystack will spawn if there's a pegswitch in the room.

Most of this is ASM based. What's happening in number 1, is that the game is falsly writing to Srm and it doesn't "grasp" that the door was unlocked already. Needs ASM tracing. The special doors seem to have a "limit". On certain locations special indoor doors (shutter, key-door etc) will not work. The shutter door also might not behave normally on these locations. The latter seems to be a sprite limit issue, which again needs tracing to see, what needs to be changed.

Note: I had all these problems before, but I solved them by using backups, or hex comparing - and brought back the original code (the location was found by blind partial code pasting from the original), or I renounced on the things that didn't work.

Since this problem is likely to crop up in other hacks due to HM being the only gig in town, perhaps at some point a tutorial may be in order.

Great that you found the thread with the scroll fix... new to these forums and you know it already better than I do  

Regarding your remaining bugs, I can either help to try finding an asm solution or you debug it with Puzz's suggested way (renouncing on them or copy/paste code from the native rom).

Only the locked door problem is maybe a thing I cannot fix, since it is srm related.
Look MoN's srm.log for more details:
https://www.zeldix.net/t143-disassembly-zelda-docs

Code:


$000 - $24F : Data for Rooms (two bytes per room)

High Byte               Low Byte
d d d d b k ck cr       c c c c q q q q      

c - chest, big key chest, or big key lock. Any combination of them totalling to 6 is valid.
q - quadrants visited:
k - key or item (such as a 300 rupee gift)
d - door opened (either unlocked, bombed or other means)
r - special rupee tiles, whether they've been obtained or not.
b - boss battle won

qqqq corresponds to 4321, so if quadrants 4 and 1 have been "seen" by Link, then qqqq will look like 1001. The quadrants are laid out like so in each room:

---------------
|      |      |
|  4   |  3   |
|      |      |
|-------------|
|      |      |
|  2   |  1   |
|      |      |
---------------

Breakdown of where the data comes from in work RAM: (we'll reprint the diagram)

High Byte                   Low Byte
d d d d b k ck cr       c c c c q q q q      
| | | | | | |  |        | | | | | | | |
| | | | | | |  |        | | | | \-+-+-+--- Derived from $7E0408
| | | | | | |  |        | | | |
| | | | \-+-+--+--------+-+-+-+----------- Derived from ($7E0402 >> 4) in 16 bit mode
| | | |
\-+-+-+----------------------------------- Derived from $7E0400



The room information is stored in 2 bytes. Your setup for this dungeon room is apparently not supported by the save system (too many locked doors or chests in this room). I think you must change the room setup to fix it, maybe it is also a good idea to see in the ram/sram how the room data is stored in your game (which bits are set, so you know why it isn't saved.

Some explanation on this
$000 - $24F : Data for Rooms (two bytes per room)
This is ram 7E/F000-7E/F24F, you need your room number in hex to find your 2 bytes. E.g., you edit room 29 in HM, this is hex room 1D. Now you take this *2 since we store 2 bytes... so 1d*2=3A.
7e/f000+3a=7e/f03a. Here you find the 2 bytes of your room. I can't tell right now which is the high and which is the low byte since some bytes are reversed, but that's easy to find out.

Now you can look with geiger on your debug console -> show hex -> view ram and observe your ram address. I do not know what the problem here might be though.

Puzzledude wrote:The special doors seem to have a "limit". On certain locations special indoor doors (shutter, key-door etc) will not work. The shutter door also might not behave normally on these locations.

Is this issue related to the number of doors overall or on a per room basis?  There's only one door in room 95, and it still doesn't shut properly.  Moreover, that door is a key door in the unhacked game.  In other words, I replaced one special door with another.  Perhaps this room only likes particular special doors.  I actually had to place two shutter doors (one on top of the other) in that room in order to prevent Link from walking through it as if it's an open door).  Not sure why, but it's worked in other rooms as well.

Puzzledude wrote:Note: I had all these problems before, but I solved them by using backups, or hex comparing - and brought back the original code (the location was found by blind partial code pasting from the original), or I renounced on the things that didn't work.

I made 23 backups thus far, and while I was aware of the bug when it happened; I went ahead and continued developing the hack anyway because I assumed there was nothing I could do to avoid it.  The bug occurred after I began editing the Tower of Hera.

Puzzledude wrote:Most of this is ASM based. What's happening in number 1, is that the game is falsly writing to Srm and it doesn't "grasp" that the door was unlocked already. Needs ASM tracing.

Conn wrote:Only the locked door problem is maybe a thing I cannot fix, since it is srm related.

I went ahead and created a workaround which I'm actually more satisfied with.  There is no longer a locked door in room 40.

Conn wrote:If you still need further help, I could try tracing the asm; this however would need you to send me your hack.

I appreciate the offer.  I might take you up on it.  I'll have to make some notes first though.  Do you want me to send it to you via PM or email?

Conn wrote:Now you can look with geiger on your debug console -> show hex -> view ram and observe your ram address. I do not know what the problem here might be though.

I've been playing around with Geiger's SNES9X Debugger, but I'm restricted to a laptop with a tiny screen (Inspiron Mini) which makes it a pain.  I have Linux Mint 17.1 installed on my main rig, and I can't seem to get the debugger to run with WINE.  I played around with it for a couple of hours in the watergate room; comparing my hack to the unhacked game, but this is my first attempt at tracing (not sure if I even came close to doing it right, lol).  I'll have to look into MoN's notes some more.  The changing hex values tend to throw me off a little (makes it harder for me to understand what to change).  I have noticed a difference from 7E1BC0-7E1CB0 when I pull the switch.  However, those same values change when I enter an indoor area, or when I transit from room to room.  I'm wondering if there's one or more hex values elsewhere that result in that change.  Is there a more convenient way to know what vicinity to look in that I might be overlooking, or is this just a time extensive process?

There's one minor aesthetic issue that I forgot to mention that's not really a bug.  I was wondering if a little ASM could be used to make pegswitches appear under water as opposed to on top of it?

you can send me the hack with issues to con.s@gmx.de ,also include some savestates which I can load with Geiger debugger. but take your time I am busy with fixing AST bugs (voice acting related) and real life at the moment.
I'm not sure whether peg switches can be put under water...

I'm not sure whether peg switches can be put under water...

Hmm. This caught my attention. The fact that he even thought of it makes me look forward to his hack.

SunGodPortal wrote:

I'm not sure whether peg switches can be put under water...

Hmm. This caught my attention. The fact that he even thought of it makes me look forward to his hack.

Hopefully I won't disappoint.   This hack does fall under the "Improvement Hack" category after all.  While the hacking phase didn't take too terribly long, I spent significantly more time with the planning phase.  I have graphs of each dungeon with every change I made noted as well as a list of all room header changes.  That way I could squeeze everything in without having to worry about the dreaded "Not enough room for header" message later.

Conn wrote:you can send me the hack with issues to con.s@gmx.de ,also include some save states which I can load with Geiger debugger. but take your time I am busy with fixing AST bugs (voice acting related) and real life at the moment.
I'm not sure whether peg switches can be put under water...

No worries.  I'm in no rush.

I do have an idea for a backup plan for the water submerged pegswitch.  Some time after the water completely surrounds the pegswitch, the pegswitch sprite could be destroyed, and a desaturated pegswitch tile could be placed underneath the sprite.  Perhaps this could be done by ASM modding the "Turn on Water" room header tag.

You can prepare your files and send them to me, no idea yet however when I will have time to look into them ^^''

Conn wrote:You can prepare your files and send them to me, no idea yet however when I will have time to look into them ^^''

I'm in the process of doing that now. I'm currently doing a quick playthrough to make sure I've worked out all the kinks.

Alright, I received your mail (landed in my spam folder). About the shutting doors, you probably should ask Puzz, these are HM related problems, I cannot solve with asm.

You also don't write anything about fixing this bug, do you still want it to be fixed?



Of course we (admins and mods) respect your intellectual property and will not forward your files to any third person.

Conn wrote:Alright, I received your mail (landed in my spam folder). About the shutting doors, you probably should ask Puzz, these are HM related problems, I cannot solve with asm.

You also don't write anything about fixing this bug, do you still want it to be fixed?



Of course we (admins and mods) respect your intellectual property and will not forward your files to any third person.

No worries on the shutter doors then.  It's only a minor aesthetic issue

I do want the watergate bug fixed.  I mentioned in the first sentence that I included a save state of the watergate room, but other then that I wasn't sure what to say.

Let me know if there's anything else I can do.

So here's the problem with the watergate submerging everything:

Corrupt:

Code:


$01/CBAC A9 0C 00    LDA #$000C              A:0001
$01/CBAF 85 B9       STA $B9    [$00:00B9]   A:000C
.....
$01/CC9F B7 B7       LDA [$B7],y[$0C:F1CD]



original:

Code:


$01/CBAC A9 04 00    LDA #$0004              A:0001
$01/CBAF 85 B9       STA $B9    [$00:00B9]   A:0004
.....
$01/CC9F B7 B7       LDA [$B7],y[$04:F1CD]   A:F1CD


As you can see, HM somehow changes this bank from 04:F1CD to 0c:f1cd. I have no idea to which avail...? Maybe it is important at another place, means there might be a reason why the original HM author changed this bank. If the game will bug at another place we must make a workaround: make a JSL to an unused region of the rom, check for the room number, if watergate, load bank 04 if not 0c.

So, to be on the safe side, use this code (pc, not headered:

Code:


at
00/cbac change a9 0c 00 85 b9 into 22 00 b0 20 EA
(this will make a JSL to pc 10/3000
at
10/3000 write this code
a5 A0 c9 0b 01 f0 05 a9 0c 00 80 03 a9 04 00 85 b9 6b
(this will load the room index $a0 check whether you are in room h010b = d267, if yes, load bank 04 if not load bank 0c



Anyways, the fix would be:
pc, no header: 00/cbad: 0c -> 04

I'll try then with the peg switch

You really should pm Puzz and ask for his mail address so you can send him your rom as well. He surely can help you with the shutter doors. SePH also had some problems with these doors and Puzz found out he used the wrong doors, also maybe the chomp chain issue is also HM related. I'm really no expert in HM editing, so he's the guy to ask

Some switch doors don't close properly.

SePH also had some problems with these doors and Puzz found out he used the wrong doors

If you're nearly finished with your hack you probably already know this stuff but I figure it wouldn't hurt to mention just in case...

Choosing the proper door can be very confusing and frustrating. There are so many of them and no way to differentiate between them in the editor (apart from numbers and generic pics). To help find the right choice for the function I'll usually open up a second copy of HM with a stock ALttP ROM, find a door that serves the EXACT same function and write down the number from the selection window (I've noticed some of them show the wrong numbers in the regular part of the editor).

If that doesn't take care of your switch doors that aren't closing properly, if you are sure you are using the proper door type it wouldn't hurt to click the "More" button near the top of the dungeon editor (next to EnemyBlk) and make sure that your room is "tagged" correctly.

Anyway, good luck.

Anyways, the fix would be:
pc, no header: 00/cbad: 0c -> 04

This fixes the issue of the flood. Thank you Conn for another debug of a problem, that's been around for ages.

The Long method however doesn't seem to be working, but thats ok, since it is clear that this value should be 04 (like in the original), value 0C is definitely wrong. In PD's quest HM put this to 0E even (naturally I blocked the entire pull switch).

That's strange, for me it works:

Code:


$01/CBAC 22 00 B0 20 JSL $20B000[$20:B000]   A:0001
$20/B000 A5 A0       LDA $A0    [$00:00A0]   A:0001
$20/B002 C9 0B 01    CMP #$010B              A:010B
$20/B005 F0 05       BEQ $05    [$B00C]      A:010B
$20/B00C A9 04 00    LDA #$0004              A:010B
$20/B00F 85 B9       STA $B9    [$00:00B9]   A:0004
$20/B011 6B          RTL                     A:0004



Maybe it has something to do with your room? Native it is 010b (267) which is out of range of HM editing...


Anyways, I looked for the pegswitch submerged, and here's nothing to achieve without some difficult asm. Usually you have bg priority bits set, but these are not valid for the pegswitch for some reasons. It's the same issue like throwing your boomerang or any other item in the foggy master sword forest, the items are not below the bg1 fog layer.

I could however, write an asm to submerge it with a palette change, but this one will be very special and a bit bug tests will be necessary. Also, the blue peg looks good, but there's no real good palette for the orange peg switch. Here are the palettes you could choose from.



image1 (top left) would be perfect for blue peg, 2-4 are options for orange peg you could choose if you want to go for it. image3 bottom left looks best (don't worry about the messed up hud, I checked with my debug rom).

here's the chomb issue:

Chomp Chain Link Issue
This is a very minor bug that I'm not really worried about. I'm only mentioning it because it might be
an easy fix. While transiting from room 123-124 & 124-125; 1-2 chomp chain links will appear on the
screen. I initially suspected that is was due to enemy block changes [19-37], but 124 & 125 are both
set to Enemy Block 37. I think it might be an issue with the chomp sprite because this bug doesn't
occur if there are no chomps in the rooms.

Before I try tracing it, has anybody experienced this? This sprite pops up when transiting into a room with the chomp chains

Conn wrote:I could however, write an asm to submerge it with a palette change, but this one will be very special and a bit bug tests will be necessary. Also, the blue peg looks good, but there's no real good palette for the orange peg switch. Here are the palettes you could choose from.



image1 (top left) would be perfect for blue peg, 2-4 are options for orange peg you could choose if you want to go for it. image3 bottom left looks best (don't worry about the messed up hud, I checked with my debug rom).

Does the second option I offered require difficult asm? I was also considering the idea of using a grey palette (if available) for both orange and blue, but I would imagine you would see the palette change (and perhaps appear on top of the water) when you transition to another room.

Btw, I'm really impressed with everything you've done so far. Great job on finding the watergate issue.

I'll have to follow up more on all this later as I have to go to work for now. Thank you!

On a second thought, Puzz, this bank change appears too specific to be a random bug, my best guess is that the HM author did it on purpose, probably to have place for custom dungeon water bg1 layers. - you can verify this by checking if the dungeon flood still works in your rom?
In this case we just, but urgently need to check whether we are in light world (load bank 04) or in dark world load bank 0c or oe (whichever value HM set here).

If my assumption is correct, you'd need this code:

Code:


at
00/cbaf change 85 b9 a9 cd f1 into 22 00 b0 20 EA
(this will make a JSL to pc 10/3000 - note it is a different address than in my above posted code, you'd need to restore at 00/cbac a9 00 0c or in your case a9 00 0e)

at
10/3000 write this code
85 b9 af ca f3 7e 29 ff 00 c9 40 00 f0 05 a9 04 00 85 b9 a9 cd f1 6b
(first the HM edited value will be stored to $b9, then my code will check whether you are in light world and if yes, overwrite the HM bank with bank 04. Else leave the value HM has set)


Edit: hm, no, forget what I wrote. I just tested the flood asm for dungeon and that address appears not to be involved so for now pc, no header: 00/cbad: 0c -> 04 is everything needed to fix this. No idea why HM changes this  

Jeimuzu:
Maybe you can explain a bit more what you require? I would like to find the easiest solution here. If the pegswitches submerge below the water surface, they cannot be used anymore anyway (grey palette or not) as long as you cannot reach them with the boomerang. I think, once the water filled the room the water cannot be removed anymore without leaving the dungeon, so in the end it won't matter whether or not they get a grey or another color. But it would be in any case better if you find a HM solution for this. Think maybe about having the peg on a podest, so it cannot get flooded?

hm, no, forget what I wrote. I just tested the flood asm for dungeon and that address appears not to be involved so for now pc, no header: 00/cbad: 0c -> 04 is everything needed to fix this. No idea why HM changes this

Yes. I tested this and the value should always be 04. Maybe HM was trying to change the pointer and falsly move the data.

A similar thing happens with the code for the Title screen and other screens. When HM runs "out of space" it forces all screens to a space just beyond 100000. This is actually done correctly for a change (but it forgets to expand the rom to 2MB, otherwise the screens still appear bugged).

A similar thing happens with the code for the Title screen and other screens. When HM runs "out of space" it forces all screens to a space just beyond 100000. This is actually done correctly for a change (but it forgets to expand the rom to 2MB, otherwise the screens still appear bugged).

So does that mean it's safe to use the screen editors if your ROM is already expanded (so it doesn't create an odd size) and there is no data in that particular spot to be overwritten? I've been afraid to use these parts of HM because what I had previously heard made me assume that it just messes up a bunch of stuff. This makes it sound like these parts are still safe and predictable, albeit quirky.

I mean, all in all HM is a fabulous editor (where would we be without it? I guess even this site wouldn't exist...), so I always will be grateful to SephirotX (<- is this the correct?).
It is however a pitty that he abandoned this project and disallows others to debug it (Ganon shaking camera, scroll bug, flood bug, title screen bug ... .... ......... A simple ok to MoN is all needed

Once the pegswitch is submerged, it won't be used again.  The water is still there even if you leave the dungeon and return.  So I'm fine with a gray palette.  One thing I'm not quite sure of is when the palette change occurs.  Is the palette different the moment you enter the room, or does it change after flipping the switch?  Depending on what's actually happening will determine whether or not it's an ideal solution.

I'll try to expand on my other idea a bit more.  In order for it to work, there would need to be room for 4 extra 8x8 tiles.  In other words, a pegswitch tile (which I included in the zip file I sent you with the appropriate palette) would be placed underneath the pegswitch sprite:

When the water rises to a certain point; the pegswitch sprite is destroyed thus exposing the grey pegswitch tile.

So in the above gif, the pegswitch sprite is still present until the water starts rising.  Once the pegswitch is submerged, the sprite is no longer present, and what you see is the tile with a desaturated palette (same palette used for the pots).  The point where I think the pegswitch should be submerged is when the water is covering 4 pixels of wall coverage.  Here's an example:

However, since I'm not familiar with ASM; I don't know if this is an easy solution.

Conn wrote:You really should pm Puzz and ask for his mail address so you can send him your rom as well. He surely can help you with the shutter doors. SePH also had some problems with these doors and Puzz found out he used the wrong doors, also maybe the chomp chain issue is also HM related. I'm really no expert in HM editing, so he's the guy to ask Wink

The shutter doors I used are the only ones that Link can't walk through.  According to Puzzledude "The special doors seem to have a "limit". On certain locations special indoor doors (shutter, key-door etc) will not work. The shutter door also might not behave normally on these locations."  I think it makes since because there are certain rooms with no items in the unhacked game that don't seem to appreciate it when you add some.  Item markers appear in random places after saving and revisiting a room (I suspect the placement of these item markers are borrowed from either another room or overworld area).  I could see if he's interested, but I'm not sure this is a HM related issue based on what he wrote.  It might need an ASM workaround in order to be fixed.

I played around with your podium idea, but items can't reach the pegswitch.