It Can’t Possibly Die!

Leave a reply

It’s been some time since we had our last chat, hasn’t it? We have so much catching up to do! We’ve both just been so busy, I guess we lost track of time! Where do we start?!

So yes, the press has been neglected as of late. I’m not going to try and pretend it hasn’t. But as usual, there is a reason. ZOHS’s popularity with me boomed because at the time I had no “real” projects (I put “real” in quotations because Zelda Oracles hacking will never be the priority it was in the past). Combine that with lots of free time to work on stuff and you’ve got some nice fluent development. But then I started learning C++ for real and beginning to understand its power and with that I was doing lots of research about dynamic mesh generation. One thing led to another and lately I’ve been working on a game instead of the suite.

However, that’s not to say ZOHS is being abandoned! I recently realized it’s okay to have multiple projects! In fact, it’s good! Multiple projects keep us from getting bored, while giving us the satisfaction of workflow. It also helps us better understand what we’re trying to do. With the lack of attention towards one specific thing and instead splitting it up, it allows us to step back and look at the bigger picture. When I started developing the suite, I just wanted a cleaner Zelda Oracles level editor that integrated all the external tools – the script editor, text editor, chest fixer, etc… while making editing tasks easier. Doing a better job programming things was a big priority.

But because I spent long periods away from it, I’ve had time to think about how things could be done better instead of regretting additions I’ve made along the road. A good example of this is the recent release of ZOHS beta 0.05. One of the coolest beta releases in a long time in my opinion, this release marked a huge point in this project’s development. While casual users might just look at it and think it only adds a hex editor and list downloading, it has done much more.

What took so long with it was migrating the map editor to use the plugin system. It’s not loaded externally (yet?), but all of the map editor’s code, GUI and functionality included, is its separate class that uses the plugin API. Before, all of this code was thrown in the main form’s code and stuff was beginning to get really cluttered, like ZOLE 4′s code. But this migration allowed me to keep it as clean as if it was running on ZOLE 5, the 100% plugin-based shell, but with the power and simplicity of ZOLE 4. This is exactly what the ZOLE 6 should be.

Working on the project in tiny bits and pieces has allowed me to add some neat features, make simple design tweaks that have large impacts on development, and fix bugs that would’ve been tough to find. An example of the latest feature is there is an option to draw the tile(s) you’re about to place instead of just a white box. This simple addition is going to make huge changes, because now you can (A) preview what your change will look like before messing with the map and (B) know what tile(s) you’re about to place. Let’s, for a moment, pretend there won’t be a history feature (undo/redo) [I believe this is going to wait until the networking update, because it will probably follow the same system to allow undoing/redoing ALL tasks]. For the clipboard, you currently have to have “Clipboard” checked in order to place its tiles instead of the regular tileset’s tiles. Perhaps you’ve made big changes to the map and haven’t saved and have a lot of tiles on the clipboard selected, but you want to place one tile from the tileset. Uh oh, you forgot to untick “Clipboard” and already placed the tiles, and you haven’t saved your work! Now you have to start over! But wait, that isn’t likely to happen anymore because you can visually see you’re still using the clipboard without looking at it! Of course, this option is completely customizable. The opacity of the tiles you’re about to place can be 0% (off), 25%, 50%, 75%, and 100% (fully opaque). Here’s what it looks like:

The design tweaks I was talking about are simple changes that make editing easier. One example is right-clicking when dragging to place a line causes the line to be removed, in case you want to get rid of or redo the line.

So all in all, releases may be spaced far apart, but good things are happening to the suite. Progress is always going to be slow, but I don’t think it’s a project that will die. After all of the core elements, progress will probably pick up and it will soon make ZOLE 4 obsolete. I am looking forward to it.

~Lin

Progress!

Leave a reply

It’s been a few days since I last posted, mostly due to Thanksgiving and some school stuff. But I have been working on the suite and it’s quickly becoming massively better than ZOLE, and many other editors in general.

I recently posted a video showing off some of the things I’ve added to the suite and how it’s slowly becoming more of a suite, but I’m starting to wish I waited because I’ve made some design overhauls and added an awesome, highly-requested feature. One of the biggest issues with ZOLE 4 was it was completely number-based and didn’t have any lists, mainly because I didn’t want to hardcode anything in case things changed. However, this is no longer an issue. Not only does the suite still launch with just the single executable file (something I’m trying to keep so it’s easy to distribute), but it also loads lists automatically (unless this is toggled off in the settings file). It does this by checking if the lists exist and if not, it downloads it from the list directory specified in the settings file. By default, this is http://www.zeldahacking.net/downloads/zohs/lists/ and if you go there, you’ll actually see I created a sounds file that populates the music editing box using the lists that a couple other people and myself had created. If you’re curious, here is the source code. All you have to specify the name of the list, such as “sounds” and it tries to download “sounds.ini” from the directory specified. It then goes ahead and fills in empty spaces with the hexadecimal indexes so it’s like a numeric box.

So that’s pretty cool. I’ve also been tidying up the editor and reworking the editor to use the API and sort of move towards a final and flexible design. Here’s a screenshot that also shows off the downloaded list:

ZOHS 0.05 Preview

There are a couple of things you’ll notice. First off, the tileset is on the right and the clipboard is below it (and also much bigger than the old one). I’ll explain why in just a moment. The second thing you’ll notice is there are tabs on the left that contain the original stuff on the left and the hex editor. The reason I have these both is to sort how I want to handle the different editing parts. On the left, you have tools that don’t manipulate the map or rely on the user’s input with it. Obviously the hex editor isn’t going to draw anything on the map, so it makes sense to separate it from the right – which contains editors that do. I haven’t finished migrating the original code to use the new editing component system (which is shown off in the video if you’re curious). To clean things up even more, I’m going to be implementing a similar editing component that handles the current things on the left. The third thing you’ll notice is there is some extra space on the paint image, which will be used to allow placing the vertical and horizontal grass tiles, and also maybe having a flower tile between them that will make the generation code alternate between them to make things more interesting.

There is an issue with this system though. If a user changes the area ID, the map editing component (which isn’t known or accessible through the main form until a ROM is opened) won’t know it has to redraw the tileset and map. The only thing I can think of is to have a method handled in the right editors that is called from the left editors to do things like update the tileset, other graphics, etc. I’ll have to try things out and see what works, because if it’s too flexible I’ll end up with another ZOLE 5 and that’s the last thing I want.

So that’s all for this post. Great things are happening to the suite that are quickly making it fulfill mine and others’ editing needs. Until next time, take care!

Plans for the API and Macros

Leave a reply

One of ZOLE 4′s biggest downfalls for users was everything had to be inputted numerically – interactions, chests, warps – and I think that’s a big reason hacking the games never took off. Despite there being tutorials and lists, users were often left in the dark when it came to editing until testing.

So how do we fix this? The entire reason ZOLE 4 didn’t display NPCs for some interactions is because it would require hardcoding. Interaction is just a fancy, wrongly-defined word for variable-passable assembly pointers that I came up with when ZOLE 4 was in its super early stages way back in May of 2010:

Some might call them sprites, some events, and others NPCs. Interactions is a word I chose to sum up both.

The solution is to implement a macro system. They will consist of code acting as templates for things like warps and have support for creating images for specific interactions, making them renderable and easily editable on the map. This would avoid hardcoding how these sorts of things are handled in the editor, while making it easy for the editor to use (and expand upon!).

I’m not entirely sure how to handle the macro system. What comes to mind is making them a part of the API and defining specific macro types – ones that set stuff in the ROM and ones that make visual things appear. This might be really difficult to use though, so if things don’t work out well I might end up creating what would be macros inside of the suite.

So it all comes down to the API. What is it? Why do I need it? Most of ZOLE 4′s tools shared a very similar format – have a window, specify the map group and index, and display some numerical data to be edited. This could all be generated automatically and use macros or editor-specific code to handle how the editor works. Plus when I implemented networking into the suite, the API will take care of what the editor controls what packets get sent practically automatically – no more need to implement features twice.

The API would mostly consist of all the ROM-loading stuff. For example, it would contain classes to load and display maps, or load interactions, etc. I’m thinking I’ll create a template editor to create the numerical editor things, maybe, and have an abstract function that draws and handles editing on the map.

If things don’t go well, I’m going to scrap a majority of the API and just write the suite normally. ZOLE 5 tried this approach and made it so broad that it wouldn’t even work. I’d really hate for that to happen to ZOLE 6, AKA the Zelda Oracles Hacking Suite.

Beta 0.04 Happened

Leave a reply

Yesterday, for the first time in months, I actually released something. But despite all that time I’ve had to learn from my mistakes of the past, I messed up just as bad. The new beta release contained all of the assembly patches for Ages that will allow ZOHS to edit graphics and maps, which seemed to work great upon releasing. It turns out, though, that I didn’t test map swapping. For loading maps I was using CC2D as the group, which turned out to break swapped maps. The real address I should’ve been using was CD24, AKA the area’s “unknown” value in ZOLE 4. This value is actually the area’s map group, which is almost identical to the real map group. Instead of it going Present Overworld, Past Overworld, Present Underwater, and Past Underwater, it’s Present Overworld, Present Underwater, Past Overworld, Past Underwater. Why is this? I don’t know. Maybe the developers wanted setting bit 0 to trigger a map-change event that’s grabbed from the next group.

Long story short, I released ZOHS Beta 0.04 before testing map swapping even though I knew it I shouldn’t have. I guess eagerness to get something out strongly overpowered patience. Not even 10 minutes later did I fix the bug and re-upload the beta version.

In other news, I’m trying to think of ways to revive the Primary Zelda Hacking community. With most of its core people gone, it’s tough to build it up. I have beta releases, but they’re so people can find bugs to squash early on. Not many people are going to want to use it over ZOLE until it can do everything ZOLE can and more. ZOHS isn’t going to take off until I at least get the scripting engine done, so that’s one of my goals for at least 0.06 or 0.07. Beta 0.05 is going to consist of a lot of code rewriting and organizing to allow a smooth creation of the API that’s going to be used for most of the mini editors inside the suite. The problem is ZOHS is using a lot of ZOLE 4′s code, especially with map loading. The only new hacking-related code is the graphics loader, which was taken from ZOLE 5. The suite, for the most part, has just been a pretty interface that brings it all together.

This post is getting really long, so I’ll save describing the API and macros in another post. I believe they’re the biggest things to implement at this point and once done, the suite’s progress will fly and quickly become superior compared to ZOLE 4.

Welcome to the Primary Zelda Hacking Press!

Leave a reply

This part of the Primary Zelda Hacking website will be dedicated to posting news regarding tools, documentation, hacks, and of course the website itself. Of course, everything will still be posted on the forums but this is primarily to organize everything and have it be easily viewed.

That said, since there isn’t a whole lot going on in the hacking scene right now, this part of the site will consist almost entirely of progress on the upcoming Zelda Oracles Hacking Suite – a utility meant to replace ZOLE 4 and all of its counterparts. This includes new features, new systems, code changes, demonstrations, and to-do lists. You can still download all of the beta versions here and when the program reaches a more stable version, the source code.

This website is supposed to act as a copy of the really old blog before the forums rolled around. It acted as an outlet for me, Lin, and I don’t want to flood the forums with my emotional connection between Oracles hacking and the nostalgia behind ZOLE. I hope you all enjoy reading as I will writing, and happy hacking!

~Lin