After getting several questions/comments on how to dump a game / apply the patch, I’ve decided it would be best for me to create a video outlining the process.
The video outlines each step, including dumping a game disc, downloading the appropriate patch, and applying the patch using the necessary tools.
Requirements
A Wii with The Homebrew Channel installed
If you don’t have the Homebrew Channel already, you can follow the instructions over at [wii.guide]
An SD Card or USB drive with at least 1.35GB of space free
Must be formatted to FAT32, you can use [GuiFormat] if needed
After some research, I’ve figured out how to customize the save file header information for both AWL and AnWL.
Each game has a file named wlp1.rel, which is a relocatable module (similar to how .dll files function for Windows programs). This file has the information which dictates the header info when creating or overwriting a save file.
This information includes the chapter names, the save filename, the game / save title, and the banner / icon to be used.
By manipulating this file, I’ve changed the game / save title for each game to HM: APL (for the wlw mod) and HM: AnPL (for the mlm mod).
I’ve considered changing the filename (originally bokujyo4.dat or bokujyoA.dat, depending on the game), but changing this would invalidate any previous save files for users of earlier alpha/beta builds of the mod.
Save Block Textures
In addition to modifying names / variables in this file, we can also modify the textures used. While I had already modified banner_card.tpl, I decided to try my hand at modifying card_icon.tpl. This file is a bit trickier since it uses a texture format that utilizes pallettes.
The important thing to note hear is that all of the individual textues must utilize the same pallette for the textures to render properly when displayed by the console hardware.
It’s also important to note that the order the textures are displayed is in bouncing order. That is to say that they go in order of 1->2->3->2->1->2->3, as opposed to a normal GIF loop order of 1->2->3->1->2->3. This is most noticable when seeing how the dog mouth opens / closes on the otiginal save icon
Standard Loop
Bounce Loop
Creating a new Save Block Texture
I started by deciding what I wanted to make for the new save icon. After some internal debate, I decided on using the blue feather (the symbolic item for proposing to one of the romance options) with a LGBT flag background. I created a version with a standard 6-stripe rainbow flag (1979 6-stripe variant), as well as one with the lesbian flag (2018 5-stripe variant).
I also created versions with the Philadelphia pride flag (2017 8-stripe variant) and Progress flag (2018 variant). While these show up ok with increased internal resolutions (i.e. emulator), they appears blurry / pixelated on original interlaced resolutions (i.e. original hardware). For this reason, I have made them available as optional, which can be used to replace the card_icon.tpl texture file on the disc.
Blue Feather (from commonall.arc.clz\symbol.tpl\Texture5), 1979 Rainbow Flag, 2018 Lesbian Flag, 2017 Philadelphia Flag, 2018 Progress Flag
Progress and Philadelphia Pride Flag Mockups
Philadelphia Flag card_icon.tpl [DOWNLOAD] Progress Flag card_icon.tpl [DOWNLOAD]
To ensure that all images used the same pallette, I saved each texture as a single-frame 256-colour .gif file. When saving the first texture, I saved the generated colour table as a Photoshop palette. Then, when I saved the second and third textures, I loaded the colour table from the previously saved palette file. This would ensure that all three saved .gif image files had the same embedded colour table / palette.
When loading a .gif with an embedded colour palette into BrawlBox, it will give the option to import the palette. By selecting this option when replacing each texture in the card_icon.tpl file, it ensures they’ll all match.
Once the game is loaded with the edited wlp1.rel, card_icon.tpl, and banner_card.tpl files, and the game diary is re-saved, the changes will take effect.
Throughout my research for Harvest Moon: A Proud Life, I’ve come across numerous odd files.
Many of these file types are common across various other Gamecube and Wii games. Some are less common.
That’s why I’ve decided to start a new project. I’ll be analyzing any GC/Wii dumps I can get my hands on so that I can log their disc contents. I plan on analyzing/posting a different game each day.
Each post will be tagged as GCN or Wii. All applicable file types (e.g. .tpl, .arc, .txt, etc.) will also be added as tags.
My goal is that other modders can easily check if there are other games that use a specific file type. I hope that this project will serve the community as a useful reference.
It’s recently come to my attention that some other projects are now using the tutorials I’ve written on this blog. This was always my intent and the primary reason why I’ve been documenting all of my findings while researching AWL.
I’ve now created a [Harvest Moon Translations Discord] where people can collaborate and discuss translating AWL, as well as other HM/SoS games into various languages.
I hope that having a dedicated server will offer people a common place to help work on these projects, and get in touch with others who might have helpful expertise, whether it’s knowing another language, or technical knowledge about the game in question.
Currently I’ve created channels for a few AWL, FoMT, and DS projects, but more will be added as they come up.
If you or someone you know would be interested in helping translate some of these games, feel free to [join]!
Update: QGCon 2020 has been cancelled due to COVID-19. I look forward to QGCon 2021 pending future updates from the organizers.
Those of you following me on Twitter might have already seen, but I’m gonna presenting a talk at the upcoming 2020 Queerness & Games Conference (QGCON). This years conference will be hosted May 23-24, 2020 at Concordia University in Montreal, Quebec.
The conference is focused on the intersection of LGBT issues and video games. It brings together queer studies academics, video game industry personnel, artists, players, and more.
I’ll be presenting a 20-minute talk tentatively titled “RETROactive Queer Representation: Usage of Mods and Romhacks To Implement Queer Representation in Retro Video Game Media”.
My talk will be aimed at presenting and discussing various romhack / modding projects that add queer representation to retro games. I’ll be discussing why individuals might express interest in such projects, as well as the different hurdles that might be faced when working on such projects and the potential implications.
I’ll likely be staying in Montreal for about a week or so; a few days before the conference, and a few days afterwards. Please feel free to send me any of your local recommendations.
If any of you reading this are going to be attending the conference, I look forward to seeing you there. And if you’re gonna be in town but not at the conference, feel free to hit me up on the HMAPL Discord so we can set up a meet up!.
After some research, we’ve determined that the save files for A(n)WL use a checksum to verify data integrity.
If the save data is modified and this checksum isn’t accounted for, a data corruption error will be presented when attempting to load the data.
This checksum is a 4-byte (32-bit) value stored at 0x40
Note: save files can be when using Dolphin emulator are located in “C:\Users\{USER}\Documents\Dolphin Emulator\GC\USA\Card A\”
The value can be calculated by taking all of the data after the checksum position, i.e., 0x44 to the end of the save file, and then calculating the checksum using the CRC32_bzip2 algorithm.
I’ve found that the easiest way to accomplish this is by saving the save data (from 0x44 onwards) to a seperate file (in this case, I’ve named it as hashtest.bin)
Once created, the save data (hashtest.bin) can be analyzed using a supported tool such as Jacksum. For Jacksum, I used the following hash command:
java -jar jacksum.jar -a all -F "ALGONAME{i} (#FILENAME) = #CHECKSUM{i}" hashtest.bin
Then just look at the output of the crc32_bzip2 hash and voila! It should match the previous 0x40 checksum value.
Using this knowledge, we can now edit various aspects of the save file including:
Character names
Animals
Items
Buildings (e.g. milking room, seed maker)
Money
The process for making these edits should be fairly straightforward
1. Extract the save data from your GCI file (from 0x44 onwards) and save it to a seperate file (e.g. hashtest.bin)
2. Find the value(s) you want to edit (e.g. money) and edit them
In this case, my money value was previously 999999 (hex = 0F423F). The value seems to be stored at 0x1962e (in hashtest.bin). We’re gonna try changing this to 123456 (hex = 01E240).
3. Calculate a new checksum of your save data using Jacksum (as shown above) by analyzing your seperate save data file (i.e. hashtest.bin)
CRC32_bzip2 checksum of our new data (money = 123456) is 34efd17e
4. Open your original GCI, overwrite with your new checksum at 0x40
5. Overwrite the save data fro 0x44 onwards with your newly edited data (copied from hashtest.bin)
6. Save your new GCI file
Voila!
Update
As an alternative to Jacksum, you can actually calculate the checksum right from within Hex Editor Neo (if you’re using a different hex editor, you’ll need to follow the Jacksum directions above).
Simply go to View -> Tool Windows -> Checksum
Then add, select the “Add Algorithm button to create an algorithm with the following settings:
CRC-32
Initial Value: ffffffff
Polynomial: 4c11db7
XOR Out: ffffffff
Uncheck Reflection In
Uncheck Reflection Out
Name: CRC-32/BZip2
Once saved, simply highlight the affected data in your .gci save file (i.e. 0x44 to the end of the file). Then, select the “Selection Only” option from the Checksum tool window, and the appropriate value should be generated in the CRC-32/BZip2 row.
Voila! You can now modify any data directly within the GCI file, regenerate the checksum (by selecting data from 0x44 to the end off the file), and then insert the new checksum (at 0x40).
I’ve also begun the process of submitting the mod to romhacking.net, so that should be live within the coming days assuming everything goes as planned.
The only aspect that I might address for the lesbian mod would be the demo video that plays if you stay idle on the title screen. Currently the mod uses one of the demo videos from the Japanese release of Another Wonderful Life. This video has a few discrepancies when compared against actual gameplay.
Japanese button text
Some animations don’t match up (i.e. bouncy ponytail)
If you know of anyone who would be interested in helping design some faux cover art for use in emulators like Dolphin, please let me know either on Twitter or via email.
Once I extracted this data (via manually copy/pasting in a hex editor), that I’m was able to feed it into the xxhash64 algorithm. I used QuickHashGUI for this.
To my surprise, this actually worked and the hashes matched!
Extracting the image data from the first image contained in the logo.tpl file (the Marvelous logo) and comparing hash values to the dumped Dolphin texture filename.
I’m going to try creating a QuickBMS script to extract raw image data from TPL files to somewhat automate the process.
Eventually this means that I should be able to generate hashed filenames for every texture on the game’s disc. This bypasses the need to typically play through and manually come across every texture in-game.
Update
I’ve created a QuickBMS script that can take any input TPL file, and output the extracted raw texture data.
endian big
idstring "\x00\x20\xAF\x30"
get filesize asize
get openedFile filename
get numberOfImages long
get imageTableOff long
if numberOfImages == 1
goto imageTableOff
get imageHeaderOff long
goto imageHeaderOff
get height short
get width short
get imageFormat long
get imageAddress long
set name string openedFile
string name - ".tpl"
string name + "_Texture0_"
string name + width
string name + "x"
string name + height
string name + "_"
string name + imageFormat
string name + ".bin"
math filesize - imageAddress
log name imageAddress filesize
else
for i = 1 < numberOfImages
goto imageTableOff
get imageHeaderOff long
get null long
get nexImageHeaderOff long
goto imageHeaderOff
get height short
get width short
get imageFormat long
get imageAddress long
goto nexImageHeaderOff
get null long
get null long
get nexImageAddress long
set imageSize long nexImageAddress
math imageSize - imageAddress
set name string openedFile
string name - ".tpl"
string name + "_Texture"
set texNum long i
math texNum - 1
string name + texNum
string name + "_"
string name + width
string name + "x"
string name + height
string name + "_"
string name + imageFormat
string name + ".bin"
log name imageAddress imageSize
math imageTableOff + 0x08
next i
goto imageTableOff
get imageHeaderOff long
goto imageHeaderOff
get height short
get width short
get imageFormat long
get imageAddress long
set name string openedFile
string name - ".tpl"
string name + "_Texture"
math numberOfImages - 1
string name + numberOfImages
string name + "_"
string name + width
string name + "x"
string name + height
string name + "_"
string name + imageFormat
string name + ".bin"
math filesize - imageAddress
log name imageAddress filesize
endif
Once extracted, these files can be hashed with a tool (e.g. QuickHash GUI) using the xxHash64 algorithm.
Combining the data from the script with the hash will provide you with the full filename that Dolphin would normally generate.
Comparison of BMS-extracted texture data vs Dolphin-dumped files
Once you’ve determined the file hashes, you can extract the textures from your TPL as PNG files using a tool like BrawlBox or Wexos’s Toolbox.
The naming convention will be as follows:
Naming Type – denotes the texture naming scheme used by Dolphin, should always be “tex1”
width x height – dimensions of the original texture, can be found in the file output from the BMS script above
hash – xxHash64 of the raw original texture data (as output from the BMS script once fed through a tool such as QuickHash GUI)
format – original texture image format as named in output from the BMS script above
Output file extention – output image file, should always be “.png”
Here’s a visual demonstration of the file naming convention, and where the different parts can be found.
Extracting a texture to a png image using BrawlBox, using naming information provided by QuickBMS + QuickHash
Update #2
After going through every CLZ, ARC, and TPL file, I beleive I’ve been able to dump/rename (almost) every texture in the game.
There are a total of 4115 unique texture images from Harvest Moon: A Proud Life (lesbian version).
I’ve compiled all of these dumped textures into a Dolphin-compatible pack, which can be downloaded [here].
One item of consideration for the mod is whether or not I should modify Nami’s character model.
Her appearance in A Wonderful Life depicts her with neat short hair. However, her appearance in Another Wonderful Life depicts her with notably messier hair.
Nami’s AWL model (neat hair) vs AnWL (messy hair)
I’m currently running [a poll on Twitter] to look at which model players prefer.
I plan on using the result in each version of the mod (i.e. both A Proud Life and Another Proud Life).
While I’m partial to the neat look, I recognize that that might be due to me growing up with AWL. With that said, the messy look is growing on me.
After a bit of digging into the file formats of A Wonderful Life, I was able to figure out which files contain data for cutscenes.
The files in question are .sb script files. The versions of these files utilized in-game are compressed using CLZ-compression, resulting in .sb.clz files.
There are a few places where these files can be found.
.sb debug scripts at disc:/test/Script/
Unnamed CLZ-compressed versions of the above debug scripts (i.e. .sb.clz files) contained in disc:/test/Script/test.arc
Unnamed CLZ-compressed chapter-specific events (e.g. romance cutscenes, son cutscenes) in disc:/Chapter#.arc
Unnamed CLZ-compressed common events (i.e. can be triggered in any chapter) in disc:/Common.arc
The unnamed Chapter and Common events can be determined by looking at the legend in disc:/test/text/EventOCC.txt. As an example, here is disc:/Chapter2.arc, with it’s corresponding event legend.
Replacing Events with Debug Scripts
Using this knowledge, we can compress some of the debug scripts using Sukharah’s CLZ Tool, then can import them into the Chapter or Common files, replacing a previously-defined event. This is done by right-clicking the intended event in the destination .arc file, then selecting “Replace” from within Wexo’s Toolbox. Then, when the game wants to trigger the normal event, it will trigger the newly replaced debug event instead.
Here is an example where I replaced 8009_link.sb.clz in disc:/Common.arc with the (compressed) debug script 0000_Teleport.sb.clz.
0000_Teleport.sb loading instead of 8009_link.sb
The main downside of the debug scripts is that almost all of the debug text is untranslated Japanese. The above example was translated by myself by modifying debug.mes.
Here is an example using the default untranslated dialog.
Accessing Galen/Nina’s house during Chapter 2
Heart Event Cutscenes
While I could manually extract every bachelorette cutscene from Chapter1.arc and import it to replace 8009_link as above, this would be fairly time consuming. Fortunately, there’s another way.
The test script folder contains a handy script, Launcher_Love.sb.
When compressed, imported, and triggered, this script will open up a menu, from which you can select any of the possible bachelorette cutscenes including heart events, matchmaker scenes, reverse proposals, and successful marriage events.
Here’s an example loading one of Muffy’s heart events.
Muffy Heart Event 4
Note that these cutscenes can only be loaded during Chapter 1. Attempting to load them in any of the later chapters will result in a crash.
Harvest Moon: A Proud Life 