RT (Room Transfer) program

Ok perfect, works now.

https://www.dropbox.com/s/t81ywev9rxn3cfk/RoomTransfer.zip

So the remaining things are damage pits and telepatic messages.

I looked further in the damage pits code, extending this should be no problem. I think the reason why you don't found the hardcoded 0x72 is because there is only an hardcoded 0x70. So normally this could should only check 0x70 / 2 = 0x38 = 56 (in decimal) pits. But there is a BPL instruction (brach if plus/positive) and therefore if the counter is 0x00 (56 pits checked) it checks another one (the 57th) cause 0x00 is positive too.

So there should be no limit. The question is now, how to recode it. There are two ways:

First: Let the code in place and change only the 0x70 to a maximum of 0xFF, so there would be 0x100 = 256 (decimal) rooms possible with damage pits.

Second: Move the code to make it a 2 byte value to have the possibility to make all 320 rooms with damage pits.

I think the second one isn't usually and would makes the coding more complicated to me. The first one should be enough, cause no one will make a zelda hack with holes in nearly all rooms.

This is great. Regarding tel. messages. Since there's a full 320 rooms usage already, there's no need to move this. The reason for this is also, that the pointers are the same as with sprites (so it requires another custom asm to move).

Regarding the pits (great news!). 256 rooms with pits is plenty enough. If you could point out the address with this byte it would be nice, since when you use the program, you don't see this change (like with the chests), since the Alttp does not go beyond the old value, so this byte does not change.

Ok, pits done, tested and seems to work.

https://www.dropbox.com/s/t81ywev9rxn3cfk/RoomTransfer.zip

I was wrong about the 1 byte value for pits, it's already a 2 bytes value, so all 320 rooms can have pits nativley.

Messages next. Good to hear that i don't need to move this.


EDIT: Hex-Location for the value of how much pits are read is 0x0394A6

You can see all these adresses when looking in the RT.cpp, there is a list with #define-instructions. For example:
#define ROOM_PITS_POINTER_LOCATION 0x0394AB
#define ROOM_PITS_DATALENGTH_VALUE_LOCATION 0x394A6

Pointer location means the location of the pointer that leads us to the data.
Data length value location means the location of the value that tells us how much data the game will read.

This is great news. I will test this some more. Didn't actually realize I could look into the cpp file for the locations.
 
EDIT
This last version is awesome. Everything seems to work normally and the bank breaches are ok. I've also tested the chests and pit expansions. Both are working (tested). It is a relief to have more of both (57 rooms out of 320 for pits was just to low). I could also remodel Bruce campbell vs Ganon with its bugged pits to now have normal hurt pits. Plus, some master quests have those bugs, since they could not expand the number of hurt pits.

I am glad to see that you find this tool useful :-)

Ok, messages are done, so now all data will be copied when using RT.

https://www.dropbox.com/s/t81ywev9rxn3cfk/RoomTransfer.zip

I found an odd problem. The toll won't work properly when using the ouput rom as new input rom to copy some rooms. Will try to fix that.

Is there anything left i should do?

Since the entire indoors is now covered, I think only fixing the existing problem you've found.

Ok and i will try to make it work with an headered rom.

The easiest way, I think, is to determine if there is a header and then make the program remove it first, and then do the same operation as for no-header.

Yeh i thought so, but actually i am thinking about how to determine it, cause it doesn't seems that the header consists of 0x00's. Sometimes it differs. Maybe the easiest way is to to count the 0x00's in the first 0x200 bytes and check if it's more than 0x100 (more than 50 percent) cause no zelda rom hast 0x100 bytes of 0x00's in the first 0x200. But this isn't very elegant.....

One possibility would be to search for sequence 78 9C 00 42 9C. All Z3 roms/hacks start this way. If this is at 0x00, then we have no-header, if this is at 200, then it is a headered rom. If it is no-header, then proceed to code, if the rom is headered, remove the first 200 bytes and then proceed to code.

Oh yes, you're right, i don't thought this way :-D, good idea! Ok i will do it so and then upload the new version.

This leads me to another idea, i will test 0xFFC0, should be "THE LEGEND OF ZELDA", if not, i remove the first 0x200 and test again, if not, it's possibly not zelda.

This is of course a possibility. Of course it will not necessary read The legend of Zelda in hacks. For instance PW has it LOZ: Parallel Worlds. This reminds me of zcompress. Did you know it does not work if you change this line to something different.

Just my two cents, here's how I check for a header:

Code:


   
    ExpandInfo::ExpandInfo(std::ifstream &zeldaFile)
    {
        int fileLength = FileSize(zeldaFile);
       
        // ---------------------------------
       
        m_data = new Buffer(0x200);
       
        m_headerBuf = new Buffer(0x200);
       
        if(fileLength & 0x200)
        {
            m_hasHeader = true;
           
            zeldaFile.read(reinterpret_cast<char*>(m_headerBuf->contents),
                          0x200);
           
            fileLength -= 0x200;
        }
       
        m_rom = new Buffer(fileLength);
       
        zeldaFile.read(reinterpret_cast<char*>(m_rom->contents),
                      fileLength);
       
        Initialize();
    }
   


@puzz: Good point, i don't thought about that, so i will use your first hint, check the first line.

@math: Elegent way, but it seems you assume that fileLength&0x200 is only true if there is a header. For example one of my unhacked roms "Zelda3(U).smc" has no header and a length of 1.050.171 Bytes. This ANDed with 0x200 is 0x200 and therefore true. So are you sure this works in every case?

XaserLE: That's 0x10063B bytes, which is either an overdump or has actually been hacked by Hyrule Magic. Hyrule Magic creates noncompliant roms because it tacks on data to the end of roms without rounding up the filesize to a 2 megabit boundary at the time of file writing (fwrite / WriteFile / etc). If you want to handle noncompliant roms, I'd just provide the user a way to override this or fall back to detection mechanisms like you guys have been saying. I find those to be unreliable though, as a hacker can and will change any of the game internals if they really want to.

Yeh i know, but i want to support a lot of roms and don't want this tool to break cause a rom doesn't fit rounded filesize (by the way: i always thought this needs to be a multiple of 8 megabits, good to now).
So i think puzz's way is a good compromise since every game seems to use a slightly different initialization code at the beginning.

Ok, works with headered roms now, even if only one of the input roms are headered. Not one of my best pieces of code, but works.

https://www.dropbox.com/s/t81ywev9rxn3cfk/RoomTransfer.zip

This final version is great. An importaint benefit to the Z3 hacking/data extracting. I've also made some precalculation roms earlier and now I can do all indoors on separate roms and extract/view the data easily. And then glue the dungeons together on a precalculated rom (which uses max space for all indoors). It is a matter of copy/paste now, without calculating a single pointer.  

Thank you so much :-), it's great to know how useful this is.

Bugfix:
https://www.dropbox.com/s/t81ywev9rxn3cfk/RoomTransfer.zip

MIRROR:
http://www.bwass.org/bucket/RoomTransfer.zip

Like i said before it was not possible to use the output rom of the tool (the merged rom) again with RT.exe to merge it with another one (to merge multiple rom's all together in one). The problem was that i forgot that i overwrite the sprite table pointer with the long jump, so in the new rom there was no sprite table pointer anymore. This was fixed.

This should be the final version of this tool but i discovered a little "problem". I used the original rom to test and used the RT the following way: "RT.exe Zelda.smc" so it creates a new one named "_Zelda.smc" with data extended and moved to the end. When using this one again (should produce the same rom without differences) "RT.exe _Zelda.smc" there was a slighly difference. It seems that one torch data is missing (exactly two bytes). When using the output rom "__Zelda.smc" again with "RT.exe __Zelda.smc" it produces the same rom like "_Zelda.smc" without differences, so this problem occurs only one time. No idea what happend here.

How it is with an unlimited on Sprites in one room ( Dungeon )
Everytime i'll get this poppup



[Not Enough Space For Sprites] is this issue to fixid or?

Hyrule Magic can only use what is there in the rom. You are not able to insert new sprites without deleting an old one. The tool in this thread can't change Hyrule Magic, but you can use two different rom's to edit and merge them after editing. In this way it is possible to have more sprites than there was. But this should be a final step in rom-hacking. The merged rom is no longer editable with hyrule magic.

So this issue can't be fixed. If you are a beginner in hyrule magic, you don't should mess with RoomTransfer tool, it's written for advanced users.

I suggest you stick with what HM is capable. Remove some sprites in other rooms or in the overworld and then add new sprites.

PS @XaserLe
The IQ hack is actually using your strategy of reorganizing indoors data to have unlimited space for room header, sprites etc, but it does not use all rooms.