animal forest translation?

[kkAteMyHomework]

This is awesome! I just stumbled across Animal Forest and thought it would be really fun to try, but the version I downloaded had only the introductory stuff in English. All animal conversations were still in Japanese, and there was some bug such that I couldn't see anything when I opened my inventory, so it was pretty much unplayable.

I just downloaded the patch ZIP file and went through all the steps. I got my extended, patched ROM and it loaded up fine. I went through setting the clock, talking to KK on the loading screen, talking with Rover in the train. However, when he said we were about to my town and the conversation ended, the screen just went black. The emulator is still running (Project 64) and I can still hear the train tracks audio loop, but the screen remains black. Any idea what could be behind that? I'm about to try the patched ROM in OS X, see if that does any different.

It's great of you to undertake this project, though. I hope I can get it to work, because I'd love to play Animal Forest for real.

 

[kkAteMyHomework]

Haha, just stumbled across the following in one of the READMEs from the ZIP:

3) Possible crash bug when starting a new player. The game may sit-and-spin upon pulling into your town. This may have been solved with the mail bug, but as of yet must be thoroughly tested.

Sorry for not RTFM first! I'll try creating a game again, this time on a Mac, and see if I can avoid this bug.

 

[kkAteMyHomework]

Aaaaand a little more feedback. The extended, patched ROM will not load for anything in Sixtyforce in OS X. Black screen for a few seconds, no Nintendo logo, and then the app crashes. The original ROM and the extended-but-not-patched ROM load fine in Sixtyforce, but not the patched one. I tried downloading a UPS patcher for OS X and re-patching the extended ROM in OS X, but that ROM still causes Sixtyforce to crash. I then tried the alpha build of the Mupen 64 Plus emulator, and it wigged out over the file name of the extended, patched ROM at first, but after a rename, it loaded the ROM. Yaaaay English Animal Forest on a Mac! However, Mupen didn't do great at textures, transparencies, etc. For example, K.K. Slider's guitar was patterned with a white and black K.K. face texture. So I would prefer to use Sixtyforce, but it keeps wigging out on the patched ROM. I'll keep looking around for other OS X emulators and trying them out. Thought you'd like the feedback.

 

[zoinkity]

Sorry I haven't been able to respond this whole time. It has been inifinately more difficult to get at the internet, and I can't post an update at the moment due to how I'm on here. Aegh...

Okay, the problem has to do with how these emulators detect ROM settings. Virtually all N64 emulators are high-level ones, meaning they don't emulate most of the hardware. To get around this issue, they use a ROM database file, listing all the known ROMs it expects to encounter and the appropriate settings to run each.
The most likely issue is that you need to open whatever database they use, find the Doubutsu no Mori entry, copy it, and use that as a basis for an Animal Forest entry. If it can run the original, it can run this too.

All known graphics plugins will not display any character on the menu screens properly, be it you, a gyroid, or whatever. That doesn't occur on a real N64, so I'm not putzing with it.

Now, not having either of these emulators and likely not being able to use either (very old computer here), I can't especially help you in a timely fashion. You might be able to coerce somebody into it however. Keep in mind the entry will need to be updated with each patch revision.

+_+

Intro bug is a crash due to bad mail. You get one piece of mail at the beginning of the game, and sadly one of the messages bugs the mail generator. I'm completely rewriting the mail message generator, so a future patch should fix this, but currently it can still occur. Aegh...

+_+

Next patch will have proper line wrap for all messages and mail. The cursor was the most annoying part honestly.

Mail generator fix will likely be in the following patch. It uses an evil script, a temporary memory bank, and is guaranteed to break the two debug mail entries.

-Zoinkity

 

[zoinkity]

December 2nd, 2010 Animal Forest Update
Newest patch is uploaded to:
http://www.mediafire.com/?oxexa2194ex424k

+_+

Changes:

• General:
  • Added linewrap to mail, message board, and gyroid block text.
  • Updated system for detecting end of line.
• Dialog:
  • Altered default gyroid message to wrap (mostly) properly.
• Bugs squashed:
  • Small fix to mail labels. Silly Faraway was a little too far away.

Documentation:

• New Files:
  • 71F4E0 - text entry dial control.txt
    • Disassembly of the text dial dialog, used for all cursor tracking.
  • 721D80 - mail messages.txt
    • Mail display and editting dialogs.
  • 727260 - display message.txt
    • Message board display and editting dialog.
• Updated:
  • ROM ASM Correspondance.txt
  • Index.txt

Resources:

• New Binaries:
  • Sorry, wasn't keeping track.
• Updated Binaries:
  • 675720: Primary Compressed File
    • Minor edit to lowercase letter spacing.
    • Addition of subroutine to return number of characters constituting a line of text.
  • 727260: Message Board Interface
    • Wordwrap implemented.
  • 721D80: Mail Interface
    • Wordwrap implemented.
  • 71F4E0: Type Entry Dial Control
    • Proper cursor tracing for wordwrap implementation.
  • 71D580: Gyroid Message Interface
    • Wordwrap implemented.

Programs:

• No changes.

+_+

This marks part one complete of the two-part message update. Wordwrap should now function properly for all block text. Anticipate a brand-new set of terrible glitches.
Part two will be a unique storage system for generated messages so they can exceed the normal message cap. No idea when that will ever get done, but it might!

Also, now an xdelta patch is also provided in the zip file. I didn't provide a patcher, but you can find that rather easily.
If you are on a Mac or otherwise can't use the rom extender, you can usea hex editor to extend the ROM as well. You want to double its size and fill the extra region with zeroes. Then either of the patches can be applied using Mac builds of the patchers, which you'll again have to find. Sorry it is such a hassle.

+_+

Now to give you a proper response about the debug menu.
The manager pointer is at 8010EF90. The pointer at this address always points to the file manager data. On the N64 this is almost always 80229050, so you can make a GS code to activate debug that will usually work--without hacking codetypes ;*) When I write @manager, that means the pointer at 8010EF90--in other words, 80229050.

To change menus, you need to set three values.

@manager+C	80801A34	pointer correction value, used for ROM lookup
@manager+10	00000240	size, used for allocation
@manager+9F	00		trigger load, unset loaded

The pointer correction value is a virtual address. This isn't a memory address like you usually see, but a tricky scheme similiar to TLB values. They compare this to the master ROM list, then load and decompress the file that contains the address. From there, they convert it to a real rdram address to the loaded data.

The GS equivalent to the built-in thingy I'm using would be this, which would only work if @manager is 80229050:

Trigger debug when controller 2 L+R pressed:
D0145B49 0030
8122905C 8080
D0145B49 0030
8122905E 1A34
D0145B49 0030
81229062 0240
D0145B49 0030
802290EF 0000

Now, since they probably altered the ROM, the debug address will likely be different. So, you're going to have to search for it. That's not nearly as bad as it sounds. You just need to find the main file table in the ROM. In the N64, this lies at ROM+0x19D40. The first couple entries probably won't be too different, and they're this:

codeword	endcode	ROMstart	ROMend
00000000	00001060	00000000	00000000 
00001060	00019D40	00001060	00000000

These dictate at what offset in ROM each of these start, where each ends, and the codewords used to access each entry. Each entry is 0x10 large.
When you find the first entry, you need to go down to the seventh entry. In the N64, this entry is:

0073F4D0 00741A40 006ED6C0 006EECE0

This lowly entry is the ROM address for the debug menu. If you decompress the file at this location, you'll get all the code and text used by debug. For our purposes though, all you want is the first two words: the codeword start and end.

Since you're lucky enough to have a ram editor, you can search memory at runtime for these two codewords. You should only get one hit. If you can't edit ram though, you could decompress the file at the sixth entry (roughly 800Kb large) and search for it there. Either way, you'll get a hit that looks similiar to this one:

0073F4D0 00741A40 80800000 80802570 
00000000 80801A34 80801A28 00000000 
00000000 00000000 00000240

This is the menu entry used in-game to load the debug menu. Now, you could menu swap to activate it, except this in practice isn't useful for debugging in game. Instead, you're going to use the entry's data in order to activate the menu directly on-demand.
In this entry, you want two values. You want the value at 0x14--the entry point--and the value at 0x28--the allocation size. In this case the entry point is 80801A34 and the allocation size is 00000240.
Now, you simply need to feed these two values into the file manager to create the menu swap code, then trigger a menu swap. The final result is the ocde you saw above:

@manager+C	80801A34	pointer correction value, used for ROM lookup
@manager+10	00000240	size, used for allocation
@manager+9F	00		trigger load, unset loaded

Here's hoping you don't need to find the manager pointer, because it requires either breakpoints or code analysis.

That's how you can go about grabbing the debug menu. Oh, incidentally, the compression type is Yaz0 and probably didn't change in re-release. Heck, they're still using Yay0, and that's also from the N64 days. If you do need to decompress anything, you can use the tools provided with the patch or use one of the many other yaz0 decompressors floating about. You could code your own too, since it really is a simple format.


-Zoinkity

 

[zoinkity]

Sorry about this bump, but thought you might want to know about progress.

This last step is exceeding the message length limitations for generated messages. They're being saved using a special format involving a set of codewords.
So far, the scheme works on the message board. However, I'm going to have to alter the codeword system slightly to account for normal mail messages.

Also, as a side-note, 80- codetypes were reserved but unused in AF. In later releases they were identical in content to the 7F- codetypes but always one byte longer. In fact, the format is more 80.##-, where ## is the length of the command. This means, theoretically, you don't need a table for the command lengths. From a programming perspective though there is a minimum length since you do expect certain data, so variable size only would be useful if you were embedding comments or using optional arguments--neither of which they did.

 

[Zuzma]

Thanks for the progress report zoinkity. There's a lot of people out there who'd love to see this completed. Have you ever though of posting at a different board? Or do you post somewhere else already? I bet you'd get more attention at the personal projects forum at romhacking.net.

 

[zoinkity]

Nah, never posted anywhere else about this. Funny enough, happened across this thread via search for a patch or in-progress for the game. Normally I don't have this degree of internet access and it isn't going to last, otherwise spamming a dozen boards wouldn't be a bad idea. You could start one if you like, but I'm probably not going to be able to post in it very often.

The only real advantage to having a thread at romhacking would be to have some kind of N64 project located there. There's been, what, six games with submissions in their database and I've worked on all but one to some degree. Don't know why, but us N64 hackers keep odd company and don't consolidate often.

Also, there are a couple advantages of a strange slow board like this one. One is you don't have to show a lot of progress all the time, and the other is you don't get a million crazy demands to hack game X in Y time for silly reason Z or else your pet A will be eaten by a B while you're tortured to C with a D.

 

[Zuzma]

Yeah that's true about there not being many N64 hackers out there. I'm pretty sure the only translation I played was wonder project J2. I remember reading about it in the past in an old gaming magazine and remembering how cool it looked. Too bad they never brought it over officially.

But yeah I thought maybe you'd get at least a little more attention at romhacking.net. It looked a little lonely here seeing you posting updates and not having any responses for months. As for the board itself I don't really see too many people demanding stuff there. The moderators are usually quick to axe trolls too. Anyway since you're happy with this place I'll just leave it at that. Thank you for doing this translation by the way.

 

[zoinkity]

Besides Wonder Project J2, there have also been Spanish and French translations for GoldenEye. I don't know of any others that have been completed.

There may not be many responses here, but then again I go months without posting as well ;*)

 

[zoinkity]

Been thinking about it, and could unlock a few things ;*)

As a heads-up, once this whole message-storage thing is worked out, you'll have a penultimate patch. Afterward, there will be bug squashing and whatnot obviously, but I'm going to go back through all the data files and try to relink all the text used in every binary that's been hacked and link these externally to a new text bank.
The whole reason for this completely unnecessary work is so that future translators will mostly need to deal with script files. That should reduce extra work to special requirements, image hacking, and maybe some message widths.
Note none of that will be happening until a semi-final patch.

Wow they use messages a lot. Tracing these hooks is tedious at best. Everything that reads or writes a message needs to be updated.

For the heck of it, also mapped out the character bank. Still have to work out exactly how their vertex merging system works. Slightly different from GE's. Still, enough of the model outputs correctly to identify each animal type. Never even saw a few of them before.
Still trying to get the primary model bank to extract without an issue. It isn't data formatting or anything; my compiler doesn't treat malloc as memory-protected so it will randomly write data into the allocated array.

 

[zoinkity]

Send aid to Japan if you can.


I'm debugging the next patch release right about now. Among other things, you'll get an updated bug list. Among those is a bug that apparently has been around from almost the beginning causing certain days to simply crash. Working that one out still.

In the debugger there's quite a few japanese notes. One of the more interesting ones is familiar to all you old-school gamers out there:
KeyWaitB (LRZ up down up down left left right right BA START)
KeyWaitB'(LR left right START)

The Konami code lives!

 

[Tonypantz]

This looks interesting. I look forward to seeing a patch :3

 

[zoinkity]

Update! (note new link)

April 1st, 2011 Animal Forest Update
Newest patch is uploaded to:
http://www.mediafire.com/?kk5q8vh81w89d63

+_+

Changes:

• General:
  • IMPORTANT! .xdelta patches against original, unextended ROM. UPS still patches against extended ROM.
  • Uses external string lookup for debug strings. Will eventually rig everything this way, except the default lines which should always be hardcoded of course ;*)
  • No controller message autoformats, uses external text, and may vary from 1-6 lines.
  • Now accepts 7F6F commands in mail and message board text. Interpretter uses specialized formatting to restore and insert replaceable strings.
  • Generated messages so not yet fit above spec! Next patch will do that. See below for details.
• Dialog:
  • Translated debug messages for test maps. Granted the maps don't work right yet...
  • Translated internal debugger messages, on the off-chance you cause some terrible stack failure.
  • Set string.txt 2F2 and 2F3 to "Dreamcast" and "PS2", respectively. Hopefully those IDs aren't used ;*)
  • Credits in string.txt no longer include leading or trailing spaces, as these are no longer necessary with the credits fix above.
• Bugs squashed:
  • Digging, fishing, and bug-catching all should use aliased (full-length) item names.
  • Credits now left-align names. No more crashing on long names or spaces to enforce alignment.
  • Killed a rather stupid bug I introduced to record string lengths.

Documentation:

• New Files:
  • 71F4E0 - text entry dial control.txt
    • Disassembly of the text dial dialog, used for all cursor tracking.
• Updated:
  • ROM ASM Correspondance.txt
  • Index.txt
  • Hacking text recall routines.txt
  • 721D80 - mail messages.txt
  • 727260 - display message.txt
  • Quest Generation.txt

Resources:

• New Binaries:
  • 77F940: Debug Gyroid in Test Level 1
    • "Item" names externalized and translated. Look to string.txt: 2F2 and 2F3.
• Updated Binaries:
  • 675720: Primary Compressed File
    • Translated default character and catchphrase. "Johnny B." is literal, but the catchphrase was set to "debug" so you could identify it from the matching one in string.txt.
    • Spun off 800C3F74 as a "general" string retriever for "standard" text banks. One more messy bit of code in the overall mess of code to be cleaned up.
  • 727260: Message Board Interface
    • Allows aliases in messages. Does not yet generate them!
  • 721D80: Mail Interface
    • Allows aliases in messages. Does not yet generate them!
  • 734F30: special dialogs and item interaction
    • Now uses aliased item names for fish, insect, and unearthing dialogs.
  • 854A60: Title Screen
    • No controller message update:
      • Now utilizes variable-width font.
      • Message autoformats: each line is centered horizontally and spaced vertically based on number of lines in use.
      • Controller messages may span 1-6 lines of text, drawn from string.txt lines 61A-620. Unused lines should remain NULL.
  • 8574E0: KK and Credits
    • Allows more header entries.
    • Right-aligns headers and left-aligns names.

Programs:

• No changes.

+_+

Two really important things:
1) The .xdelta patch should patch against a non-extended, unbyteswapped ROM. Only the .ups patch still requires an extended one.
2) Message board and mail interpretters now read this crazy extended format, allowing you to use an alias command to generate mail and replace strings within it. However! It doesn't yet generate this kind of message. The reason it doesn't is simply to get the patch out now. I'm sort of getting evicted and wanted to ensure everyone has the latest set of code (including myself!).
The way I've been testing the interpretter, and the way you can, is to hack your message board messages manually. They usually fall within the 8012xxxx range, and you can find them with a simple text search. You replace this message with a 7F6F command to load its text, and you can also replace strings within it.
As a simple example, the typical "anyone can use this message board" message would be written:
7F 6F 30 1E 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
The result is it copies mail.txt entry 0x1F to the buffer in its entirety and displays it.
There's also a method for string replacement which is a bit messy but does work. You place specially-formatted string stringies inside 0x80 flags.
This would print the message: "Here's the chic carpet you ordered. ..."
7F 6F 30 4F 80 24 04 7F 6F 26 01 80 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
The first four bytes loads the message. Then comes the 0x80 flag, and that says a list of text replacement keys follow. The first key is for a 7F24 "string 1" replacement, replacing any instance of that in the message with 04 bytes, that being 7F6F2601. 7F6F2601 is an alias to load the string "chic carpet", or in other words string 01 in text bank 26. Aliased aliases. That's why this patch took so blasted long.
After the list of string replacement codes you must type in another 0x80 or it will sort of never stop looking for them. Was going to kill that bug but sort of didn't get that far.

Besides having to make proper generators for these messages, will also need to fiddle with capital letter widths. 'A' is too wide, and its enough to jump lines.

Wow, one huge bug went undetected for at least two years! Some (but not all) Saturdays crash. March 5th, 2011, for instance. There's a bad pointer and a lot of copying involved, so it may ultimately stem from a bad pointer correction file. Working on tracing it.
You can assume every patch since at least June 2009 is affected. I don't have backups beyond that point.

Updated the bug list to indicate the debug town doesn't work right. Animal outfits, text, and behaviour are all screwed up due to a bad pointer. Will work it out, but since the error is contained to something that you shouldn't technically have access to anyway, it isn't exactly high-priority. Might even be tied to above. Again, goes way the heck back.
An interesting note is that all the debug towns are the same town. Yep, they're just seperated by inaccessible (untiled) rooms. You can tell (tee hee) by reading the item placement files. Map files are more a hassle, but you could read them too. The intro demo town, on the other hand, is its own entity.
A few people have asked why debug menu access was limitted. First was that in some menus you'd screw up game data, but if you didn't have a town yet and used the menu, then jumped to particular points you could make your town one of the hardcoded towns.

In "block A2" of debug test 2 you'll find a paper airplane. You can collect it with A and throw it with Z (?). It will fly a short distance, land, and then fail to hand control back over to the player ;*) If there's time, I'll try to hack that thing so it works properly. Seems kinda fun.

Credits are now (mostly) right-aligned headers and left-aligned names. (left-aligned isn't 100% accurate but good enough, notes containing the accurate code) Note at the moment it doesn't add any extra credits in. There's a script with that already, but the issue has to do with them being timed against the music. Without tracing the multipliers you're limitted to a certain number of windows, allowing 10 lines of 20 letters per window.
The point of this credit hack was to circumvent an issue with "long" names. If you roll over the right margin bad things happen, and it looks more like the original format this way. Still, be careful with header name lengths.
As a technical note, the "I'm also a header" list now can accept (theoretically) any number of entries, terminated with zero. (You'd have to move the list to get more than two extra) In case you're curious, there's two lists. One marks the entries starting each page, each of which are treated as a header. The second lists additional entries that should be treated as headers. Originally, the only difference was the scale multiplier applied.
I've been concidering adding in a feature to tag a line as a header directly in the text, but it does seem unnecessary right now. Maybe in the future. Maybe.

Yes, the no controller message is amazingly autoformatted and may span an autodetected number of lines (limit 6). It really was completely unnecessary, so concider it a taste of how everything will eventually be formatted.
With any luck, future translations will be little more than plug-and-chug. -well, except for the images. -and typeface promotions. -etc.

Next patch release will be whenevre I can get back up and rolling. In the meantime you can always you the data provided with the patch to continue your own work.

-Zoinkity

 

[Lysol Pionex]

Donations?

Do you have a way to accept donations for your hackery?
and do you have any other awesome hacks on which you're working?

I'm very impressed by the progress you made on this ROM; so glad you took it over. It would have gone nowhere otherwise.

 

[zoinkity]

Can't really accept donations.

At the moment I'm short a computer (unless you count "work") so I can't quite work on Animal Forest at the moment, but there's some smaller projects (ie. will fit on a memory stick). Nothing cool or notable though.

 

[Elfmaniac]

Hi there! First of, congratulations to zoinkity for his amazing work on Animal Forest !

I report a bug (a very annoying one) :

With the last patched Rom (04-01-2010), I have a freeze at loading a game the day after the extension of my house after paying the 18 000 (or so) bells to Nook. I load my game, a citizen prepares my town for me and it crashes at this moment. Someone else created a town on her computer and the game crashed the day the house might be extended too. So it seems the problem comes from there. Always when the citizen prepares the town with the orange text. But the music still goes on.

Is someone aware of this bug too and has an answer or a fix to this?

I'm on Project 64 1.6 with Jabo Direct 3D 8 and I of course have patched and extended the Rom.

Thanks and zoinkity if you come here, you do a great job !

 

[zoinkity]

Thanks for the bug submission. I'll try to work out a fix. It must have done something terrible to the town data for that to happen.
If you could send a bad save file to [email protected] it would help enormously. I'll trace where the problem lies from there. Before and after would be better, but either way.

I don't have a computer of my own at the moment, but can do some tiny stuff via USB stick.

 

[Elfmaniac]

Thanks for your quick reply!

I joined you everything you need (I hope).

 

[zoinkity]

Just as a small update, I am tracing the bug but it will take a bit of time to narrow down exactly what's screwing it up much less fix it. So there is a fix coming eventually.

In the meantime I'll try to come up with a save editor to fix specific problems like this. The biggest issue has been badly generated messages, some which are triggered on certain days of the week. Aegh...