(Bugs) armips patch "inter-area_warps" (Portrait of Ruin)

[Aceearly1993]

https://www.youtube.com/watch?v=MEUBP_9CkNM

(After applied the current version of armips patch "inter-area_warps" - as of rev. 1.12.0) If check the warp point, then press "L" or "R" to move on a different page of map, retreat from destination selection, and quickly check the warp point again, the game will let you have access to some unintended warp spots for some reason, when choose the unintended spots character will move to spaces you did not really want character to go to. Flip the pages again will cause the warp destination coordinate to auto correct itself.

I don't know if this had been noticed/cited in the Randomizer section (I barely play the randomized DSvania games) but it looks like here it's left untouched for years.

I dunno if the editor is end of maintenance or not but Hope it gets solved sooner or later as inter-area warp is a very cool QoL feature.

[LagoLunatic]

Sorry, but I can't reproduce this. I just tried it, and reopening the warp menu after closing it always brings me back to the map for the area I'm currently in. I don't get the bug where it remembers which area you had open in the warp menu (which is almost certainly what causes the warp points to be offset compared to their true positions, as different area maps have different offsets).

I tested on this on a fresh PoR ROM where the only changes I made were:

• Add overlay 119 via DSVEdit
• Apply por_inter-area_warps.asm via DSVEdit

The most likely explanation is that the bug is caused by some other change that you made to your project besides applying this patch. For instance, maybe you overwrote part of the patch's code (in overlay 119, or the main arm9 executable) with some data by accident. If you overwrite the code and corrupt it, anything can happen, including strange bugs like this. I recommend starting from a fresh project and applying the patch and once you've confirmed that works, you can compare the patch's code in your two versions to see what's different between them.

[Aceearly1993]

Thanks, but I opened a fresh new rom, start an entirely new project, only applied the overlay 119 and inter area warp, and unfortunately this bug still happens. I'm really in lost. Is it tied to it being ran different system OSes? ( I'm using windows 10 20H2 for references.) Or am I missing something in one of the minor changes of the files in main branch where that could be the fix? I noticed something is changed here and there in the main branch but I'm too blind to find a clue/instruction on which file affected who. if that's the case please instruct/guide me which exact file should I change.

[LagoLunatic]

Is it tied to it being ran different system OSes? ( I'm using windows 10 20H2 for references.)

Your PC's OS shouldn't affect anything. And I probably tested it on 20H2 at some point (I'm currently on 21H2).

Or am I missing something in one of the minor changes of the files in main branch where that could be the fix?

This patch hasn't been modified since 2019. So whether you're using DSVEdit 1.12 or running from source shouldn't matter (but if you're using an older version of DSVEdit than that, it might matter).

The only other things I can think of that might affect it somehow are:

• Emulator/version. I tested it on melonDS 0.9.5 earlier today. But years ago when I first made the patch I think I tested on dsmume 0.9.11, and no$gba (dunno what version).
• The "vanilla" PoR ROM you're starting out with isn't actually vanilla. Maybe it's a hack that you're using as a base, or your ROM dump is corrupted somehow. Make sure you verify that the SHA-1 hash of your vanilla ROM is 382602e3615b2282eead584014125e71b5b0f033, otherwise it's not actually vanilla.

[Aceearly1993]

I verified again, the SHA-1 on the ROM I have is the same as what you've provided. The revision of the editor I am using is 1.12.0 (the latest on the released pack) I'm really in lost what else are missing (ran into the same tragedy situation as the waterwheel glitch fix patch case I issued in the past).

There're also CRC32 and MD5 on the ROM patcher js I want to also check the value of them on you end just in case if I did not miss anything and everything.

[LagoLunatic]

What is "ROM patcher js"? The CRC32 of my vanilla ROM is 96DF4C4D but that's not going to be different from yours of the SHA-1 is the same.

The only other thing I can think of is if you create an xDelta patch of your ROM that has the bug compared to a vanilla PoR ROM, and then upload the xDelta patch here (don't upload either of the ROMs). Then I can see if you're patching the ROM the same way as I am.

[Aceearly1993]

CRC32 is the same as on my end, so I'm officially lost on everything and anything when it comes to if the ROM on my end is fresh, vanilla ROM.

Anyway my project file goes: CV PoR Refined Edition 1.0.0.1.zip

Inter area warp only: inter area warp.zip

[LagoLunatic]

I applied your "Inter area warp only" xDelta patch and tried it again. I also tried to replicate the button presses from your youtube video as closely as I could from watching it. Still no bug. Works totally fine for me.

Do you have some cheat code enabled?

[Aceearly1993]

I don't have any of the cheat code enabled.

[LagoLunatic]

Dunno, I've never heard of anyone else having this issue or the waterwheel one. I guess your PC is just haunted. Call the ghost busters.

[Aceearly1993]

Oh well... I still believe it could be because one regulation in the armips patch is missing. A last request, can you verify if it happens upon patched my main project file to ROM on your end?

[LagoLunatic]

Yes, the bug doesn't occur on "CV Portrait of Ruin Refined edition 1.0.0.1". Both from a fresh save a and a complete endgame save file. Again on melonDS 0.9.5 as before.

[Aceearly1993]

Oh well... I guess I have no choice but to pass the maintenance role of the project to possession of a different people if it's the worst case. I still can't understand why it makes differences only on my end. The last variation might be the windows os revision I hope someday either you or somebody else could check the inter area warp armips patch once again regarding its behaviors on other windows os revisions starting from 20H2. Thanks for verifications anyway.

[LagoLunatic]

There's no way the windows 10 patch version makes the difference, testing that would be a waste of time. Even different operating systems entirely (like windows 8, linux, etc) shouldn't matter. But if you really think that's the cause for some reason, you can update to windows 10 21H2 and test it yourself.

Alternatively, you could try testing it in different emulators and see if the bug happens. If it happens in no$gba you could try to debug it by stepping through the asm one line at a time and try to figure out the cause of the bug.

[Aceearly1993]

It seems I detected the true source of this bug. It's tied to if the upper screen is displaying mini map or not. If the upper screen is displaying information of Jonathan/Charlotte instead of mini map before activate warp zone, the inter area warp mechanic created by the armips patch will trigger this bug.

[LagoLunatic]

You're right, I can reproduce it from the info screen.