Platinum Lucario

Updated with MegaMinerd's information

Updated with information from MegaMinerd's research~

Pokémon Mystery Dungeon (WiiWare)
data1_XXXX.bin and data2_XXXX.bin archive information

The files, data1 and data2 are archive binaries, the "XXXX" indicated in the file name, is the game code for the files, which can vary depending on the version (eg. data2_WPAJ.bin).

Since data1 and data2 archive binaries are compressed with the AT7 compression algorithm, the archives must be decompressed before any data can be extracted.

But here's how the decompressed data1 and data2 files are structured:

Part 1 - Pointer and file name table
Part 2 - Actual data of all files

Part 1 - Pointer and file name table

This data contains all the pointers of all files, as well as their file names.

Each table row consists of:

Namespace data

This data contains the filename data, and all filenames can only be in ASCII format. Filenames can only be a maximum of 19 characters long, every filename always ends with a 00 value byte and must be in the namespace data in order for it to function properly. Anything after the 00 valued byte through to offset 0x1B will be what we'll refer to it as "junk text".

Junk text is the remains of what used to be a previous file that existed on that entry before it was overwritten by a different filename, either through renaming or removal of a file during development. So essentially it would be development leftovers. It's possible to create a program that would re-replicate the same type of junk data results though file namespace overwriting. For example, we have a file called adev_app_icon.tex, then we name it "app_icon.tex", it would look like this: "app_icon.tex tex". Alternatively if we renamed or removed "bg_event.sed", the file name in the table row below it called "bg.swd" would take priority and overwrite the text (and file offset data) on that table row and the namespace would look like "bg.swd t.sed", then if the file was renamed again to "b.swd", it would be "b.swd  t.sed" which would look like "62 2E 73 77 64 00 00 74 2E 73 65 64 00 00 00 00 00 00 00 00" in hex. This means that an addition of a new file or renaming a file in the archive has the potential to create junk data, overwriting text in an existing entry while leaving some of it there.

Part 2 - Actual data

Each file data fits into this area as followed:

First - File data
Second - Line break filling

Line break filling

This data occurs between each file to show that its sepparate data, it can either be 16 or 32 bytes long, the FF value marks the end of the file data and start of the filling data, all the rest of the filling data is 00 value bytes, after that, the next file begins. The end of the entire data1 or data2 archive is marked with a FF value byte as well, but without the 00 values after it. 

Quote

MegaMinerd: Each file is terminated with FF then padded to an offset divisible by 32 using 00. Evidence: files have many different lengths, for example dgMapTxt00.txt has a length of 0x0562.

However, every pointer is divisible by 32.

Also, I believe 00 00 00 00 7C is the data root terminator and the data root is then also padded to an offset divisible by 32.

32-byte filling data:

FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

16-byte filling data:

FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Credits:

MegaMinerd - For most of the research into filling data

Pokémon Mystery Dungeon (WiiWare)
data1_XXXX.bin and data2_XXXX.bin archive information

The files, data1 and data2 are archive binaries, the "XXXX" indicated in the file name, is the game code for the files, which can vary depending on the version (eg. data2_WPAJ.bin).

Since data1 and data2 archive binaries are compressed with the AT7 compression algorithm, the archives must be decompressed before any data can be extracted.

But here's how the decompressed data1 and data2 files are structured:

Part 1 - Pointer and file name table
Part 2 - Actual data of all files

Part 1 - Pointer and file name table

This data contains all the pointers of all files, as well as their file names.

Each table row consists of:

Namespace data

This data contains the filename data, and all filenames can only be in ASCII format. Filenames can only be a maximum of 19 characters long, every filename always ends with a 00 value byte and must be in the namespace data in order for it to function properly. Anything after the 00 valued byte through to offset 0x1B will be what we'll refer to it as "junk text".

Junk text is the remains of what used to be a previous file that existed on that entry before it was overwritten by a different filename, either through renaming or removal of a file during development. So essentially it would be development leftovers. It's possible to create a program that would re-replicate the same type of junk data results though file namespace overwriting. For example, we have a file called adev_app_icon.tex, then we name it "app_icon.tex", it would look like this: "app_icon.tex tex". Alternatively if we renamed or removed "bg_event.sed", the file name in the table row below it called "bg.swd" would take priority and overwrite the text (and file offset data) on that table row and the namespace would look like "bg.swd t.sed", then if the file was renamed again to "b.swd", it would be "b.swd  t.sed" which would look like "62 2E 73 77 64 00 00 74 2E 73 65 64 00 00 00 00 00 00 00 00" in hex. This means that an addition of a new file or renaming a file in the archive has the potential to create junk data, overwriting text in an existing entry while leaving some of it there.

Part 2 - Actual data

Each file data fits into this area as followed:

First - File data
Second - Line break filling

Line break filling

This data occurs between each file to show that its sepparate data, it can either be 16 or 32 bytes long, the FF value marks the end of the file data and start of the filling data, all the rest of the filling data is 00 value bytes, after that, the next file begins. The end of the entire data1 or data2 archive is marked with a FF value byte as well, but without the 00 values after it. 

Quote

MegaMinerd: Each file is terminated with FF then padded to an offset divisible by 32 using 00. Evidence: files have many different lengths, for example dgMapTxt00.txt has a length of 0x0562.

However, every pointer is divisible by 32.

Also, I believe 00 00 00 00 7C is the data root terminator and the data root is then also padded to an offset divisible by 32.

32-byte filling data:

FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

16-byte filling data:

FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Credits:

MegaMinerd - For most of the research into filling data

AT7 File Container Format

Documentation for...

Pokémon Mystery Dungeon: Keep Going! Blazing Adventure Squad
Pokémon Mystery Dungeon: Let's Go! Stormy Adventure Squad
Pokémon Mystery Dungeon: Go For It! Light Adventure Squad

Or by it's other names...

Pokémon Mystery Dungeon: Forward! Adventurers of Flame
Pokémon Mystery Dungeon: Let's Go! Adventurers of Storm
Pokémon Mystery Dungeon: Aspire! Adventurers of Light

All on WiiWare~

Hello everyone, I've actually been making some progress with the research into the AT7 File Container format, here's what I have currently documented:

As of now, I've done some huge research into the AT7 Container format
and I have made some progress (finally). The AT7 format is split into
multiple segments and sectors. Each segment has a 6-byte long header, both which
indicate it's ID and size of the segment. AT7P counts the header, where as
AT7X does not. Like AT4PX or PKDPX, the segment headers have control flags in
it's header, but it is only determined within the first AT7P segment header .AT7P segments
have only been examined with compressed data sizes of less than 49,158 bytes. It is unknown
if the AT7P segments can go higher than 49,158 bytes

AT7X segments have uncompressed data, but can only be 49,158 bytes long.

Now here's some examples of where you can find the AT7 Segments for data2_WPAJ.bin:

(This would keep going on and on, can't post all of the offsets
since it would take too long, but I am posting about AT7E though)

Segments

AT7P segments can be any size! The size of the segment is always stated at offsets 0x4-5
in little endian. Where as AT7X is always at a fixed size and have uncompressed data,
therefore meaning that offsets 0x4-5 will only count the uncompressed data, but not the
header. The entire AT7 file container is split into sectors, containing 131,072 bytes
(20000h) each. The AT7E segment always indicates the end of the archived files and then
the free space comes after the AT7E header.

Compressed data works as follows: After the compressed size bytes, it begins with
each of the blocks. Each block starts with a flag byte. As it goes from MSB to LSB,
if the bit is set, it reads, takes the next byte from the input and moves it to the
output completely unchanged. If the bit is clear, it reads a 2-byte big-endian
control code. The top nybble is a repeated string length of 3. The remaining bits
are a 12-bit negative offset of the most recent occurrence of the string to repeat.

AT7P Segment Info

* - These bytes count both the header and compressed data

As explained before, AT7X segments are a fixed size of 49,158 (C006) each, counting the
header as well. Unlike with AT7P, AT7X segments have uncompressed data, which means that
the data can be read without any need to decompress. Since AT7X can only hold data sizes
of 49,152 bytes, any data contained has to be exactly 49,152 bytes. This can often be
used for textures or certain images or any data that has no data that can be re-replicated
in any way, but must be exactly 49,152 bytes within parts of large files.

AT7X Segment Info**

** - It always has a fixed length of 49,158 bytes (C006h) each
*** - The bytes are always 00 C0 (C000h), which means it is always 49,152 bytes long in decimal. Unlike AT7P, these bytes only count the compressed data,  but not the header

The AT7E segment marks the end of the container and will fill any remaining bytes within a
sector with byte values of "45" (or "E" in ASCII).

AT7E Segment Info****

**** - This segment always indicates the end of the AT7 container, before the free space
***** - These bytes can be any size, the entire AT7 container is made of blocks that are 131,072 bytes (20000h) each, and all free space bytes have a value of "45". The size of the free space will depend on how much space the last block has left over. For example, the last block of data2_WPAJ.bin only has AD7C (44,412 bytes) of data left in it 20000h - AD7Ch = 15284h (86,660 bytes), which means data2_WPAJ.bin only has 86,660 bytes of free space with each byte value of "45"

Sectors

Sectors are sections of the container that make up the file, like how sectors work on a Hard Disk Drive. Each sector is 131,072 bytes long (20000h). There can be multiple sectors within an AT7 container, for example, data2_WPAJ.bin contains 166 sectors (A6 in hexadecimal). But some contain as little as just 1 sector (such as data1_WPAJ.bin). If the last sector of the AT7 container has free space, the end of the data will be flagged with the AT7E segment, beginning the start of the free space.

Special thanks to:

MegaMinerd - For discovering and explaining about how the compressed data works and explaining that AT7X data isn't compressed

AT7 File Container Format

Documentation for...

Pokémon Mystery Dungeon: Keep Going! Blazing Adventure Squad
Pokémon Mystery Dungeon: Let's Go! Stormy Adventure Squad
Pokémon Mystery Dungeon: Go For It! Light Adventure Squad

Or by it's other names...

Pokémon Mystery Dungeon: Forward! Adventurers of Flame
Pokémon Mystery Dungeon: Let's Go! Adventurers of Storm
Pokémon Mystery Dungeon: Aspire! Adventurers of Light

All on WiiWare~

Hello everyone, I've actually been making some progress with the research into the AT7 File Container format, here's what I have currently documented:

As of now, I've done some huge research into the AT7 Container format
and I have made some progress (finally). The AT7 format is split into
multiple segments and sectors. Each segment has a 6-byte long header, both which
indicate it's ID and size of the segment. AT7P counts the header, where as
AT7X does not. Like AT4PX or PKDPX, the segment headers have control flags in
it's header, but it is only determined within the first AT7P segment header .AT7P segments
have only been examined with compressed data sizes of less than 49,158 bytes. It is unknown
if the AT7P segments can go higher than 49,158 bytes

AT7X segments have uncompressed data, but can only be 49,158 bytes long.

Now here's some examples of where you can find the AT7 Segments for data2_WPAJ.bin:

(This would keep going on and on, can't post all of the offsets
since it would take too long, but I am posting about AT7E though)

Segments

AT7P segments can be any size! The size of the segment is always stated at offsets 0x4-5
in little endian. Where as AT7X is always at a fixed size and have uncompressed data,
therefore meaning that offsets 0x4-5 will only count the uncompressed data, but not the
header. The entire AT7 file container is split into sectors, containing 131,072 bytes
(20000h) each. The AT7E segment always indicates the end of the archived files and then
the free space comes after the AT7E header.

Compressed data works as follows: After the compressed size bytes, it begins with
each of the blocks. Each block starts with a flag byte. As it goes from MSB to LSB,
if the bit is set, it reads, takes the next byte from the input and moves it to the
output completely unchanged. If the bit is clear, it reads a 2-byte big-endian
control code. The top nybble is a repeated string length of 3. The remaining bits
are a 12-bit negative offset of the most recent occurrence of the string to repeat.

AT7P Segment Info

* - These bytes count both the header and compressed data

As explained before, AT7X segments are a fixed size of 49,158 (C006) each, counting the
header as well. Unlike with AT7P, AT7X segments have uncompressed data, which means that
the data can be read without any need to decompress. Since AT7X can only hold data sizes
of 49,152 bytes, any data contained has to be exactly 49,152 bytes. This can often be
used for textures or certain images or any data that has no data that can be re-replicated
in any way, but must be exactly 49,152 bytes within parts of large files.

AT7X Segment Info**

** - It always has a fixed length of 49,158 bytes (C006h) each
*** - The bytes are always 00 C0 (C000h), which means it is always 49,152 bytes long in decimal. Unlike AT7P, these bytes only count the compressed data,  but not the header

The AT7E segment marks the end of the container and will fill any remaining bytes within a
sector with byte values of "45" (or "E" in ASCII).

AT7E Segment Info****

**** - This segment always indicates the end of the AT7 container, before the free space
***** - These bytes can be any size, the entire AT7 container is made of blocks that are 131,072 bytes (20000h) each, and all free space bytes have a value of "45". The size of the free space will depend on how much space the last block has left over. For example, the last block of data2_WPAJ.bin only has AD7C (44,412 bytes) of data left in it 20000h - AD7Ch = 15284h (86,660 bytes), which means data2_WPAJ.bin only has 86,660 bytes of free space with each byte value of "45"

Sectors

Sectors are sections of the container that make up the file, like how sectors work on a Hard Disk Drive. Each sector is 131,072 bytes long (20000h). There can be multiple sectors within an AT7 container, for example, data2_WPAJ.bin contains 166 sectors (A6 in hexadecimal). But some contain as little as just 1 sector (such as data1_WPAJ.bin). If the last sector of the AT7 container has free space, the end of the data will be flagged with the AT7E segment, beginning the start of the free space.

Special thanks to:

MegaMinerd - For discovering and explaining about how the compressed data works and explaining that AT7X data isn't compressed

I certainly would've voted for "AT7P Editor for WiiWare Pokémon Mystery Dungeon", if it was there. But I decided to choose .Net 3DS Toolkit, since it would be much better to see it cross-platform.

While we have been doing a lot of research on Explorers, but there's also another game I've been interested in researching lately.

Since Pokémon Mystery Dungeon: Forward! Adventurers of Flame, Pokémon Mystery Dungeon: Let's Go! Adventurers of Storm and Pokémon Mystery Dungeon: Aspire! Adventurers of Light never got released outside of Japan. Little has been documented about these games, but they use very similar file formats to the Explorers ones. So the Adventures ones also could be included in PMD2 as well, since they're part of the same generation, but instead released as WiiWare on the Wii.

One particular file format that drew my attention, was the AT7P file container format. I haven't done much research on it, but it is an archive format that also uses compression (possibly lz77 or yaz0).

Unless we're able to extract and repack this file format, there won't be much hope of a translation project occurring anytime in the future. Which is why I'm interested in researching this file format. So far from what I've found apart from it's header ID "AT7P" at 0x0-2, I've found that free space within this file is indicated by every byte as "45". It could be related to some of the file container formats in the Explorers (such as AT4PX and AT4PN). I'll need to do some research, but if anyone else wants to, you'll need a program called ShowMiiWads in order to unpack the Wii .app files. There's two of these AT7P files contained in the app, they're under the names "data1_WPAJ.bin" and "data2_WPAJ.bin"

In the compressed data, I can see that data1_WPAJ.bin contains only a data.ini with some version info stuff inside data.ini. But it seems like data2_WPAJ.bin contains all the game data in it, only thing left to do, is to have a solution to unpack and repack the files. Just from looking at it, it seems to contain many SIR0 files as well.

36 minutes ago, evandixon said:

There used to be a view for it (not sure why it's not displaying now), although you can use the Image -> Import/Export menu items to convert to and from PNG. I just tested it with the world map.

  Reveal hidden contents

 

Yep, exporting and importing still works.

But there's also some images that are not rendered correctly in Sky Editor. I'm pretty sure it is their native image format. But just the game's engine renders it differently.

5 minutes ago, evandixon said:

I'll see what I can do. It might be a while, what with IRL work to do and Legend of Zelda: Breath of the Wild. (Although MD editing is far more interesting than IRL work, so there's really no telling when I'll find time for it.)

I can understand that. I too have been playing so much of BotW as well. And I've also noticed that CTE/IMG functionality is broken in GTI. Using SkyEditor.ROMEditor.MysteryDungeon.PSMD.CteImage variable results in the no available UI message. While it kinda worked in legacy builds (with some images loaded incorrectly), I may need to do some research into the CTE image format. While it may display incorrectly, there's a chance that it may be in some compressed format, or it may rely on the game's engine to move the pixels around.

17 minutes ago, evandixon said:

IIRC, Sky Editor sorts strings by the string ID, rather than preserving the order in the file. When editing a message.bin file alongside a script, I usually just press the "Script Sort" button, which looks at all the string references in the script and sorts the strings by order of reference (meaning dialogue is displayed in the order it's presented in the story).

A string ID is a 32 bit integer, which Sky Editor displays as signed because unluac, the best Lua decompiler I've seen, displays them as signed numbers, so it's easier to look them up.  I personally would prefer it to use unsigned, but I guess it doesn't really matter.

I'm not sure what you mean by some entries not having a number column, I mean, I don't remember seeing anything like that.  Are you sure you're using the latest version?  And here's the repo in case you're looking at the old one.

Ah, thank you. I'm now using the latest version, and it seems to me that I can't seem to see anything where I can sort it into the order of the file displaying from top to bottom. Usually having something like that usually makes it more easier for me to look through the files and see which ones are in the Adventure Hints category and so fourth.

And what I meant by having a number column, was actually to do with how the file is read from top to bottom, so it can be used alongside ID and Entry columns as well.

Alrighty, I've done some research into the SIR0 format on common.bin and 54.sir0, and I've noticed that the text in files, as well as it's scripts, are displayed in the right order when viewed from a Hex Editor, but when viewing from Sky Editor (a program that hasn't had any changes to it's code in over a year now), it displays any text entries in an incorrect order. Normally, it should also have the number of each entry from the start of the file, to the end of the file. But this is not the case with Sky Editor, it doesn't have a number column for each entry.

And I've noticed an oddity, some of the IDs in the list are displayed with a negative value. Are they meant to display a negative value? If so, then the ID might not be the problem.

Either way, text editing in both GTI and SMD are out of order, and something needs to be fixed with ROMEditor.FileFormats.MessageBin. If you'd like, I could dig into Sky Editor's code and see what seems to be wrong with the ROMEditor.FileFormats.MessageBin variable.

I am currently in the process of datamining Gates to Infinity. However, I've come across a file type called .img, which displays 2D images, such as text, textboxes and main menu artwork. Since I have no knowledge of programming, I can't create a program to convert the file type. But I have read up on Megadrifter's post on how the file format operates, unfortunately I'd need programming knowledge if I was to create a program to convert it.

Welcome back! It's been a long time since I've last come here and posted. I never would've expected the forums to be compromised by a malware attack. The worst thing about malware attacks... is that it encrypts files, rendering them completely unusable. I honestly hope nothing like this ever happens again. It would be horrible to lose more data. Dx

Anyways, I'm glad to see the forum up and running again. ^^

Great job there ! I remember someone saying the english logo was too big but it worked ! Thank you !

All it needed was a bit of scaling down the logo to be the exact size as that of the Japanese logo... and that's was it. As you can see, the original official English Pokémon Black/White Version had the logo pretty small, it had to fit in the 256x128 pixels margin. The image had to include both the checkered pattern as well as the "Pokémon Black Version" logo, as they both had to fit in the 256x128 pixels margin. Same thing applies for the Pokémon Black Version 2 logo, there is no way that even developers working for Nintendo themselves would be able to bypass those margins and go between them.

'Cause here's the thing... the NCGR files can only count higher in this pattern: 8, 16, 32, 64, 128, 256, 512, 1024 ect. It's just like the sizes in the .nds files themselves.

Alright everyone, if any of you need to use the official English logos for this translation project, I have created them in NARC files. I will indeed also be putting up a guide on how to edit the NSCR files here. Please be sure to replace the NARC in a/0/2/6, I have one for Black 2 and one for White 2. Anyways, here it is: https://dl.dropbox.com/u/90415813/titlescreen.zip

And I am honored to contribute to this project with giving you all the official English logo title screens. ^^

I've been thinking about importing the name imput screen from Black/White into Black2/White2. Does anyone know where you can find the data for changing the name imput screen? I wonder if it's coded in the ARM9.bin or the overlays? 'Cause I'd really like to learn how to find the data for the name imput screen, so then I can copy and paste the data into Black 2 and White 2.

I'm a bit confused as to why you would want to translate it when there are already perfectly good English Pokemon Red ROMs all over the internet?

I think he means the Japanese Pokémon Red ones. The real English Pokémon Red and Blue are edited versions of the Japanese Pokémon Blue, it's the differences between those.

Hi, I'm currantly looking for an Action Replay code for Pokémon Black (IRBO) that can bypass the problem with not gaining EXP during battle and a walk through walls code that works in the exact same way as the Japanese version that is not permanent when you save. I'm looking for no EXP gain bypass code that is not permanent whenever you save the game and will go back to not gaining EXP whenever you turn off the code. I know there's one that does that sort of thing in the Japanese version of Pokémon Black (IRBJ), but not the English one. I've done several attempts to change the code used for No$GBA (used for bypassing the error screen) and tested it out... but the only results I get... is freezing/crashing. I am using DeSmuME, btw. Just wondering if anyone has a code that works the same way as what it does in the Japanese version? OK... as for the Walk Through Walls code that is found on the codejunkies website... it causes all trainers to not be able to battle you and I've found that no Pokémon start shaking in the grass, shadows, bubbles or dust appear when you use the walk through walls code from the codejunkies website, so I'd like to request one that works in the exact same way. Thanks for reading!

~Davin (aka Platinum Lucario)

Well, 'twas only yesterday I learned how to change the logo, but guess what? I can also change the palette as well, I've managed to insert the official logo in, however... there is one problem... the NSCR file makes the top part of the word "Version" appear at the top of the screen. Like what I showed on The PokéCommunity forums in a tutorial that I typed up yesterday. If we manage to fix it up, then I'm sure the logo will be working perfectly in the translated version.

Here's the screenshot:

If anyone knows about how to change the size of the image limitation or the NSCR file, please PM me and tell me about it. Thanks!

There have been many questions about it, indeed I am one of those people who wish to know how to do it.

I'm using CrystalTile2, and I got up to exporting the Pokémon Black logo on Tahaxan using the NCGR.l, NSCR.l, and NCLR files. Now what do I have to do next? Please tell me, because I have not found a valid responce from any other thread on the forum. All they just say is "use CrystalTile2" and that's it. No explanation on how to use it to replace the title screen logo or how to put it in the game. When I used CrystalTile2, I tried to get the title screen logo in perfect possitioning, I tried changing the thingy in preferences to Map, it then went to just a single tile, I tried everything I could to get it in perfect possition. Someone please tell me how to get it in perfect possitioning, and how to replace the logo, please tell me NOW! I really want to know how to.

Hi SCV, I have a suggestion for the map editing, there is a file called OpenGL.dll which supports 3D objects. That could become useful in displaying the map layout and such.

However, I have noticed that all the map layouts are all put in one big map (which is the world map). Even there's a load of space for maps at the top of the world map (which is off the town map when you look at it). So basically you'd probably know this already, but it is true that every square (map layout or part of town) on the world map is 32x32 blocks. So don't go thinking that a town is just one whole map, it's either made up of 1, 2(only in HG/SS), 3, or 4 squares. So basically in the development, they edited one square, not many at a time. But the towns were put in a catergory. Say for instance, you're editing Jubilife City in D/P/Pt or Goldenrod City in HG/SS, you'd have to edit one of the four squares that make up the city altogether. Any objects have a set, just like in the 3rd generation, so which means if you go into an area with a different object set, it won't be changed unless you exit and re-enter through a warp point. There are two object sets, it seems. And yes, HG/SS will be exactly the same as D/P/Pt.

Some of you may know me, some of you may not know me. I'm the person who appeared on PokéCommunity once. As well as appeared on other forums too. For those who do not know me. Well, what can I say about myself?

My name's Davin, I'm a person who is fond of a place called Xat.com. Which is a chatbox site. I've been into ROM Hacking even before I ever came to PC. However, over time I got bored of creating 3rd generation hacks (which I never made one anyways). So now I'm into 4th generation ROM Hacking. Which is most likely I would be the one in hand for giving advise on Map layout objects and all that. In case you're all probably wondering where I got the avatar from, I got it from a friend of mine on Xat.com, her name is Azzy. It's a really nice avatar too.

So, in I go... I guess.