Prof. 9

PWT Editor v0.2.1 got DMCA'd on MediaFire, so here's a reupload that doesn't include any PWT files (seeing as they're all in the Event Gallery already). You can also grab it from the attachment. http://filetrip.net/nds-downloads/utilities/dl-pwt-editor-v0-2-1-f33224.html PWTEditor v0.2.1.zip

Nice work! I've actually been working on the same thing but for different games for quite a while now. It's great to see things moving on the Pokémon e-Reader front as well. CaitSith2's nedcmake and nedcenc can do this for you. Nedcmake takes vpk data and header info, and creates a bin file with header, and can create raw and bmp (!) files as well. Nedcenc can transform bin files to raw and vice versa. Personally I've found nedcenc is a bit more reliable when dealing with multi-card applications. Is there an IRC channel for this?

I believe you just get the opposite gender's trainer. So if you play as Nate, you get Hilda, whereas if you play as Rosa, you get Hilbert.Incidentally, research by the altwfc.net team showed that the very first byte in the tournament data probably determines which games can download the tournament. 0x00 = Black 2, 0x01 = White 2, 0x02 = Both.

I took a quick look at it and here's what I've come up with. Some breakpoints from FireRed US 1.1: 0x080A0840: check_new_height(poke_id, record_ptr) 0x080A06B0: calc_hval(pkm_ptr) 0x080A0784: calc_height(poke_id, hval) 0x08088E4C: get_dex_height(dex_id) 0x080A0754: get_hval_class(hval) The height of the Pokémon is calculated based on the Pokémon's PID and IVs and normalized, then multiplied by the Pokémon species' average height as listed in the Pokédex. The formulas are below. Calculating the hval (^ meaning exclusive OR): a = ((iv_atk ^ iv_def) & 0xF) * (iv_hp & 0xF) b = ((iv_spatk ^ iv_spdef) & 0xF) * (iv_spe & 0xF) hval = (pid & 0xFFFF) ^ (a | (b << 8)) A lookup table is used for normalization: [table] [tr][td]class[/td][td]min[/td][td]base[/td][td]size[/td][/tr] [tr][td]0[/td][td]0[/td][td]290[/td][td]1[/td][/tr] [tr][td]1[/td][td]10[/td][td]300[/td][td]1[/td][/tr] [tr][td]2[/td][td]110[/td][td]400[/td][td]2[/td][/tr] [tr][td]3[/td][td]310[/td][td]500[/td][td]4[/td][/tr] [tr][td]4[/td][td]710[/td][td]600[/td][td]20[/td][/tr] [tr][td]5[/td][td]2710[/td][td]700[/td][td]50[/td][/tr] [tr][td]6[/td][td]7710[/td][td]800[/td][td]100[/td][/tr] [tr][td]7[/td][td]17710[/td][td]900[/td][td]150[/td][/tr] [tr][td]8[/td][td]32710[/td][td]1000[/td][td]150[/td][/tr] [tr][td]9[/td][td]47710[/td][td]1100[/td][td]100[/td][/tr] [tr][td]10[/td][td]57710[/td][td]1200[/td][td]50[/td][/tr] [tr][td]11[/td][td]62710[/td][td]1300[/td][td]20[/td][/tr] [tr][td]12[/td][td]64710[/td][td]1400[/td][td]5[/td][/tr] [tr][td]13[/td][td]65210[/td][td]1500[/td][td]2[/td][/tr] [tr][td]14[/td][td]65410[/td][td]1600[/td][td]1[/td][/tr] [tr][td]15[/td][td]65510[/td][td]1700[/td][td]1[/td][/tr] [/table] Height class is determined from the largest minimum that's less than the hval. Normalized hval calculation: hnorm = base + (hval - min) / size The Pokémon's average height in meters is pulled from the Pokédex data to calculate the individual Pokémon size in meters. In the ROM the height is stored multiplied by 10, hence the division below. hmeter = hdex * hnorm / 10 Finally, the height is converted to inches as such: hinch = hmeter * 100 / 254

This will almost certainly be blocked by Poké Transporter's hack check.

This will never be possible as the game only has room for 4 trainers per tournament in the save file. You will always need at least 3 filler trainers.

It turns out the Pokémon data (including the names), at least the quicksave in-dungeon party data, is compressed by simply removing all unused bits. For instance if there are two variables, one that uses 3 bits and one that uses 4, they're squashed into a single byte. Because of this all the bytes of the names (and other data) are shifted. After un-shifting them you'll get normal characters that you can interpret using the table file. So there's no proprietary character encoding voodoo going on. I haven't looked at it much yet, but here's a quick method I wrote to do the unshifting. It's not optimized but it should be good enough for a proof of concept: http://pastebin.com/aCSaTmh2 To use, load the save file (or the relevant part of it at least) into a Stream, set it to the position of the name and call decode() with the right parameters. Here are some that work: 0x8413: startbit 3, bits 80 (starter's name) 0x8457: startbit 5, bits 80 (partner's name) I'll probably look into this more later. If you want to see for yourself, the routine that decompresses the quicksave party data starts at 0x02059BA0 in RAM. The actual call to the decompression routine to decompress a name is at 0x02059DCC.

You'll have to ask RubenPikachu. Maybe it doesn't get saved?

The tournaments you linked seem to have invalid checksums, so they are detected by PWT Editor and the game as corrupt. This could be due to using a hex editor to make changes, or bugs in the tool(s) you used. Since you used RubenPikachu's program, I can't help you with that; even though DTE was built on top of PWT Editor, it implements its own extra features, and I haven't had any tournaments corrupt on me with PWT Editor.If you really want to import these, use a hex editor to truncate them to 0x1210 bytes and import them as Raw Data in PWT Editor. Yes. Three tournaments is the max that you can fit in a save file.

It's mostly ANSI, but some characters were removed and/or replaced with different characters.Here's a table file: http://www.mediafire.com/?xb0dxr9tl8ed2tp All the bullet characters are graphically the same, and 5B is glitchy. [$NN] denotes a character that the game doesn't support (meaning it's either a regular space, a solid square, or butchers the text display).

Have you tried PWT Editor? If that didn't work either, upload your save file and the tournament you're trying to import.

.NET Framework 2.0 is pre-installed on all versions of Windows from Vista onwards, so it might work out of the box. Otherwise feel free to use the source/documentation and port it to something like Java.

As far as I know, no.

This can happen when your save file is not in the standard format, for example when you're using an emulator such as No$gba (which by default compresses all save files). Try converting your save file to RAW format before you load them.

Nice work, looks like being lazy paid off (jk jk). I would suggest naming it something other than PWT Editor to avoid confusion though.