Text Editors for TLoZ Oracle of Ages & Seasons (GBC) & Minish Cap (GBA)?

[Greyfield]

Hi all,

I'm looking to make a few personal text/script edits to my copies of TLoZ Oracle of Ages (GBC), Oracle of Seasons (GBC), and Minish Cap (GBA).  Do you all have any suggestions for tools or utilities to do that?  Apologies if this post would be better suited for the Script/Translation section.

For edits I've made to other Zelda games, I've either been able to do it directly (e.g., using a text table) or editors (e.g., LALE or Hyrule Magic), but haven't been able to find text/script editors that work for me for those three games.  Note that I tried to use Lin's ZOLE / ZOTE editor for Oracle of Ages, but the text appears as gibberish, and Minish Maker only currently seems to support level editing.

Any suggestions you have are appreciated!  Many thanks.

[Drenn]

There is an "easy" way to edit text in the oracle games. It's easy to do once set up, but the setup can be complicated.

Basically, I've made a disassembly for oracle of ages/seasons allowing anything to be modified by hand. You would edit the text files from my disassembly with a text editor, and then re-compile the game (example: https://github.com/Drenn1/oracles-disasm/blob/master/text/ages/text.yaml)

ZOLE/ZOTE/etc are "deprecated" tools, I'm replacing them with the disassembly and a new level editor for maximum flexibility.

Setup instructions for the disassembly can be found here: https://wiki.zeldahacking.net/oracle/Setting_up_oracles-disasm

See my signature for a link to a discord where we can help you a bit more. I don't know much about Minish Cap, but you seem to have found Minish Maker already, so you should be able to find a link to its respective discord channel as well, where you will find the most knowledgable people on that.

[josepbenz]

interest too

[Greyfield]

Drenn,

Thanks for posting this.  I'm unfamiliar with Ubuntu, so I'll have to get my sea legs, but it seems relatively straightforward.

As far as editing the text goes, I know with some editors you had to make sure not to go make the each dialog any longer than it was already because it could potentially overwrite the next.  Are there any restrictions like that with a disassembly either in terms of individual dialogs or the total dialog length?  I imagine a small portion of the dialogs would be a word or two longer or shorter depending on how I changed things, but I don't imagine the total number of lines per dialog changing, if that makes sense

Two other hopefully quick questions.  Do you happen to know the character limit per line in Oracles?  If I remember correctly in Link's awakening, it was 16 characters per line.  Finally, since I'm unfamiliar with how the disassembly works in terms of making a new ROM, how compatible would a reassembled Oracles ROM be with some of the existing patches out there?  I currently run Oracles with your VWF, the forced GBA mode, and your color restoration patches.

Thanks again!

[FAST6191]

Depends upon the disassembly, assembler and what you did in the meantime. The basic ROM hack for a non filesystem (so anything older than the DS that did not come on a floppy disc or optical media, give or take some homebrew efforts) game will tend to start from the assumption that the basic ROM layout is the same. One wherein you assemble the whole ROM from some kind of source code (be it leaked or fan recreated) could well radically alter things and not have it be anywhere near as annoying as doing that is for a baseline ROM as a hack. Indeed I would tend to assume it was going to be different until proven otherwise -- making a more matching one then probably wanting to match assembler handling (be it by recreating it or finding and making whatever Nintendo used all those years ago run on what you have available to you), build scripts and whatever else Nintendo used back when ( https://www.pagetable.com/?p=28&cpage=1 is somewhat related at this point, even if only as an example of what might be in store for that one and I am not sure if such things have been included in any of the gigaleaks or similar).

If you are playing with a disassembly forcing it into GBA mode is nothing too drastic -- there will be a little check during early run of the game and going from there. You can then recreate such a thing, or indeed dodge it entirely if you so desire. Colour restoration in that is also nothing too troubling -- if memory serves the same thing that also did the "is on GBA" is also the thing that tells it if so then also put these brightened/washed out palettes on there because this first gen unlit GBA screen is so dark (it being several years before the SP, never mind the GB player or SP 101, was even a glint in Nintendo's eye at this point). https://bgb.bircd.org/pandocs.htm#cgbregisters has how GBA detection works.

Character per line limit, assuming you don't care to make it larger, is something you can generally find your yourself once you have the text -- new lines will either be handled by pointers, some kind of autowrap (unlikely on a GB/GBC but not impossible) or some kind of value within the text itself (windows typically using 0d0A, unix tending to be 0a, hence the option you might be given in various editors or windows notepad not necessarily always displaying new lines in ASCII art and whatnot). Pointers (which will come back up in a second) might take a bit more effort but if you have found the text (relative search, tracing, corruption, grabbing text from RAM and back searching for it, compression searching... it matters not, just that you have it) and thus have enough to start making a table you can then doodle on.
Alternatively if it is not a variable width font you can usually figure out how many pixels it assigns to characters, the general borders of the thing and then use an image editor if you wanted to multiply it out.

"As far as editing the text goes, I know with some editors you had to make sure not to go make the each dialog any longer than it was already because it could potentially overwrite the next.  Are there any restrictions like that with a disassembly either in terms of individual dialogs or the total dialog length?"
Is perhaps not the right question or line of thought in it. I don't doubt there are restrictions with various editors and there are good technical reasons for them, however if you are at the point in life where you are considering playing with disassembly then it is moot.
There are two reasons for such restrictions, three if you want to count screen real estate issues but that is only related at best and sort of covered above.
1) Not enough space in the ROM. Not an issue for almost any GBA ROM (Mother 3 tending to be the only exception worth speaking of) where anyone can have 32 megabytes of total ROM space absolutely trivially if they wanted, could be more of one for the GB/GBC as they were more limited in space and increasing space might have been a hard task (see mbc changing). Working with a disassembly might make this easier but still could throw up some hurdles.
2) Someone did not care to sort out the pointers properly.

Pointers are like contents pages in a book is usually how I describe things. Open up a book, rip out a bunch of pages or stuff some new ones in and if you go along dutifully counting pages to get to what the old and out of date contents page says and chances are you will not be where you want to be. As your little 4.194304MHz z80 a like with 8K of RAM (which is actually more powerful than a lot of even older systems) is not going to want to parse an entire game script every time it wants to do something then it will have little signposts saying where things are, pointing the way if you will. Change the text and you change these, add more in and you have to find new space somewhere in the ROM. Making a text editor handle this I would generally have considered as part of the basic functionality but not all will do that, and might not even need that for the purposes of the would be coder of it if they are less interested in fiddling with major translations as much as changing a word or two here and there and just need a glorified program to display text as determined by their table along with any placeholders and markup, and at least pull from pointers.

[Drenn]

Drenn,

Thanks for posting this.  I'm unfamiliar with Ubuntu, so I'll have to get my sea legs, but it seems relatively straightforward.

As far as editing the text goes, I know with some editors you had to make sure not to go make the each dialog any longer than it was already because it could potentially overwrite the next.  Are there any restrictions like that with a disassembly either in terms of individual dialogs or the total dialog length?  I imagine a small portion of the dialogs would be a word or two longer or shorter depending on how I changed things, but I don't imagine the total number of lines per dialog changing, if that makes sense

You can make the text as long as you like, subject only to the amount of space available in the ROM. Even then, it's trivial to expand the ROM size for more space, the only problem is that you would need to manually relocate some data. I don't expect you'll need to do that, though it's not hard.

Two other hopefully quick questions.  Do you happen to know the character limit per line in Oracles?  If I remember correctly in Link's awakening, it was 16 characters per line.  Finally, since I'm unfamiliar with how the disassembly works in terms of making a new ROM, how compatible would a reassembled Oracles ROM be with some of the existing patches out there?  I currently run Oracles with your VWF, the forced GBA mode, and your color restoration patches.

Thanks again!

The restriction is 16 characters per line. In most cases, though, the script which parses the text will automatically insert newlines to prevent that limit from being exceeded. But there are specific situations that it can't handle, like if there are 17 consecutive characters with no spaces. The game breaks hard when the limit is exceeded. In your case, if you're just making minor changes to the dialog, I would recommend removing the existing newlines altogether and letting the script re-calculate them automatically. (I did this for the VWF hack.)

Because "re-compiling" the ROM can radically change its general layout, it is more likely than not to break existing patches. The GBA-related patches are trivial and could be re-implemented easily. The VWF hack is another story. Since the VWF hack was made with the disassembly, it would make the most sense to make your changes on top of that. The only problem with that, is that I haven't updated it in years, meaning it's missing years worth of work that I've put into the disassembly... so that's not a very good option.

Pointers are like contents pages in a book is usually how I describe things. Open up a book, rip out a bunch of pages or stuff some new ones in and if you go along dutifully counting pages to get to what the old and out of date contents page says and chances are you will not be where you want to be. As your little 4.194304MHz z80 a like with 8K of RAM (which is actually more powerful than a lot of even older systems) is not going to want to parse an entire game script every time it wants to do something then it will have little signposts saying where things are, pointing the way if you will. Change the text and you change these, add more in and you have to find new space somewhere in the ROM. Making a text editor handle this I would generally have considered as part of the basic functionality but not all will do that, and might not even need that for the purposes of the would be coder of it if they are less interested in fiddling with major translations as much as changing a word or two here and there and just need a glorified program to display text as determined by their table along with any placeholders and markup, and at least pull from pointers.

As you pointed out, handling pointers automatically is rather basic functionality for a text editor. None of the above really applies when working with the disassembly, because pointers are handled by the assembler. Basically, forget about pointers. We call them "labels" instead, and although they technically are turned into numbers (pointers), we don't care what the value of the number is because it is determined automatically.

[Greyfield]

Thanks for the replies, Drenn and Fast.  Most of this make sense.

I've started making some edits to /oracles-disasm/text/ages/text.yaml, so will build ages.gbc and test it out.  I'll begin working on the /oracles-disasm/text/seasons/text.yaml next.

From the setup wiki, I see that the time make -j4 command will produce ages.gbc.  But how do you compile seasons?  Do I change the line .DEFAULT_GOAL = ages to seasons or all (to make both) in the Makefile file?

Thanks again,

[Drenn]

"DEFAULT_GOAL" should be set to "all" by default, so it will do both. But you can change it to "ages" or "seasons". Alternatively, type "make -j4 ages" to build ages explicitly. ("time" is optional.)
March 10, 2021, 05:56:32 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
Actually, I was mistaken, because I forgot that the hack-base branch only supports ages. You'll need to stay on the "master" branch and run the command "./swapbuild.sh" to enable editing text on that branch.

Could I recommend joining the discord again? I expect you'll have more questions, and the forum isn't really suited for it.

[FAST6191]

Never quite sure of the merits of real time chat programs for this sort of thing -- some things might want to take a few minutes to contemplate an answer and at that point you are back on forums being workable.
Moreover if Discord decides to get ban happy (and their moderation policies are very dubious and have been for years) or shutter the service (it is not like it is an open protocol you can run your own servers for after all, and I see no reason it will stick around and not join the corpses of ventrillo, teamspeak, mumble and all the rest before too terribly long) then you probably lose it unless someone has backed things up. Going further the next person wanting to play is unlikely to discover some random discord server chat from a web search, nor be likely to find it easily formatted/searchable if they somehow do manage that minor miracle.

[Drenn]

Never quite sure of the merits of real time chat programs for this sort of thing -- some things might want to take a few minutes to contemplate an answer and at that point you are back on forums being workable.
Moreover if Discord decides to get ban happy (and their moderation policies are very dubious and have been for years) or shutter the service (it is not like it is an open protocol you can run your own servers for after all, and I see no reason it will stick around and not join the corpses of ventrillo, teamspeak, mumble and all the rest before too terribly long) then you probably lose it unless someone has backed things up. Going further the next person wanting to play is unlikely to discover some random discord server chat from a web search, nor be likely to find it easily formatted/searchable if they somehow do manage that minor miracle.

You make some good points, and I'm not a fan of Discord being proprietary. But the people who are highly interested in a specific game simply aren't going to hang around on RHDN looking for posts about that game. I'm here now, but there are some other experienced Oracles hackers who could help if this was posted somewhere where they would see it. The same goes for Minish Cap - all of the most knowledgable romhackers have gathered in a "domain-specific" discord channel rather than one big forum like RHDN. (And don't expect them to put in the work of setting up their own forum when they'll ultimately end up with less users than on discord.)

On a chat app, there is more incentive to share very minor romhacking discoveries and quick questions you might not bother to post on a forum. This hurts discoverability, but results in a lot more useful information ultimately being shared. And frankly, Discord is the best option for discoverability among chat apps right now.

I've seen Discord take over IRC for almost everything I used to use it for, and I lament it. But it's more accessible than IRC, and we have so many more people in our channels now. I hope that something non-proprietary will ultimately replace Discord. In the meantime, you are absolutely right - I need to make sure somebody's logging the Discord servers or else do it myself, because there is a lot of invaluable information that may not be anywhere else!

[Greyfield]

Hi all,

Thanks for the additional replies.  I believe I've successfully edited the text of both games, and will give them a whirl soon to see how it went.

- For ages, I used the hack branch with uncompressed assets (for the bug fixes)
- For seasons, I used the default original/master branch with uncompressed assets.  To note, I wasn't sure how to switch back to the original/master branch in Ubuntu, so I just downloaded the disassembly a second time.

The next thing I'd like to do is force the game into GBA mode with the GCB color palette.  I'll take a look at your link tomorrow, FAST6191, to see if I can figure something out.  Conversely, Drenn, is there a way to do that by modifying files in the disassembly? I'll dig around in the files to s what I can find.

I've not really used Discord before, so I'll have to spend a bit more time with it.  I'm an old man.

Thanks again for your assistance, this has been great.

[Drenn]

Hi all,

Thanks for the additional replies.  I believe I've successfully edited the text of both games, and will give them a whirl soon to see how it went.

- For ages, I used the hack branch with uncompressed assets (for the bug fixes)
- For seasons, I used the default original/master branch with uncompressed assets.  To note, I wasn't sure how to switch back to the original/master branch in Ubuntu, so I just downloaded the disassembly a second time.

The next thing I'd like to do is force the game into GBA mode with the GCB color palette.  I'll take a look at your link tomorrow, FAST6191, to see if I can figure something out.  Conversely, Drenn, is there a way to do that by modifying files in the disassembly? I'll dig around in the files to s what I can find.

I've not really used Discord before, so I'll have to spend a bit more time with it.  I'm an old man.

Thanks again for your assistance, this has been great.

To force it into GBA mode all the time, change this line from "inc a" to "dec a". In this context the "a" register needs to be set to "$ff" in order for it to think it's running on a GBA, and this will accomplish that.

To force GBC palettes in GBA mode, you would change this line from "jr nz,@gbcMode" to "jr @gbcMode". This changes the conditional jump to a non-conditional jump, meaning it will always jump to the gbc mode code.

This should work the same as the IPS patches / game genie codes, although the specifics may be slightly different.

[Greyfield]

Thanks Drenn, that worked!