ZOLE Released and a 'New' Site

Well, I know it's been a long time, and I'm sorry, but this post is really late. The moment we've all been waiting for for nearly 2 months (Since the news of ZOLE. I know many people have been waiting years...) has finally come... I released ZOLE quite some time ago, but I forgot about the blog and have been EXTREMELY busy figuring stuff out, fixing bugs, and trying to help everybody out. I've also created two new tools not shown here, and I'm sorry for anyone who follows this blog and doesn't know about them.

But anyway, every tool, tutorial, list, and discussion about the games is now at the forum: http://zeldahacking.ulmb.com/index.php

You'll find two new tools there, which include something to fix chests and a buggy piece of crap text editor (Although others disagree). Here's what it looks like:


So ya, pretty nice in its own right. So be sure to check out the forums.

Honestly, I'm really gonna miss posting here. It was something I looked forward to every night when figuring out and adding those things to ZOLE. But, things change and they're all for the better. I've still got lots to explore and who knows, I might post again. It's really sad to see the end of it though... *sigh* But be sure to check back here some time in the future! You never know what to expect!

If you care about ZOLE and want to help me out, do me a huge favor by advertising the forums and spread the word of ZOLE to everybody you know! The more people hacking the games means the more people discover stuff, and the more people discover stuff, the less I have to do and the better hacks get, and the more popular Zelda Oracles hacking gets, the more hacks we have to play. It's a simple thought but when done can bring massive changes.

But thanks for reading today's, and last for a while, post on ZOLE. Thanks everybody for following, and I hope you have as much fun hacking as I did making the program. So until a day to yet come, see ya later!

About The Wait

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

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!

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...).

Just a Heads Up

Well, I decided I'm going to take a break and not really work on project til mid next week. Sorry for the inconvenience, but I just don't want to work on it until school's out.

Another No-News Post

Nothing has happened today. I learned some new stuff that will advance the editor in the future, but I haven't touched one piece of code. Tomorrow being Friday, I will be able to get work done without the trouble of school. Sorry for the short post, but like I said, I wanted to get one every day.

See you tomorrow!

A Bunch of Things

Well, I've finished up pretty much everything on interactions, and now it's time to finish warps. For a full list, you can add new interactions, delete existing ones, or delete the whole map's interactions altogether.

But now some bad news. Jigglysaint, the pioneer of these games, has informed me interactions have different events based on the maps you're on, which is not good for hacking. However, it's not really time to worry. I haven't debugged anything passed basic loading in the overworld, so hopefully I'll figure it out soon.

I spent a bit of time trying to find chest data today, but it was worthless as I couldn't even find it in the memory (This is how I discover the majority of things I find). I also found out even if maps had walkable tiles connecting to the right and bottom edge of the map, you couldn't access them, as the game doesn't even let you exit the other map.

One last thing I want to cover is with this editor, I want to include a graphics and tileset editor. I'm going to most-likely have to once again add an ASM hack, but this is to allow bank indexes to be used, since the uncompressed graphics would be going in the new ROM space. I'm sorry if the fact that there are going to be several ASM hacks in the end, but this just makes the editor more powerful and editing much easier.

So that's all I wanted to cover. School is finally dieing down as I'm taking my finals soon, so once I'm on break there will likely be heavy updates daily. See you tomorrow!

Keeping You Posted On...

Nothing! Today, nothing got added to the editor. The IDE wasn't even opened, and the project wasn't even executed. I've had a long day and it's only going to get more stressful this week. However, next week starting Thursday I will be out of school for the summer (I'm currently in 9th grade if you're wondering). Anyways, see you tomorrow!

Interaction Adding And Removing

Well, this is a small update, but not much work was done on the editor today. I decided to take a break as this is my last full week of school, and as you can imagine, it's stressful. However, the editor now has the capability to add or remove interactions to a map, as there is plenty of space at the end of the bank. The next update will include full warp editing, so wait for tomorrow for the update on it.

Holy Crap! For Real?!

Yep! You heard it here! Click-and-set editing now works for every single map. This means we can now customize hacks to the fullest without a single worry of needing space (*Offer does not apply to interactions and warps. See inside for de... oops!). There are current 3 ASM scripts being written. I have basically kicked out compressed dungeon loading since the game originally did not support fully uncompressed dungeon data. Here's the 2 major scripts (The other one is a modification of an existing one to call one of the scripts).

ROM0:3EF8 D5 push de
ROM0:3EF9 E5 push hl
ROM0:3EFA C5 push bc
ROM0:3EFB 3E 54 ld a,54
ROM0:3EFD EA 22 22 ld (2222),a
ROM0:3F00 21 00 40 ld hl,4000
ROM0:3F03 FA 2D CC ld a,(cc2d)
ROM0:3F06 DF rst 18
ROM0:3F07 2A ldi a,(hl)
ROM0:3F08 66 ld h,(hl)
ROM0:3F09 6F ld l,a
ROM0:3F0A FA 30 CC ld a,(cc30)
ROM0:3F0D 06 00 ld b,00
ROM0:3F0F 4F ld c,a
ROM0:3F10 09 add hl,bc
ROM0:3F11 7E ld a,(hl)
ROM0:3F12 C1 pop bc
ROM0:3F13 E1 pop hl
ROM0:3F14 D1 pop de
ROM0:3F15 5F ld e,a
ROM0:3F16 AF xor a
ROM0:3F17 7C ld a,h
ROM0:3F18 E6 80 and a,80
ROM0:3F1A C8 ret z
ROM0:3F1B 7C ld a,h
ROM0:3F1C D6 40 sub a,40
ROM0:3F1E 67 ld h,a
ROM0:3F1F AF xor a

ROM0:3949 11 00 CF ld de,cf00
ROM0:394C 2A ldi a,(hl)
ROM0:394D 12 ld (de),a
ROM0:394E 1C inc e
ROM0:394F 7B ld a,e
ROM0:3950 FE FF cp a,ff
ROM0:3952 C8 ret z
ROM0:3953 C3 4C 39 jp 394c ;I'm aware this could have been jr, but space was not an issue and BGB doesn't assemble it the way I want it to

So nothing to particular interest, but I thought maybe someone would like to see it. Here's some proof of the dungeon editing:



As usual, thanks for reading and hope to see you tomorrow!

Click-And-Set Overworld Editing

That's right! I've implemented click-and-set overworld editing. After going through a crap load of trial and error to get it all right, the editor now expands the ROM, decompresses all overworld (Small, actually) maps, and makes the maps ready to edit.

However, it wasn't just that simple. I had (Sorry, but it had to be done) to make a custom ASM script and change the way it gets the level data address. Basically, now it writes the bank of where the map data starts, since a region carries over to another bank. The only other thing I have to point out is the editor isn't very efficient with the 64 banks added. Each region gets 2 banks for map data, and there are 2 banks dedicated to map addressing. But, don't worry! You don't have to do anything. The editor will automatically expand the ROM, fix the header, and insert the ASM script.

Here's a test edit.


So as you can see, everything works great. You just click a tile and click where you want it on the map and it appears just like you want it to. Up next I'm working on dungeons. Let's hope they're not too much of a pain!

The News That Will Spice This Editor Up

Well I'm so excited I can hardly type up this post. After giving it some real thought, I realized I could give the editor click-and-set editing! This means no more worrying about compression! However, due to space problems, the ROM will be forced to be expanded up to 2MB, which is adding 64 banks. However, this is way more than needed. The dungeons, which need 176 bytes per room, need 176 * 512 = 90112 (0x16000) bytes, which is only 5 1/2 banks (Excluding some stuff). The rest of the rooms, which need 80 * 1024 = 81920 (0x14000) bytes, which is only 5 banks (Again, excluding some stuff. Don't worry, it's nothing major). This leaves up 54 banks to do what we please.

Sorry, but ROM expansion WILL be forced and applied as soon as you open your ROM, along with the decompression and repointing of each room. It's not like this is a bad thing. It's much better than being stuck with compressed rooms. And besides, dungeons were barely editable the way they are compressed anyway.

So hopefully you're just as excited about this news bit as I am, because this will make hacks 100 times better in the future. Thanks for reading and expect another post tomorrow!

The Final Post On Warps

Well, after about checking this out for maybe 5 hours (You have to keep note that I tend to slack off... a lot...), I've grasped the way side rooms work. The first byte is unchangeable, but doesn't effect how we edit warps. Infact, I don't see its use. Anyhow, the second byte is the source map. There is no source group (I will be calling this region after this post) because side room use virtual group 6 (Note: There is no real group. This saves about 2 bytes in terms of instructions without using bit 5,a). The third byte is a reference to the warp data, like other warps, and the last byte is the same nybble-encoded byte (Will be explained below).

The reference byte (03) refers to data as follows. The first byte is the real destination map, the second byte is the destination location (I still keep my warp-tile theory as it HAS been seen), and the last byte controls the room-enter type. For example, 03 is facing up, 04 is facing right, 05 is falling from above, etc...

Now the last byte is nybble-encoded. The first nybble controls the destination group (region), whereas the second nybble controls how you enter the warp (Or exit the room rather). For example, 03 (If I remember correctly), is a straight-forward switch to the map. 04 will move you up a little bit as if climbing up a ladder.

So my plans and previous interpretations were incorrect. The warp editor will have its second phase started Saturday, May 15th (Some may call it tomorrow, others today, as it's currently 4:54AM here) and hopefully started then too. Thanks for reading and stay tuned for more updates!

Warps - Yes, More About Them!

Good news everyone! I've completely cracked the data format for warps, and found out why rooms with working stairs in dungeons don't have real warp data. You see, to save space (And let's thank Capcom for this wonderful space-saving yet hack-friendly method), dungeon rooms without warp data will take whatever the room you're in and the position of the warping tile and add or subtract 64 (Depending on the tile. For example, if it's a staircase leading up, it will add 64) from the current room. This is great because hackers won't have to worry about space, and if they DO want to make the staircase lead somewhere special, a simple warp can be added.

Side rooms seem to be different, though. They use a separate loading procedure, which means their format is different. However, its format was how I predicted. The data only contains the 4 bytes. One byte is for... well, it seems to have something to do with data at 0xF8, another for the warp-containing map group (With some special formatting, that I'll leave up to the user to figure out. Trial and error is small price to pay, as it's pretty simple), one for the destined map, and then finally a nybble-based byte controlling the destination group and entrance type. So you may be wondering: How does the game know where to place you? Well, to save about 20 bytes total of space (Damn Capcom...), it loops through the level data until it finds a stair tile (Regardless of the direction). If it can't find one, it finds an entrance. If it can't find one of those, well, I haven't gotten there yet, but I'd imagine it finds some other warp spot.

So this blog was kind of crowded. All-in-all, I've figured out warps completely and should start, if not finish, the warp editor by tonight.

Brainstorm, Brainstorm, Brainstorm!

There hasn't been much progress recently, as I've been unsure on how to make a warp editor. As the warps aren't exactly the prettiest thing, it's hard to make a flexible editor that's easy to use. However, thinking about it has gotten the main idea done. You can see in the screenshot here what the main window looks like.



It's not done, but you get the idea. The "Follow and Edit Warp" button will open another window containing the real warp properties, as it would be too crowded and terrible in the same window.

All in all, there's not much to blog about today. Stay tuned until tomorrow to see progress, and expect it done by this Monday as the weekend is coming up!

Warps and More About Interactions

Well, today's update is mainly about warping. But before I get on about warps, I'll be talking about interactions.

Continuing from my progress yesterday, I've finished everything I need for interaction loading. The editor has the ability to edit existing interactions, but you current cannot re-point, add, or delete any. With the aid of a hex editor, I was able to learn more about certain interactions. It turns out, tree seeds depend on tile 34.



The unknown values to seem to be a constant 00 on trees, but since the interaction type is used for the growing grass that spawn seeds, they might control those.

Anywho, I've cracked the format of warps (Has only been testing on overworld maps). Needless to say, the format is just as bad as everything else in the game. Compressed? Almost. However, the ability to on-screen edit them won't be added. Instead, a separate window called a Warp Editor will be. You see, there are 3 types of warps. One type consists of a plain warp point for every warping tile in the room to use. This is why you'll notice using a walk-through-walls code and entering, say, a chimney will take you to the same spot as a door (in some case). On the other hand, there's another type that's a waste of space, yet Capcom insisted on using it. The type starts by defining the current map of the warp. Then there is a pointer that points to a set of data controlling the position the warp point is at, followed by the destined map group, location, and map. Sadly, instead of using pointers for every map, the game must loop through every warp until it finds one matching the current map's properties.

So you may be thinking warps will be a pain to edit. But, like everything else, my editor will deal with them easily. It's just one less feature (on-screen editing) the editor will have, but really just make editing take one more step.

ZOLE - Interaction Loading and a Boost to the Current Stage

Welcome to the first post on my blog. Obviously, this site is primarily directed to (GB/C) Zelda hacking. My current project is a Zelda Oracles (Current vaguely working for Seasons) level editor.

Anywho, level viewing is perfect. It currently loads dungeons (big rooms) and overworld maps (small rooms). There is no saving, but like every other tool, viewing always comes first!

So I finished interaction loading a bit ago. Some might call them sprites, some events, and others NPCs. Interactions is a word I chose to sum up both. Here's some screenshots of what they look like in the rooms.

View the Screenshot (Big Image)
You can view a screenshot showing only 4/16 types of interactions. You might be wondering why they're simple colors, but the opcodes are actually a partial pointer pointing to code in the same bank ($12), which may be followed furthermore. Because actually recreating a Z80 emulator in C# would be out of the picture, the editor just shows the sprites as blocks to show you they're there (These are the 8x8 blocks). The 16x16 blocks actually draw at the position they would appear in-game, as the sprite data contains a position.

This may all seem complicated at first, but you'll see how wonderful this engine is for hacking. We can add trees anywhere, our own dungeon warp points, enemies wherever we want, portals, bosses, events, switches, and many more without a big hassle. For example, here's a small hack I did placing Twin Rova in a regular overworld map.



Flexible enough? To top things off with of good news, sprite sets are nonexistent! This means we can throw whatever we want on any map.

The only real bad news about this game is the compression. The graphics and tileset assembling data is compressed beyond the ability to edit. The level data compression is compressed, but good enough to edit it. Repointing is rather out of the picture (sadly), as the small room's compression type also effects the pointer, but a future feature I will add will allow you to swap rooms to get what you want in a room where you want it. Editing won't be a dream, but flexible enough to make a good hack.

A long post, but you're informed of the project. I hope you readers visit my blog often and catch up on most-likely daily filler info!