Zeldix Magic

If you're looking for more bells and whistles while still keeping cross-platform capability, this is probably your best option: https://www.jetbrains.com/rider/

I would suggest targeting either Mono or .NET Core, so the final application itself will be cross-platform.

Otherwise, VS is basically the best there is, but it's Windows-only.

Edit: Hmm... it's still in prerelease, and might not be free once released (since ReSharper isn't).  So, that might be a non-starter. VS Code might really be your best bet.

Alright, so I got a new repo and account. A newer version of the program is up. I am aware that I haven't used "VisualStudio.gitignore" correctly.

Also, the program has code setup to save changes to the ROM for the monologues but the changes aren't being written to the ROM. For those who want to look at the code, the program has a temporary copy of the opened ROM in the resources folder to write to. The romio class has code to save to the rom. The code is executed, but never writes to the file. Any one else experiencing this?

Not looking at the code, one pitfall I can imagine is that trying to read and write the same file tends to not go well, with results exactly like that, just not writing anything to the file. Considering how small it is, I'd just read the whole ROM into memory and close the file, operate on the RAM buffer, then write it all out to file on save. If that's already what you're doing, feel free to ignore.

Okay guys, originally my plan was to move the off topic stuff into it's own thread but the site features were not agreeing with me. I tried twice and both of those times posts that I know for a fact were not selected ended up in the new thread. So, I merged the two threads back and just deleted the off topic stuff instead. If anyone wants to debate strategies for organizing and maintaining a Zelda III ROM hack I suggest you start a dedicated thread for it.

Anyway, carry on.

The issue was solved by the way, I haven't committed the fix to github yet. The text can be written to the ROM, however, there are conflicts. For example, the letter "A" conflicts with hex values with "A" in it. I tried to fix this with prioritizing letters and numbers to be replaced first but that didn't fix the issue. Any suggestion on how to avoid this instead of replacing "A" with "$" and then replacing it later would be appreciated. I'd rather not have a hacky solution.

For reference, Zelda III uses fixed byte pair encoding. It' very easy to decode but I am currently having trouble encoding.

EDIT: It would seem that reading byte by byte is probably a better method than replace all. As for saving, I'm thinking about replacing the old monologue in the binary with the new one instead of encoding everything at once.

Make sure you opened the file in binary mode.

That's not the issue here. I'm replacing text in a string and converting it to hex. Once that is done, I insert back into the ROM. The issue here is that encode parts of the string are being decoded again there being turned into gibberish. This is more fault in my current algorithm.

What I need to do is create another algorithm instead of lazily replacing characters in a string. It will require a complex algorithm, but I think I worded it out in my head.

When I did my credits text editor, I read in the characters into 2 separate arrays, one for the raw characters, and the other for the attributes like color, then when I wrote it back I combined the two to encode the final value. For monologues, I don't think they have color attributes, but you do have the dictionary, so I would just load them into text strings, then when you go to write them back, go character by character, and scan the dictionary for matches. If you find a match, write the dictionary value, if not, write the character and move to the next.

qwertymodo wrote:When I did my credits text editor, I read in the characters into 2 separate arrays, one for the raw characters, and the other for the attributes like color, then when I wrote it back I combined the two to encode the final value. For monologues, I don't think they have color attributes, but you do have the dictionary, so I would just load them into text strings, then when you go to write them back, go character by character, and scan the dictionary for matches. If you find a match, write the dictionary value, if not, write the character and move to the next.

That's the idea. I plan to have a counter that increments by one. It's a bit tricky so I'll show you with example:

dictionary:
* CA
* THE
* _
* _D
* OG
Phrase to encode: THE CAT DOG

Note: The longest phrase is 3 characters long.
^ = cursors

Phrase: THE_CAT_DOG
Cursors:^#^
Selected string: THE

It's in the dictionary so we decode that. The next place to check is (current cursor value + length of found dictionary word)

Phrase: _CAT_DOG
Cursors:^#^
Selected string: _CA

Not in dictionary, so we move the left cursor

Phrase: _CAT_DOG
Cursors:^^
Selected string: _C

Nope

Phrase: _CAT_DOG
Cursors:^

Selected string: _

Found

… etc.


Does this make sense? I already created the data structure to store the dictionary so it can be found faster. I should have no trouble with the algorithm.

Well qwertymodo, you were right. It was a data type issue, though my explained problem was an issue as well. Now I need to fix up the code because I convert hexadecimal values to decimal and vice versa way too often. After that, the monologue portion of the program should be ready to use.

The program includes new features like an export function and the ability to define a range to edit your text. A step up from Hyrule Magic.

You shouldn't ever need hex values unless you're actually trying to print in hex in the GUI. Binary data should just be stored in an array of unsigned bytes, whether that's unsigned char or uint8_t, or whatever. Then you just write the bytes to the file. Storing individual bytes in larger types like int is just asking for trouble, and also wasteful.

Will the monologue editor have anything to indicate text box boundaries? It takes an ungodly amount of time to test and tweak the text for an extensive hack of this game. When I did a heavy text edit one time the only decent way to test the dialogue (why does HM call it a monologue? wouldn't that be Link talking to himself or something?) changes was to save the edited text in the slot for "Help me... Please help me..." at the beginning of the game. Save states are out of the question as any change will then ruin all of the text for that save state.

Link doesn't talk back, it isn't a dialogue. However, the text box itself could be referred to as a dialog (note the spelling).

qwertymodo wrote:Link doesn't talk back, it isn't a dialogue. However, the text box itself could be referred to as a dialog (note the spelling).

He doesn't say much but he does indeed respond to some of the other characters. Most of the time it's just stuff like "Yes", "No", "I don't understand", but he also has the option to say stuff like "I just dropped by" (when talking to the King Zora or whatever) or to lie to the pond fairies about throwing stuff into the pool.

SunGodPortal wrote:Will the monologue editor have anything to indicate text box boundaries? It takes an ungodly amount of time to test and tweak the text for an extensive hack of this game.

Yes. That's already implemented. Check out the .exe on github.

qwertymodo wrote:You shouldn't ever need hex values unless you're actually trying to print in hex in the GUI. Binary data should just be stored in an array of unsigned bytes, whether that's unsigned char or uint8_t, or whatever. Then you just write the bytes to the file. Storing individual bytes in larger types like int is just asking for trouble, and also wasteful.

Indeed.

Check the github repo out. The program now has fully functioning saving and exporting features. Enjoy and happy holidays.

Trovsky wrote:Yes. That's already implemented. Check out the .exe on github.

I'd like to but I can't seem to find it. When I follow the link in the OP I see no exe.

Binaries should not be committed into the repo (thankfully the .gitignore already blocks that), instead you should use github's releases feature: https://help.github.com/articles/creating-releases/

I've since removed the .exe file once I understood how .gitignore worked. As qwertymodo explained, you'll have to compile the .exe file yourself, unless you want me to give you a download link from a shady German website.

Ah. This is going to sound stupid, but I'm really not in the mood for learning something new. LOL I'm in the mood for something easy and obvious. I'll just check it out later.

Trovsky wrote:you'll have to compile the .exe file yourself, unless you want me to give you a download link from a shady German website.

See the link I posted Re: releases. Though, i suppose that's more intended for actually releases when it's at a stable version, rather than for uploading binaries of random commits.

SunGodPortal wrote:Ah. This is going to sound stupid, but I'm really not in the mood for learning something new. LOL I'm in the mood for something easy and obvious. I'll just check it out later.

I pushed a new branch and included the bin folder. Check out the releases folder and try to run Zeldix.exe. You do need to have the resources folder and have in the correct relative path.

I pushed a new branch and included the bin folder. Check out the releases folder and try to run Zeldix.exe. You do need to have the resources folder and have in the correct relative path.

It works. Good to see a GUI interface.
Great job. You definitely need to continue with this work.

By the way, I think it is odd how Z3 handles repetitive words. I think it woluld be better to make everything in one byte one letter and autorepoint the data to a custom location between 100000 and 200000. I believe this actually is possible under "custom". I'm assuming this is where you enter the address and a new block data, while copy pasting initial both global banks of text in hex there.

Ah. This is going to sound stupid, but I'm really not in the mood for learning something new. LOL I'm in the mood for something easy and obvious. I'll just check it out later.

It's not really new as such. Compiling is a normal process of bringing the source code into one executable with possible additional files. Good to see this thing actually is public.

Puzzledude wrote:
It works. Good to see a GUI interface.
Great job. You definitely need to continue with this work.

Yes, I plan to work on them a better music editor sometime, but right now I have some other non-Zelda related work to do.

Puzzledude wrote:I think it woluld be better to make everything in one byte one letter and autorepoint the data to a custom location between 100000 and 200000. I believe this actually is possible under "custom". I'm assuming this is where you enter the address and a new block data, while copy pasting initial both global banks of text in hex there.

I don't quite understand your premise, but the custom option doesn't change pointers, it reads at a location that the user inputs. I don't have the location of the pointers for the monologue so I decided to have an option to read at a specific location if a the user moved the monologue location for whatever reason. The custom option should also be useful for any game with the same script structure, you just have to change the character values in the txt file in the resources folder.

The txt file is how the program gets the character values and the DTE table. If someone could provide the pointers for the DTE table values, that would be helpful. The location of the words in the DTE table I know already.

Puzzledude wrote:Compiling is a normal process of bringing the source code into one executable with possible additional files. Good to see this thing actually is public.

The project being open source is a response to Hyrule Magic not being so.