LagoLunatic / DSVEdit

Multi-purpose editor for ROM hacking DS and GBA Castlevania games
MIT License
91 stars 12 forks source link

Improve compatability with ROM patches from ROMHacks + immediate fix for now #79

Closed RedNova25 closed 9 months ago

RedNova25 commented 9 months ago

Summary

I was trying to load a version of Dawn Of Sorrow with a ROMhack xdelta patch applied. The ROMhack does change the first 16 bytes of the NDS file so this messes with the Extract ROM autodetection of the game. If I edit the first 18 bytes of the ROMhack rom so that they match the original game ROM, I get an error that doesn't make sense.

This could potentially be fixed by adding an "Extract ROM WIth Override" where you can specify the game and region of the ROMHack patch.

In the meantime, please let me know what I can do in order to open the ROMHack in DSVEdit.

Detailed Explanation

The ROMhack I am trying to open in DSVEdit is Castlevania: Dawn of Sorrow - Definitive Edition+. The ROMhack ROM was created using a Dawn of Sorrow ROM and an xdelta patcher. When I open the ROM in DSVEdit with "Extract ROM", the error I get is below.

---------------------------
## ROM Extraction failed
---------------------------
Failed to extract ROM with error:
Specified game is not a DSVania or is not a supported region.

<PATH>/DSVania_Editor_1.12.0_x64/dsvlib/game.rb:1441:in `verify_game_and_load_constants'
<PATH>/DSVania_Editor_1.12.0_x64/dsvlib/game.rb:47:in `initialize_from_rom'
<PATH>/DSVania_Editor_1.12.0_x64/dsvedit/main_window.rb:338:in `block in extract_rom'
<PATH>/DSVania_Editor_1.12.0_x64/dsvedit/main_window.rb:1480:in `block in execute'

I looked into the source code referenced in the trace (but did not edit it). I saw that it was determining the ROM's game identity (in verify_game_and_load_constants in game.rb) using the first 16 bytes of the ROM file, which the ROMhack changed. I used Notepad to replace the first 16 bytes of the ROMhack ROM with the first 16 bytes of the original game. I am unsure if the copy and paste operation used modified the whitespace characters or not.

Below is the error I get when I run "Extract ROM" again, which is typically invoked when the region of your ROM is incompatible with the tool. This doesn't make sense, because the E in ACVE (occurs in first 16 bytes of original ROM and ROMhack ROM) means that the ROM's region is USA. See here for why. There may be other indicators for ROM region that I do not know about.

---------------------------
ROM Extraction failed
---------------------------
Failed to extract ROM with error:
This ROM revision is not supported. For the Japanese version of Dawn of Sorrow, only the original version is supported.

<PATH>/DSVania_Editor_1.12.0_x64/dsvlib/nds_file_system.rb:661:in `read_from_rom'
<PATH>/DSVania_Editor_1.12.0_x64/dsvlib/nds_file_system.rb:43:in `open_and_extract_rom'
<PATH>/Desktop/DSVania_Editor_1.12.0_x64/dsvlib/game.rb:60:in `initialize_from_rom'
<PATH>/Desktop/DSVania_Editor_1.12.0_x64/dsvedit/main_window.rb:338:in `block in extract_rom'
<PATH>/Desktop/DSVania_Editor_1.12.0_x64/dsvedit/main_window.rb:1480:in `block in execute'

I attempted to inspect more of the code but I have not worked in Ruby (let alone have an IDE for it) and there is a lot going on. Please let me know how I can modify this ROMHack in DSVEdit, before considering modifications to DSVEdit features (unless those modifications are necessary). The ROMhack was worked on by LagoLunatic so he might know more about what to do.

Technical Details

DSVEdit Version: Stable Release 1.12.0_x64 DSVEdit Version Released: August 29th, 2021

Original ROM: Castlevania - Dawn of Sorrow (USA).nds, Decrypted CRC32 of Original ROM: 135737F6 Original ROM first 16 bytes: CASTLEVANIA1ACVE

Link to ROMHack here Link to xdelta patcher here Name of ROMHack: Castlevania: Dawn of Sorrow - Definitive Edition+ ROMHack Version: 2.3 ROMHack xdelta patch details: Full Version, Definitive Mode, Dignity Art ROMHack xdelta patch filename: Cv DoS DE+ (v2.3) (Full, DM, Dignity Art).xdelta ROMHack first 16 bytes: CVDOSDE+ ACVE

LagoLunatic commented 9 months ago

I didn't work on the hack directly, Masked Dedede just asked me questions about hacking so I assume that's why I'm credited for it.

The reason the hack cannot be opened in DSVEdit isn't because of a bug in DSVEdit, it's presumably because the hacker specifically edited their hack to make DSVEdit unable to open it because they don't want people looking through their hack for some reason. Personally I don't like when hackers do this, so I refused requests to add this feature into DSVEdit itself. But I'm also not going to do the opposite and add the ability for DSVEdit to open hacks that have been specifically made DSVEdit-incompatible on purpose like you want (that's probably not even possible since the hacker could just change something else in a future version).

If you want to open this hack in DSVEdit, your options are to figure out what edits the hacker made on your own and revert them manually (it's going to be more than just the first 16 bytes), or ask Masked Dedede directly and try to convince them to let you edit their hack. I have no interest in looking into this.

RedNova25 commented 9 months ago

I understand now and I didn't mean to suggest bypassing the hacker's permissions or intents to not allow me to edit. Thank you for making me aware of the situation, and the quick response @LagoLunatic