Parallel Worlds Blind room door

Ok, so I've had a burst of productivity and motivation, and decided to try and fix the game-crashing door in Blind's room in Saria's Gardens. Using the HM unlock patch so I can view the room in HM, it looks like there is simply nothing associated with that door, so the best way to fix it would be to simply remove it entirely. I don't have a lot of experience with HM, so I'm hoping that somebody can help me out. First of all, I know that the unlocked ROM can't be edited in HM, because it just crashes. So the next best thing would be to export the room directly in hex into the vanilla aLttP ROM, edit the room, and then import it back. I've heard that this can be done, but can't find directions on how to do it. This post got me as far as figuring out where the room's header is, but I don't know where the room's actual data is. What I do know is that it is room 172 (0xAC), which appears to be nearly identical to the original aLttP room. The room header for room 172 is at 0x27D0F-0x27D15 and its contents are

Code:

E0 17 0A 20 00 25 00

I tried editing room 172 in HM in the original ROM, but HM makes a ton of changes to the ROM immediately upon opening it, so it's nearly impossible to find the actual changes I made via simple hex diff. Any ideas?

Try changing the byte at $11A775 from $81 to $61. If I'm right this should simply move the door from Blind's room to an empty adjacent room, removing it as a problem. I can test it in the original rom, where the address is different so it'll only be partial confirmation, but if you have a savestate or the ability to test it quickly in PW that would be even better.
Edit: I'll go through the process of how I got there if you'd like as well (if it works)

I don't have time to playtest tonight, but it looks good in HM.  Thanks again, man

Try changing the byte at $11A775 from $81 to $61.

Nice find. I actually edited a similar byte, when making Parallel Remodel - as you can see there is no door there in the Remodel. You see this byte controls the location of an element on bg3, which is this door. The byte in close proximity should also control the door type - so you can for instance also control the type of the door and change it to something solid - like shutter.

Why wasn't the door removed before the original release?
As far as I know Blind doesn't require a door in his room to work

IntimFuchtler wrote:Why wasn't the door removed before the original release?
As far as I know Blind doesn't require a door in his room to work

I once asked Euclid the same thing and he said that this door simply was forgotten and was never removed. I'm not sure if you know, but Parallel Worlds is not compatible with Hyrule Magic, since it has the dungeon data shifted (moved) to be able to have more data. So it was not so easy to just edit this out - since you had to find that specific address written above (in hex). Finding and editing the info that superskuj wrote above is difficult and requires a lot of knowledge on pointers (since you need to find the room data, move it to another ROM, edit the door with HM and then see which byte changes).

I did remove the door in Parallel Remodel though.

Playtesting confirms it worked perfectly.

Very nice. I'm just learning about this stuff so a task like this is good practice and a lot of fun too

qwertymodo wrote:Playtesting confirms it worked perfectly.

If you think about it, testing is not necessary at all, since this particular byte controls the X and Y position of the door element on bg3. It can not possibly destroy anything else. But it is good to know that this crash bug is out the way.

superskuj wrote:Very nice. I'm just learning about this stuff so a task like this is good practice and a lot of fun too

Yes, I'm quite amazed you were able to read all the pointers necessary to eventually locate the data for this particular room - and that you also found the data location for this particular door object. I've done this a lot when making the Remodel, but I of course did not write down the exact location for this door, but I know I removed it.

As a programmer by trade, "testing is not necessary at all" are dangerous words

I mean, sure, I'm not going to restart my entire play through again to test this, but at least "unit testing" the one room to be sure that I patched the right spot and that it did what I expected...

qwertymodo wrote:As a programmer by trade, "testing is not necessary at all" are dangerous words

I mean, sure, I'm not going to restart my entire play through again to test this, but at least "unit testing" the one room to be sure that I patched the right spot and that it did what I expected...

Yes of course local testing is welcome to see things in the actual game, but you see I know the Alttp dungeon data and in this case only 1 byte was changed, that I know exactly what it does. I know for a fact that changing the locations of the objects will not bug the rom out (since the string is not shifted, like if you would choose "add" or "remove"), unless they go off-screen. In fact, this method of editing is the safest possible. If HM would be programed to work like this only, it would never bug out the rom. It bugs the rom, when it needs to shift data and recalculate all pointers for all rooms when just one room was edited.

Problems can also occur with special doors, like if you would use a shutter door - this in fact needs to be tested, since the shutter might not work and you could walk through the shut door.

And of course I assumed you would test the entire game at the end, as it is common practice before any release.