Well, sorry ZOLE hasn't been released yet, but I've been testing it and putting finishing touches. For example, now you can copy/paste map data and middle-click to fill tiles. But, I've also fixed several bugs and since then I haven't been able to find one. I'm creating some part of a hack right now and once I see the dungeon editor works fine, I'll release it.
In the mean time, join the forums. There's a bunch of stuff that's been released and discussed there, even though ZOLE hasn't been released. http://zeldahacking.ulmb.com/index.php
Sunday, June 27, 2010
Thursday, June 24, 2010
Great News
Well, this is going to be one of the last posts for a while, but you can still expect one more, and then I'll be posting again once I start my other tools. But I didn't post to give you bad news, I posted to give you great news!
I know I said this before, but ZOLE is almost ready for release now more than ever. With ASM scripts created and modified, several window bugs fixed, and many saving bugs fixed, ZOLE is now very stable and has had every bug found fixed (Thanks to Jigglysaint for being the primary beta tester). Now, it will not be released today, and maybe not even tomorrow, but when it does, you'll be glad you waited.
So what's to come? Well, the only thing I have left to add is a patch that basically kills all those little flags in the beginning of the game that removes music and the ability to press start/select. I'm not sure how I'll do it but I'm sure I'll figure out some way (Probably by either finding the flags in the memory and finding what modifies them or following the beginning events).
But until tomorrow, see ya later!
I know I said this before, but ZOLE is almost ready for release now more than ever. With ASM scripts created and modified, several window bugs fixed, and many saving bugs fixed, ZOLE is now very stable and has had every bug found fixed (Thanks to Jigglysaint for being the primary beta tester). Now, it will not be released today, and maybe not even tomorrow, but when it does, you'll be glad you waited.
So what's to come? Well, the only thing I have left to add is a patch that basically kills all those little flags in the beginning of the game that removes music and the ability to press start/select. I'm not sure how I'll do it but I'm sure I'll figure out some way (Probably by either finding the flags in the memory and finding what modifies them or following the beginning events).
But until tomorrow, see ya later!
Tuesday, June 22, 2010
Beta Testing Day And the Text Engine Cracked
That's right! ZOLE is now finished and ready for testing. This obviously means the Gale Seed Warp Editor is finished and I've applied some finishing touches. However, I only have a few people I want to test. There's 3 others and then myself.
But anyway, I've basically cracked the way text works (Actually, this was about 10 minutes ago). First off, it's a lot more easy to work with than I thought. If you look at the ROM in a hex editor, you'll see words scattered all over bank 1F, and some others. However, a closer look will reveal the true format.
You see, there are basically text types that help build up dialogue. Here they are.
00 - End of text
01 - Scroll
02 - Another reference type, except this one can use images (Maybe others can???)
03 - Reference to another word
04 - Another reference type
05 - Another reference type
Note these are all from trial and error.
When switching from a different type to regular text, nothing needs to be done. Since ASCII basically starts at 0x20 (Space), the game detects it's too high to be an opcode and just reads until there IS a type switch. The good news is, the game auto-wraps the text for us, but we still have to let it know when to scroll. Let's break down the man below the shop's dialogue.
7F97E - "So,"
7F981 - 03 Reference
7F982 - 7A (Inserts " what")
7F983 - "'s" So, what's
7F985 - 03 Reference
7F986 - 29 (Inserts " with")
7F987 - 03 Reference
7F988 - 54 (Inserts " this")
7F989 - "gloomy" So, what's with\nthis gloomy
7F98F - 01 Scroll
7F990 - "uncertainty,"
7F99C - 01 Scroll
7F99D - "anyway?" So, what's with\nthis gloomy\suncertainty\sanyway?
7F9A4 - 00 End
Wow, look at all that! But rest assured. I'm going to be making another tool which is to edit text (A text editor. We're catching up, Pokemon hacking!!!). If at any point you feel like I'm doing all the work while people hack for fun, don't, I love programming and finding data.
So, you may be asking yourself: "When will ZOLE be released?!". Well, when beta testing is over, which will probably be tomorrow. I'll make a post and link you to the forums. Note the forums currently use ULMB's free host, but depending on how well they go, I will pay and get a domain and such.
But until tomorrow, see ya later!
But anyway, I've basically cracked the way text works (Actually, this was about 10 minutes ago). First off, it's a lot more easy to work with than I thought. If you look at the ROM in a hex editor, you'll see words scattered all over bank 1F, and some others. However, a closer look will reveal the true format.
You see, there are basically text types that help build up dialogue. Here they are.
00 - End of text
01 - Scroll
02 - Another reference type, except this one can use images (Maybe others can???)
03 - Reference to another word
04 - Another reference type
05 - Another reference type
Note these are all from trial and error.
When switching from a different type to regular text, nothing needs to be done. Since ASCII basically starts at 0x20 (Space), the game detects it's too high to be an opcode and just reads until there IS a type switch. The good news is, the game auto-wraps the text for us, but we still have to let it know when to scroll. Let's break down the man below the shop's dialogue.
7F97E - "So,"
7F981 - 03 Reference
7F982 - 7A (Inserts " what")
7F983 - "'s" So, what's
7F985 - 03 Reference
7F986 - 29 (Inserts " with")
7F987 - 03 Reference
7F988 - 54 (Inserts " this")
7F989 - "gloomy" So, what's with\nthis gloomy
7F98F - 01 Scroll
7F990 - "uncertainty,"
7F99C - 01 Scroll
7F99D - "anyway?" So, what's with\nthis gloomy\suncertainty\sanyway?
7F9A4 - 00 End
Wow, look at all that! But rest assured. I'm going to be making another tool which is to edit text (A text editor. We're catching up, Pokemon hacking!!!). If at any point you feel like I'm doing all the work while people hack for fun, don't, I love programming and finding data.
So, you may be asking yourself: "When will ZOLE be released?!". Well, when beta testing is over, which will probably be tomorrow. I'll make a post and link you to the forums. Note the forums currently use ULMB's free host, but depending on how well they go, I will pay and get a domain and such.
But until tomorrow, see ya later!
Lots and Lots of New Stuff
Today's (late...) post is going to be semi-short but packed with lots of stuff. However, I'm extremely tired right now so there will be no screenshots.
For starts, an option to change the map's music has been added. It's a simple numeric text box below the Area Information group box.
A new window has been added to edit the dungeon portals. There is a numeric text box controlling the dungeon and two more for the linked maps.
Something I'm very happy about is the warp editor is now 100% finished and fully functional. This includes small indoor map exiting, which was a very simple fix. Shame I didn't get it earlier.
The next thing is a new window to choose the script a map gets (Basically setting the index of the script and the pointer the script points to). It works like chests where you can only search and swap, but there's plenty of maps to go around.
A small, yet useful feature, has been added to clear out enemy spawn groups. I personally hate to hex edit when working with a level editor as I have to reload the ROM, and since ZOLE doesn't support editing these groups, you can clear them out which leaves the space for other interactions.
Finally, a new patch has been added, which is (what really now makes Ages match with Seasons...) to make it so in Ages, you can go to the bounding maps so instead of the maps really being 14x14. This basically allows us to use several more maps for the overworld and less indoor ones.
The only remaining thing to be added in ZOLE before its first release is a Gale Seed Warp Editor. I have started this and found the Present warp data (Past most likely works the same way, I just haven't looked for it) but am too tired to continue. I wanted to make sure I got tonight's blog in because there's a lot I pushed in today. AND! That's not it. Aside from the level editor, I have created a forum and started writing up some tutorials, but no one will know about it until beta testing is done and it is released.
So, until tomorrow, see ya later!
For starts, an option to change the map's music has been added. It's a simple numeric text box below the Area Information group box.
A new window has been added to edit the dungeon portals. There is a numeric text box controlling the dungeon and two more for the linked maps.
Something I'm very happy about is the warp editor is now 100% finished and fully functional. This includes small indoor map exiting, which was a very simple fix. Shame I didn't get it earlier.
The next thing is a new window to choose the script a map gets (Basically setting the index of the script and the pointer the script points to). It works like chests where you can only search and swap, but there's plenty of maps to go around.
A small, yet useful feature, has been added to clear out enemy spawn groups. I personally hate to hex edit when working with a level editor as I have to reload the ROM, and since ZOLE doesn't support editing these groups, you can clear them out which leaves the space for other interactions.
Finally, a new patch has been added, which is (what really now makes Ages match with Seasons...) to make it so in Ages, you can go to the bounding maps so instead of the maps really being 14x14. This basically allows us to use several more maps for the overworld and less indoor ones.
The only remaining thing to be added in ZOLE before its first release is a Gale Seed Warp Editor. I have started this and found the Present warp data (Past most likely works the same way, I just haven't looked for it) but am too tired to continue. I wanted to make sure I got tonight's blog in because there's a lot I pushed in today. AND! That's not it. Aside from the level editor, I have created a forum and started writing up some tutorials, but no one will know about it until beta testing is done and it is released.
So, until tomorrow, see ya later!
Sunday, June 20, 2010
Soon Release, New Feature
Well, today's feature was a simple one but surely effective. It gets its own window and is titled "Arrange Rooms". Basically you can order the way dungeons are formed. This does not effect minimaps.
Oh, and that's Level 1 with a few hacked rooms with hacked graphics and palette to resemble Link's Awakening DX rooms. This just shows it works. Also, please ignore the "Map: 0" when it should be "Map: 10". I simply forgot to make it update the numeric box as soon as the window is opened. Other than that it's flawless.
So I've decided the only thing I'm sure of adding before the release is a Gale Seed warp editor, and some more patches. I really want to add a minimap editor since it's kind of important but data findings for it haven't been successful. But, like most editors, there will of course be another release of ZOLE sometime after the first, and more after that.
Until tomorrow, see ya later!
Oh, and that's Level 1 with a few hacked rooms with hacked graphics and palette to resemble Link's Awakening DX rooms. This just shows it works. Also, please ignore the "Map: 0" when it should be "Map: 10". I simply forgot to make it update the numeric box as soon as the window is opened. Other than that it's flawless.
So I've decided the only thing I'm sure of adding before the release is a Gale Seed warp editor, and some more patches. I really want to add a minimap editor since it's kind of important but data findings for it haven't been successful. But, like most editors, there will of course be another release of ZOLE sometime after the first, and more after that.
Until tomorrow, see ya later!
Saturday, June 19, 2010
Some Stuff
Well, today I've been mainly focusing on my new phone and setting everything up and making it all perfect took a while. But, when that was all done I picked up ZOLE and redid that VRAM decompressing system.
Right now, it works fine and I haven't noticed any other corrupted tilesets. However, I did struggle a bit while writing the ASM script because the unexpected interrupts were messing up the data the emulator was reading from. Although it took me a while to realize this was the reason tiles weren't showing up properly, a simple "di" and "ei" fixed it all.
But anyway, for some bad news (Well, we haven't had any bad news in a while, so it's time I give you some!), I'm afraid 'unique' and 'tileset' tiles won't be editable until a future release of ZOLE. The reason being is I forgot the compression also includes "destination" values for data, and the only way to really avoid it is to make the VRAM be completely raw and not load any other tiles, which would require an ASM hack and I'd have to redo some stuff in ZOLE I don't want to.
However, there is good news to that! I will try to add a feature that basically will clear the write data of the other tiles so only the VRAM shows, but honestly, it isn't very good for overworld tiles sets because nearly every (Or maybe even every) overworld room uses the same VRAM set. Although, that's not really a bad thing, since ZOLE will allow the exporting and important of raw graphics data so VRAM sets will be "copyable".
I still haven't gotten around to making the tileset editor, or even brainstormed about it, but since tilesets are compressed (If I remember correctly) I'm going to be making it like VRAM and decompress them and add a new ASM script(Although there yet again isn't enough space. This would require another MB for all tilesets to be decompressed).
I haven't heard any complaints about using and auto-applying custom ASM scripts, but if you're against it, leave a comment and I'll make them all optional (Except for the raw map loading). But if not, they'll be automatically added. But anyway, until tomorrow, see ya later!
Right now, it works fine and I haven't noticed any other corrupted tilesets. However, I did struggle a bit while writing the ASM script because the unexpected interrupts were messing up the data the emulator was reading from. Although it took me a while to realize this was the reason tiles weren't showing up properly, a simple "di" and "ei" fixed it all.
But anyway, for some bad news (Well, we haven't had any bad news in a while, so it's time I give you some!), I'm afraid 'unique' and 'tileset' tiles won't be editable until a future release of ZOLE. The reason being is I forgot the compression also includes "destination" values for data, and the only way to really avoid it is to make the VRAM be completely raw and not load any other tiles, which would require an ASM hack and I'd have to redo some stuff in ZOLE I don't want to.
However, there is good news to that! I will try to add a feature that basically will clear the write data of the other tiles so only the VRAM shows, but honestly, it isn't very good for overworld tiles sets because nearly every (Or maybe even every) overworld room uses the same VRAM set. Although, that's not really a bad thing, since ZOLE will allow the exporting and important of raw graphics data so VRAM sets will be "copyable".
I still haven't gotten around to making the tileset editor, or even brainstormed about it, but since tilesets are compressed (If I remember correctly) I'm going to be making it like VRAM and decompress them and add a new ASM script(Although there yet again isn't enough space. This would require another MB for all tilesets to be decompressed).
I haven't heard any complaints about using and auto-applying custom ASM scripts, but if you're against it, leave a comment and I'll make them all optional (Except for the raw map loading). But if not, they'll be automatically added. But anyway, until tomorrow, see ya later!
Friday, June 18, 2010
Nothing New, Again...
Well, today was a really busy day and I'm lucky I finally got time to post. But anyway, the only thing I did today relating to ZOLE was figure out I wasn't thinking properly yesterday and have to redo basically the whole decompressed tile system. No biggy though, I should have more time tomorrow. Until tomorrow, see ya later!
Thursday, June 17, 2010
Something Brief
Well, this isn't really an official post, but it's pretty cool so I thought I'd share it. Today has been a pretty busy day and it just going to get worse later so I wanted to make sure I got atleast SOMETHING in. But anyway, what I added today is pretty sweet. Basically, ZOLE can write the decompressed VRAM (base tileset) graphics and supports loading them raw. A custom ASM script is added to support loading completely uncompressed VRAM data, and it's pretty fun to mess with. The editor makes sure it writes to an address where the right 4 nybbles are unset so it appears fine in a tile editor (such as TLP) to edit. Here's something I made for testing.
So there's everything. Before the tiles were completely unrecognizable compressed. This feature isn't complete though, as I have to make it do the same for the unique and 'tileset' tiles. Then, I have to make the tileset configuration editable (Note all of these will require another ASM script to make things easier for the user and me), and finally something that will dump and import other tiles, mainly for swapping Ages and Seasons graphics, since I wanna add a Subrosia area in Ages instead of the ugly underwater (Gosh that was a long sentence). But anyway, just a heads up of what to expect in the next couple posts. See ya later!
So there's everything. Before the tiles were completely unrecognizable compressed. This feature isn't complete though, as I have to make it do the same for the unique and 'tileset' tiles. Then, I have to make the tileset configuration editable (Note all of these will require another ASM script to make things easier for the user and me), and finally something that will dump and import other tiles, mainly for swapping Ages and Seasons graphics, since I wanna add a Subrosia area in Ages instead of the ugly underwater (Gosh that was a long sentence). But anyway, just a heads up of what to expect in the next couple posts. See ya later!
Wednesday, June 16, 2010
New Features and a To-Do List
Alright! I know I've missed the last couple days, but I'm here to make it up. For starts, let me announce that ZOLE is nearing it's end (Hold on!). However, ZOLE is only the level editor I'm going to be making for the game. I'm looking into making another tool that you probably won't hear anything about for a while as I haven't done any research on yet. But before that, here's a list of what needs to be done before anyone should get excited (It may seem like a lot but some of the things aren't really that much to make).
-Minimap editor - I need to find the data for this.
-Gale seed spot editor - Already found the data.
-Dungeon room order editor - Already found the data, but I want to integrate it into the minimap editor.
-Graphics/tileset decompressor + repointer - This will require a small ASM hack. Not all tilesets will be able to be decompressed, as it will require over 1MB of space, so it's a choice.
-Text editor - I have no idea how text works. The text probably uses dictionary compression as around 0x60000 I believe you can find random words used in the same each starting (or ending?) with 00. Note this may not be added as it could use a totally different system than I'm thinking of.
-Dungeon name editor - Might have a little trouble with this. I've done a slim search and found nothing before.
-Dungeon portal editor - I know this gets grouped with interactions, but many people won't want to have to know ASM to edit half the simple things in the game.
-Small indoor exit warp editor - I know I said I was just going to include a tutorial, but a separate editor would just be easier for all of us.
-Full Seasons compatibility - This will not be added before the first release.
So that's the checklist. Now, I've added two things today. First thing, a palette editor. It allows the selection of any palette and then a preview of what the selected area would look like with it applied (Oh how this is useful). Here's what it looks like.
Ugh, what an ugly palette, but hey, it's just a demonstration. Right now, it only edits basically "uncompressed" palettes, which is every single palette used in tilesets except for 1 (It can still be edited just fine though). I don't want to explain what I mean by "uncompressed" so just read on.
The next thing I added is small but useful, a start editor. It really doesn't need a screenshot as it's a few labels and numeric boxes so I won't post one.
But that's all. Oh, and a heads up: I'm going to be making a forum specifically for Zelda hacking, since there doesn't seem to be one (Maybe just for the Oracles games, since I don't know half the Zelda games that are even out there nowadays). But until (hopefully!) tomorrow, see ya later!
-Minimap editor - I need to find the data for this.
-Gale seed spot editor - Already found the data.
-Dungeon room order editor - Already found the data, but I want to integrate it into the minimap editor.
-Graphics/tileset decompressor + repointer - This will require a small ASM hack. Not all tilesets will be able to be decompressed, as it will require over 1MB of space, so it's a choice.
-Text editor - I have no idea how text works. The text probably uses dictionary compression as around 0x60000 I believe you can find random words used in the same each starting (or ending?) with 00. Note this may not be added as it could use a totally different system than I'm thinking of.
-Dungeon name editor - Might have a little trouble with this. I've done a slim search and found nothing before.
-Dungeon portal editor - I know this gets grouped with interactions, but many people won't want to have to know ASM to edit half the simple things in the game.
-Small indoor exit warp editor - I know I said I was just going to include a tutorial, but a separate editor would just be easier for all of us.
-Full Seasons compatibility - This will not be added before the first release.
So that's the checklist. Now, I've added two things today. First thing, a palette editor. It allows the selection of any palette and then a preview of what the selected area would look like with it applied (Oh how this is useful). Here's what it looks like.
Ugh, what an ugly palette, but hey, it's just a demonstration. Right now, it only edits basically "uncompressed" palettes, which is every single palette used in tilesets except for 1 (It can still be edited just fine though). I don't want to explain what I mean by "uncompressed" so just read on.
The next thing I added is small but useful, a start editor. It really doesn't need a screenshot as it's a few labels and numeric boxes so I won't post one.
But that's all. Oh, and a heads up: I'm going to be making a forum specifically for Zelda hacking, since there doesn't seem to be one (Maybe just for the Oracles games, since I don't know half the Zelda games that are even out there nowadays). But until (hopefully!) tomorrow, see ya later!
Sunday, June 13, 2010
No Real News
Well, there isn't really any news today. I've been messing around with a program I'm making that lets two people play a game together (Like watching someone play a VBA game and then taking over by capturing the screen's buffer and sending it over and some other stuff). I've also been playing around with the editor recreating Zelda Link's Awakening's maps (Which is actually pretty fun) and I noticed that I have to figure more out about interactions, because I can't seem to get the ID for those little green blobs that pop out.
Oh well. Until tomorrow, see ya later!
Oh well. Until tomorrow, see ya later!
Saturday, June 12, 2010
One Down, X To Go!
A strange title, but the point I was getting at is another feature down and only so many more to go. The feature I'm talking about is the Chest Editor. Here's what it looks like.
A small, yet powerful window. You're probably thinking, "Oh my gosh, 65536 possible chest items?! How am I supposed to know what's what?!" Well, obviously you just find a map with the chest item you're looking for, swap data (or just copy the ID) and you're good.
But anyway, I've been thinking. Should I have a dungeon room order editor? In my opinion, this is extremely useless as all of the data is raw and will never be used by another room. I doubt anyone would find any use of it, so I'm thinking against it, but I want to get opinions first (This is not like ZLADE/ZLA where the maps are compressed and certain data is used over and over again).
So that's all for today's short post. Other than this I've been fixing bugs and messing around with debugging. Until tomorrow, bye!
A small, yet powerful window. You're probably thinking, "Oh my gosh, 65536 possible chest items?! How am I supposed to know what's what?!" Well, obviously you just find a map with the chest item you're looking for, swap data (or just copy the ID) and you're good.
But anyway, I've been thinking. Should I have a dungeon room order editor? In my opinion, this is extremely useless as all of the data is raw and will never be used by another room. I doubt anyone would find any use of it, so I'm thinking against it, but I want to get opinions first (This is not like ZLADE/ZLA where the maps are compressed and certain data is used over and over again).
So that's all for today's short post. Other than this I've been fixing bugs and messing around with debugging. Until tomorrow, bye!
Friday, June 11, 2010
More Data Findings, Map Scripts, and a New Feature
Well, I haven't worked on the editor today except for warp saving fixes, but I have found quite a few pieces of data.
For starts, let me introduce a new feature, patching. Basically, the editor will have a menu with categories of patches and things to add or remove. This is to basically decrease the knowledge needed to remove some of the annoying things that would kill hacking. Most of these patches (all so far) just change one byte. There will be no way to revert them back to normal.
So far, patching includes removing the random forest maps (That annoying game) and all possibilities of it. There is also one to change the map the gate to the Maku Tree is (However I will go on further about this). There will be many map patches, such as changing the animal and volcano town maps, but right now there are only two.
In other news, I've cracked how the Gale Seed Warping works. Actually, it's extremely efficient and just screams "HACK ME!". There are three straight-forward bytes per spot (Although the third one seems kind of useless), and room for about 3 or 4 extra warps at the end of the data (I've tested this and we can easily add or remove them).
The only thing I worry about is area editing, such as editing what makes the minimap say Cresent Island is Cresent Island, and there's a Scent Seed Tree there. I've found other unimportant things, such as the cursor offset, sprite, and palette, but I doubt anyone would care to edit those.
Back on the topic of patches, I want to get into the map changing, or what they're really called, map scripts (Like how the Maku Gate stays forever removed after being opened. This is, of course done by a flag somewhere in the 0xC000 bank, but I mean the other part of it). The way they're done is kind of similar to how interaction script locations are calculated. The CPO (Common pointer operation, which is where you have a base address, add the map group * 2, and calculate the pointer there) is done to address 0x124A7. The date here is in pairs of two. The game reads the first byte as the map. If the byte matches the map you're going in to (Like 48 if you're heading up from the Ring Shop), the next byte (Always read but only matters if the Z flag is set) is a reference to the next procedure (I'm going to call these scripts from now on).
The new script is calculated by taking the script reference byte and multiplying it by 2, adding it to 0x012437, and calculating the pointer there using bank 4.
For example purposes, the generated script address takes us to 0x12673. The only thing done here is a global flag check. The flag it checks is bit 2 of 0xC6D2, which is set if the Maku Gate has been opened. If you're wondering, here's how to find the address of the flag and the bit number. Basically, the upper 5 bits are the value to be added to the memory address and the lower 3 are the value added to 0x0000F8 to be read as the bit AND value.
Calculating Address Flag and Bit Number [C# Syntax]
byte value = 0x12; //This is the one used in the Maku Gate check
byte b = (byte)(((value & 0xF8) >> 3)); //0x2
int memoryAddress = 0xC6D0 + b; //C6D2
b = (byte)(value & 0x07); //2 byte
bit = ROMData[0xF8 + b]; //ROMData being the file buffer
Calculating Address Flag and Bit Checking Value [C# Syntax]
byte value;
int dMemoryAddress = 0xC6D2; //Let's make this as easy as possible
byte dBit = 0x2; //The bit to check
byte b = (byte)(dMemoryAddress - 0xC6D0);
byte final = (byte)((b << 3));
Not too bad, but they probably could've saved more space using two bytes instead of one and not performing the procedure. But anyway, that's how those map-specific entry events work. Pretty handy-dandy if you ask me, and it only makes hacking these games better. See you tomorrow!
For starts, let me introduce a new feature, patching. Basically, the editor will have a menu with categories of patches and things to add or remove. This is to basically decrease the knowledge needed to remove some of the annoying things that would kill hacking. Most of these patches (all so far) just change one byte. There will be no way to revert them back to normal.
So far, patching includes removing the random forest maps (That annoying game) and all possibilities of it. There is also one to change the map the gate to the Maku Tree is (However I will go on further about this). There will be many map patches, such as changing the animal and volcano town maps, but right now there are only two.
In other news, I've cracked how the Gale Seed Warping works. Actually, it's extremely efficient and just screams "HACK ME!". There are three straight-forward bytes per spot (Although the third one seems kind of useless), and room for about 3 or 4 extra warps at the end of the data (I've tested this and we can easily add or remove them).
The only thing I worry about is area editing, such as editing what makes the minimap say Cresent Island is Cresent Island, and there's a Scent Seed Tree there. I've found other unimportant things, such as the cursor offset, sprite, and palette, but I doubt anyone would care to edit those.
Back on the topic of patches, I want to get into the map changing, or what they're really called, map scripts (Like how the Maku Gate stays forever removed after being opened. This is, of course done by a flag somewhere in the 0xC000 bank, but I mean the other part of it). The way they're done is kind of similar to how interaction script locations are calculated. The CPO (Common pointer operation, which is where you have a base address, add the map group * 2, and calculate the pointer there) is done to address 0x124A7. The date here is in pairs of two. The game reads the first byte as the map. If the byte matches the map you're going in to (Like 48 if you're heading up from the Ring Shop), the next byte (Always read but only matters if the Z flag is set) is a reference to the next procedure (I'm going to call these scripts from now on).
The new script is calculated by taking the script reference byte and multiplying it by 2, adding it to 0x012437, and calculating the pointer there using bank 4.
For example purposes, the generated script address takes us to 0x12673. The only thing done here is a global flag check. The flag it checks is bit 2 of 0xC6D2, which is set if the Maku Gate has been opened. If you're wondering, here's how to find the address of the flag and the bit number. Basically, the upper 5 bits are the value to be added to the memory address and the lower 3 are the value added to 0x0000F8 to be read as the bit AND value.
Calculating Address Flag and Bit Number [C# Syntax]
byte value = 0x12; //This is the one used in the Maku Gate check
byte b = (byte)(((value & 0xF8) >> 3)); //0x2
int memoryAddress = 0xC6D0 + b; //C6D2
b = (byte)(value & 0x07); //2 byte
bit = ROMData[0xF8 + b]; //ROMData being the file buffer
Calculating Address Flag and Bit Checking Value [C# Syntax]
byte value;
int dMemoryAddress = 0xC6D2; //Let's make this as easy as possible
byte dBit = 0x2; //The bit to check
byte b = (byte)(dMemoryAddress - 0xC6D0);
byte final = (byte)((b << 3));
Not too bad, but they probably could've saved more space using two bytes instead of one and not performing the procedure. But anyway, that's how those map-specific entry events work. Pretty handy-dandy if you ask me, and it only makes hacking these games better. See you tomorrow!
Thursday, June 10, 2010
A LOT of Interaction Stuff
Well, once again I'm back to posting about interactions. Before I go on though, if you care, warps are now editable instead of just viewable. But anyway, I've been debugging stuff and trying to get more information on interactions. Many of my findings include that the "enemy spawn group" ID is actually a memory pointer (Bank 0x12) to more spawns. Opcode 7 isn't for tree seeds, but it's some sort of trigger that tells the game not to respawn the interactions the instant you walk into a room (A guess, however highly correct. If tree seeds and enemies both use it, obviously you know that they both don't respawn the instant you walk into a room. This is what I'm going to call it from now on).
I've also discovered a script editor shouldn't be needed for dungeons. There are already interactions that contain things such as "Open this hatch when there aren't any enemies". For example, a 02 interaction with the ID of 0xB1E would open up a right-pointed door once all enemies are defeated (Such as the one right of the first room in Level 1).
Warning: The following is very long and was written as I was debugging. Scroll down until you see more bold text to see something useful.
This next finding might not be right. However, I believe the script pointer for 02 interactions is calculated by taking the first byte (The lower byte of the 'ID'), multiplying it by 2, adding it to 0x3B8B, and calculating the pointer there using the set bank (See further for how this is calculated.).
Calculating Script Bank [C# Syntax]:
byte value = (byte)(id & 0xFF);
if (value < 0x3E) bank = 0x08;
else if (value < 0x67) bank = 0x09;
else if (value < 0x97) bank = 0x0A;
else if (value < 0xDC) bank = 0x0B;
else bank = 0x10;
The resulting address directly points to an ASM procedure, or script in our case. After thinking a bit, the game might not have its own script engine (Very possible. For example, the script can just load a pointer for a text pointer and then call another ASM procedure. Its own scripting language wouldn't help much. If I remember correctly, Pokemon Red used all ASM and CBM still did a great job with Brown). The parenthetical point I was trying to get at is you can think of it as a scripting language, but really it's most likely ASM with arguments (Heh... Aren't all scripting engines like that? What I mean is there probably isn't ASM that has script opcodes and works from there, like in Pokemon GSC).
[An hour later]
I've been able to get filled in even more. In the room to the right of the first room in Level 1 (I'll be talking about this room from now one), there is an object positioned in the top left that controls where and when to open the north door. Now, let's walk through the script calculated from the IDs (Or, script reference I guess).
The ID is 0x81E. 0x1E means a 0x08 bank, and after the pointer calculating is done, we're left off at 0x0206E4. 0x1E is commonly used and found in rooms with opening doors. But anyway, at that address is an ASM script calling 0x0026EC. I'm not exactly sure what this does, other than checks the first byte in the interaction's data. 01 is normal and 02 resets a sprite by setting 64 bytes starting at its base to 00.
So after that calling, another procedure is called at 0x0026E4. This procedure starts by checking what's at 0xCD00. This value is set according to the room scrolling going on. Bit 3 (0-based) is set if you're going room-to-room, bit 0 is set if the room transition is complete, and bit 7 is set if the room is scrolling regularly.
Back to the 0x26E4, the procedure checks if the room transition is complete or not, and if not, then return (This is why doors don't open if we've killed all enemies until we've finished going from room-to-room). The rest of the procedure isn't really important as long as we know that, so let's move on.
Truthfully I'm not sure what is at 0xCCDD, as it's always been 00 and I haven't been able to find a command that writes something other than constant 00, so let's ignore it for now. After the 02 check, the next lines check the value at 0x**44 (** being the current interaction), which from my understanding controls whether or not the interaction is enabled. The accumulator is set and a past version of the script is recalled and some other stuff is added (You can learn more about this by checking out the script at 0x000000).
Now we're at 0x0206FC. 01 is placed at 0x**44. The Y position of the interaction, or as it's used here, the Y location of the door to open, is copied over to 0x**7F. The same thing is done to the interaction's X position, except copied over to 0x**7E. After this, the absolute X is calculated (It's just the X <<>= 0x80, it continues on. If not, it returns. Upcoming is a check at 0x**46. If the value there is 00, the script continues at 0x002567. If not, the value at 0x**46 decreases by 1 and the procedure returns.
At 0x002567, the value at 0x**47 is read. If 00, the script continues at 0x002573. If not, the value is decreased and if not 00, procedure 0x00201D is called. The accumulator is then reset and the procedure returns.
Once again continuing (Gosh this is getting REALLY annoying, but I see a for-sure-to-reach return!) at 0x002573, the game reloads are second calculated script pointer (0x0206FE) and calls procedure 0x002518.
Here we find out that script pointer is really at 0x306FE, because of a bank switch from 0x08 to 0x0C. If the value there is not 00, we call the procedure at 0x30000.
OKAY! I've honestly had enough of that. The deep down ASM that we're never going to touch is unimportant.
Something Useful
So, for events like doors to work, The first byte of the type 02 interaction must be 0x1E. The other byte has to do with bit work. Bit 0 and 1 are the door direction (00 being down, etc). Bit 2 is a flag that's used for events (What kind, I'm not sure, but the room with the cube in Level 1 has it set), and bit 3 is set for when doors open when all enemies are killed (Or a block is pushed if there are no enemies). I have not messed with the other 4 bits yet though.
A Custom Door and Event
Here is something I tried in a test. It brings in three Stalfos, adds a new door to the bottom that automatically closes and opens up when you kill the enemies. It also proves the click-and-set editing feature and shows off the warp editor.
Watch the video: http://www.youtube.com/watch?v=8RNQkZ8HV1E
That's all for today's extremely long and boring post, but hey, I found out a lot and now hacking can be made even better. Until next time, see ya later!
I've also discovered a script editor shouldn't be needed for dungeons. There are already interactions that contain things such as "Open this hatch when there aren't any enemies". For example, a 02 interaction with the ID of 0xB1E would open up a right-pointed door once all enemies are defeated (Such as the one right of the first room in Level 1).
Warning: The following is very long and was written as I was debugging. Scroll down until you see more bold text to see something useful.
This next finding might not be right. However, I believe the script pointer for 02 interactions is calculated by taking the first byte (The lower byte of the 'ID'), multiplying it by 2, adding it to 0x3B8B, and calculating the pointer there using the set bank (See further for how this is calculated.).
Calculating Script Bank [C# Syntax]:
byte value = (byte)(id & 0xFF);
if (value < 0x3E) bank = 0x08;
else if (value < 0x67) bank = 0x09;
else if (value < 0x97) bank = 0x0A;
else if (value < 0xDC) bank = 0x0B;
else bank = 0x10;
The resulting address directly points to an ASM procedure, or script in our case. After thinking a bit, the game might not have its own script engine (Very possible. For example, the script can just load a pointer for a text pointer and then call another ASM procedure. Its own scripting language wouldn't help much. If I remember correctly, Pokemon Red used all ASM and CBM still did a great job with Brown). The parenthetical point I was trying to get at is you can think of it as a scripting language, but really it's most likely ASM with arguments (Heh... Aren't all scripting engines like that? What I mean is there probably isn't ASM that has script opcodes and works from there, like in Pokemon GSC).
[An hour later]
I've been able to get filled in even more. In the room to the right of the first room in Level 1 (I'll be talking about this room from now one), there is an object positioned in the top left that controls where and when to open the north door. Now, let's walk through the script calculated from the IDs (Or, script reference I guess).
The ID is 0x81E. 0x1E means a 0x08 bank, and after the pointer calculating is done, we're left off at 0x0206E4. 0x1E is commonly used and found in rooms with opening doors. But anyway, at that address is an ASM script calling 0x0026EC. I'm not exactly sure what this does, other than checks the first byte in the interaction's data. 01 is normal and 02 resets a sprite by setting 64 bytes starting at its base to 00.
So after that calling, another procedure is called at 0x0026E4. This procedure starts by checking what's at 0xCD00. This value is set according to the room scrolling going on. Bit 3 (0-based) is set if you're going room-to-room, bit 0 is set if the room transition is complete, and bit 7 is set if the room is scrolling regularly.
Back to the 0x26E4, the procedure checks if the room transition is complete or not, and if not, then return (This is why doors don't open if we've killed all enemies until we've finished going from room-to-room). The rest of the procedure isn't really important as long as we know that, so let's move on.
Truthfully I'm not sure what is at 0xCCDD, as it's always been 00 and I haven't been able to find a command that writes something other than constant 00, so let's ignore it for now. After the 02 check, the next lines check the value at 0x**44 (** being the current interaction), which from my understanding controls whether or not the interaction is enabled. The accumulator is set and a past version of the script is recalled and some other stuff is added (You can learn more about this by checking out the script at 0x000000).
Now we're at 0x0206FC. 01 is placed at 0x**44. The Y position of the interaction, or as it's used here, the Y location of the door to open, is copied over to 0x**7F. The same thing is done to the interaction's X position, except copied over to 0x**7E. After this, the absolute X is calculated (It's just the X <<>= 0x80, it continues on. If not, it returns. Upcoming is a check at 0x**46. If the value there is 00, the script continues at 0x002567. If not, the value at 0x**46 decreases by 1 and the procedure returns.
At 0x002567, the value at 0x**47 is read. If 00, the script continues at 0x002573. If not, the value is decreased and if not 00, procedure 0x00201D is called. The accumulator is then reset and the procedure returns.
Once again continuing (Gosh this is getting REALLY annoying, but I see a for-sure-to-reach return!) at 0x002573, the game reloads are second calculated script pointer (0x0206FE) and calls procedure 0x002518.
Here we find out that script pointer is really at 0x306FE, because of a bank switch from 0x08 to 0x0C. If the value there is not 00, we call the procedure at 0x30000.
OKAY! I've honestly had enough of that. The deep down ASM that we're never going to touch is unimportant.
Something Useful
So, for events like doors to work, The first byte of the type 02 interaction must be 0x1E. The other byte has to do with bit work. Bit 0 and 1 are the door direction (00 being down, etc). Bit 2 is a flag that's used for events (What kind, I'm not sure, but the room with the cube in Level 1 has it set), and bit 3 is set for when doors open when all enemies are killed (Or a block is pushed if there are no enemies). I have not messed with the other 4 bits yet though.
A Custom Door and Event
Here is something I tried in a test. It brings in three Stalfos, adds a new door to the bottom that automatically closes and opens up when you kill the enemies. It also proves the click-and-set editing feature and shows off the warp editor.
Watch the video: http://www.youtube.com/watch?v=8RNQkZ8HV1E
That's all for today's extremely long and boring post, but hey, I found out a lot and now hacking can be made even better. Until next time, see ya later!
Late News, but It's Good!
Well, this will be a short post (And sorry for it being late, but I was watching the Black Hawks get their well-earned Cup!) but I have good news. I've found more data that will only make hacking much better. For starts, the first thing I found is the starting stuff. This includes the map group, the map index, and your position. Next, just recently, I've found how music works. Luckily it's simply one uncompressed byte for each map and easy to access. This pretty much ends what I need to find, as I know how pretty much everything works (Although I would like to know what forces the game to not let you in the east and south bounding areas). I have not yet found the overworld minimap graphical or ordered data, but I'm sure it shouldn't be any trouble at all.
Some more things I have left to discover the data for are events (According to JS there is a scripting engine. I'm not sure if this is bad or not. Hopefully it shouldn't be too hard to crack!), how checks work, and some more stuff about interactions (Mainly what enemy groups spawn what and where). Note that the script editor (If I crack the scripting engine. However, I have a feeling I can as long as my debugging skills are good enough, since obviously interactions use it and I have their addresses) will not be implemented into the level editor, but made as a separate program for organization.
So that's all for discoveries and data findings. I got bored earlier today and killed some time and remade 20 of the LA maps (There is one mapping error in here I did not notice [A tree using the wrong corner], so ignore that). Oh, and these are actually playable as I made them using the level editor.
So that's all for today's. Tune in tomorrow for more updates!
Some more things I have left to discover the data for are events (According to JS there is a scripting engine. I'm not sure if this is bad or not. Hopefully it shouldn't be too hard to crack!), how checks work, and some more stuff about interactions (Mainly what enemy groups spawn what and where). Note that the script editor (If I crack the scripting engine. However, I have a feeling I can as long as my debugging skills are good enough, since obviously interactions use it and I have their addresses) will not be implemented into the level editor, but made as a separate program for organization.
So that's all for discoveries and data findings. I got bored earlier today and killed some time and remade 20 of the LA maps (There is one mapping error in here I did not notice [A tree using the wrong corner], so ignore that). Oh, and these are actually playable as I made them using the level editor.
So that's all for today's. Tune in tomorrow for more updates!
Tuesday, June 8, 2010
Aah, Sweet News at Last!
Sorry to keep you waiting, but I have something to post about! Don't worry, the project is still under development and I've gained even more knowledge on some things, like address that control the tile grass turns into after being chopped, or when to swap a room or tile with another. Basically things that can really only be done with an assembler and a hex editor.
So anyway, I've finished both stages of the warp editor (Currently STILL only a viewer, but not to worry, it will surely be able to edit when I stop slacking). This means we can see what maps have what warps, and exactly where those warps lead to. Here's a screenshot of the editing screens.
On the left is the normal, global room warp, middle is position-specific, and right is side-room. The ones below them are their windows for editing the secondary warp.
Other than warps, it is now possible to edit area properties (Including what area a map gets). I've also fixed an ASM bug with side room loading from warps, since they use groups 6 and 7 instead of 4 and 5, so they were loading improper pointers. But that's all good, and that concludes today's post. Thanks for staying with me so long and bearing my unexpected vacation. Until tomorrow, keep on trollin' (I wonder if BreakingNYC will start again now... Hmm...).
So anyway, I've finished both stages of the warp editor (Currently STILL only a viewer, but not to worry, it will surely be able to edit when I stop slacking). This means we can see what maps have what warps, and exactly where those warps lead to. Here's a screenshot of the editing screens.
On the left is the normal, global room warp, middle is position-specific, and right is side-room. The ones below them are their windows for editing the secondary warp.
Other than warps, it is now possible to edit area properties (Including what area a map gets). I've also fixed an ASM bug with side room loading from warps, since they use groups 6 and 7 instead of 4 and 5, so they were loading improper pointers. But that's all good, and that concludes today's post. Thanks for staying with me so long and bearing my unexpected vacation. Until tomorrow, keep on trollin' (I wonder if BreakingNYC will start again now... Hmm...).
Subscribe to:
Posts (Atom)