Guest Posted September 6, 2017 Posted September 6, 2017 (edited) Update from 9/15/2017: Thanks for all the contributions so far, I confirmed that DeSmuME emulates the migration from Gen 3 to Gen 4 very well. I will still do some more tests and check if bugs happen but so far I couldn't see anything that differs from a Pokemon that was migrated on a real DS. From my standpoint what has been said about it are rumors and I want to put these rumors into the land of the myths by confirming the real Trash Bytes. This makes my former plan of providing information for an "Pal Park Editor" obsolete... so I decided to change the subject of this Thread. Instead I would like to collect this data for a perfect legality analysis of migrated Pokemon from Gen 3 and Gen 4. This might also help to determine wether a migrated 3rd Gen Event Pokemon to Gen 4 is hack, at least to a higher percentage. As you might know, many 3rd Gen Event Pokemon had been migrated to Gen 4 when the DS Games were released... At least in the communities of the west, 4th Gen files were very popular back in the days. Between these Events some very rare ones that are impossible to find as Gen 3 files. Links:https://projectpokemon.org/wiki/Trash_Bytes#Migrated_via_Pal_Park Attached Files for the Research: Pal Park Research save files (Gen 4).7z Pal Park Research save files (Gen 3).7z Edited September 17, 2017 by ajxpk Subject changed.
theSLAYER Posted September 6, 2017 Posted September 6, 2017 @Sabresite remember I mentioned today/yesterday that Pal Park having false Trash Bytes on Desmume? XD Also @ajxpk I can't say for certain, but based on my usage of Pal Park editing on Pokesav, I think it's already in Gen 4 format at that point. (which if that's true, if you drag it in like that, there will not be the appropriate trash bytes, as those slots hold pokemon that already have been imported, just not officially "in your box". that's pretty much pointless, unless your plan is for PKHeX to give the correct trash bytes. Anyway, this entire point hinges on whether that above statement is true)
Sabresite Posted September 6, 2017 Posted September 6, 2017 @ajxpk, as I mentioned to @theSLAYER, the trash bytes are different because stack handling is 'approximated' and most likely not reused in the same way. 1
Guest Posted September 6, 2017 Posted September 6, 2017 (edited) Yeah, that's the whole plan actually. My first idea was just to implement correct trash bytes in the pk3 to pk4 conversion. But then I thought why not having a Pal Park feature in PKHeX? Edit: No, actually I think there was a little misunderstanding, I just saw it now. Of course Trash Bytes have to be added by us that's what the Research is for, but you propably already know it. Btw. Pokesav had an Pal Park Editor? Edited September 6, 2017 by ajxpk
Sabresite Posted September 6, 2017 Posted September 6, 2017 I never mapped out proper soul silver/heart gold trash bytes. Since emulators don't work properly, we have to use flash carts and legit carts. Anyone up for the challenge?
Guest Posted September 6, 2017 Posted September 6, 2017 (edited) 30 minutes ago, Sabresite said: @ajxpk, as I mentioned to @theSLAYER, the trash bytes are different because stack handling is 'approximated' and most likely not reused in the same way. Yeah, makes sense. I think you told me about this before. 20 minutes ago, Sabresite said: I never mapped out proper soul silver/heart gold trash bytes. Since emulators don't work properly, we have to use flash carts and legit carts. Anyone up for the challenge? I have hope that melonDS will do the job better. The developer is doing a great job in making things as accurate as possible. So there is a good chance I think that it will be done correctly. That's of course if it's implemented. At least unlike in DeSmuME's case the developer doesn't hates Pokemon. I'm up for it! We just need someone who migrates some Pokemon on real hardware for us... Edit: I know it makes sense having this under "Save Research & Development" but why was this Thread moved away from the PKHeX section? Anyways... Edited September 6, 2017 by ajxpk
Sabresite Posted September 6, 2017 Posted September 6, 2017 I have a Fire Red and Soul Silver US cart. The other languages will have to be flash cart. Let's start by prepping saves in both GBA and NDS format. We need them with nicknames of just "A" I feel like I am in 2009 again. 1 1
Guest Posted September 6, 2017 Posted September 6, 2017 We don't have to rush this. Let's see if we can find someone who can help us with the other versions.@HaxAras What do you have in terms of Gen 4 games? Any chance you could do some pal parking for us?
HaxAras Posted September 6, 2017 Posted September 6, 2017 (edited) I'd be happy to. I have English and Japanese SoulSilver and English Heart Gold. I have Diamond, Pearl and Platinum in English and Japanese. gen 3 I have English, Japanese, Spanish and French carts. I could just throw in some cross language Pokémon as I've been meaning to experiment with that more anyway. I don't have a complete save on my JP SS but I could just write my HG save to it. Do you need me to migrate anything in particular or just Pokémon with a nickname of A? Spoiler Diamond: German Colosseum shadow Mon. Eng Emerald egg Eng Ruby egg JP Ruby egg JP Emerald egg Spanish Ruby egg JP Soul Silver Eng, JP, French, Spanish wild encounters Spanish shadow Mon German shadow Mon. @ajxpk I discovered an exploit a few years ago that allows you to migrate as many times as you want from Diamond and Pearl. You need 2 GBA carts. You change the date on your DS to 2 days ahead. Insert the dummy cart, try to migrate and make the game/DS synq. Then insert the cart to be migrated from and migrate normally. Then change the date to 2 days ahead and repeat. Edited September 6, 2017 by HaxAras
Guest Posted September 6, 2017 Posted September 6, 2017 Great. Would be nice if you could migrate Pokemon with the nickname "A" to HeartGold/SoulSilver and Platinum. Not sure if Platinum is necessary, but I would like to take a look at migrated Pokemon there as well. In the meanwhile I will prepare save files for the other european versions, except if there is someone who is offering to help us with these version. I'm not sure what exactly is needed to trigger the opening of the Pal Park other than beating the Pokemon league, so any save file that is ready to migrate Pokemon is appreciated. What we still need is HG/SS FRE/GER/ITA/SPA and Gen 3 save files of each language.
HaxAras Posted September 6, 2017 Posted September 6, 2017 2 minutes ago, ajxpk said: What we still need is HG/SS FRE/GER/ITA/SPA and Gen 3 save files of each language. I should have Spanish, French, Japanese and English Ruby saves. Japanese, English and Spanish Emerald saves Japanese Sapphire. I can donate my HG save and I can migrate from Platinum. 1
Guest Posted September 6, 2017 Posted September 6, 2017 I just remembered that I still have European 3rd Gen save files from older researches. So all we need are the 4th Gen save files. They're the most problematic anyway since we need to have the Pal Park being unlocked.
Guest Posted September 8, 2017 Posted September 8, 2017 I just want to inform you that I prepared some European HGSS save files. We should have everything for HGSS now.
HaxAras Posted September 9, 2017 Posted September 9, 2017 Sorry for the delay. Somebody asked me to go somewhere with them when I was finishing up this project in gen 3 and I forgot about it. Spanish: Feebas (Hatched, English origin game) Absol - Captured, Spanish Emerald English: Feebas (Hatched, English origin game) Tyrogue (Hatched, English origin game) - I messed this one up. It was supposed to be a captured mon. Japanese: Feebas (Hatched, English origin game) Skitty - (Possibly hatched - was supposed to be a captured mon) These have been migrated from my Platinum save, immediately after migration. 236 - A - F2E71B9DC06A.pk4 300 - A - 9AA186459CF4.pk4 349 - A - 5D37C7C80411.pk4 349 - A - 8DE17E5C287F.pk4 349 - A - 248649F49DC6.pk4 359 - A - CADB7FF26B34.pk4
Guest Posted September 10, 2017 Posted September 10, 2017 Thanks. Just for the record. This is English Platinum Version now, right? All in order? We need to know the exact order how they were pal parked. This is actually confusing. I was expecting a more consistent result. But maybe it's because I see trash bytes of migrated Pokemon for the first time. Could you migrate more Pokemon for us? Btw. It would be better if they're all from the same region, because Japanese A isn't the same as English A if you know what I mean. Not that if it matters much but it's easier to look at it.
HaxAras Posted September 10, 2017 Posted September 10, 2017 (edited) English Platinum - Migrated from an English Emerald. English Tyrogue and Feebas, Spanish Absol and Feebas and Japanese Feebas and Skitty. Japanese Pearl Migrated from a Japanese Sapphire Male Pooch, Male Wurmple, Female Pooch, Female Wurmple, Female Zigzagoon, Male Zigzagoon 265 - A - AD55DCAC5A3D.pk4 261 - A - 0D255B94E8C0.pk4 261 - A - EA972015597B.pk4 263 - A - 108CBD7EEAF8.pk4 263 - A - B0A59937DD2F.pk4 265 - A - 5A89380624E1.pk4 I'll do English Emerald to English Heart Gold later. Followed by English Sapphire to Heart Gold. Edited September 10, 2017 by HaxAras
Guest Posted September 10, 2017 Posted September 10, 2017 Thanks. Looks beautiful. DP JP has pretty clean trash bytes. I'm curious to see HGSS JP. Btw. I finished preparing the Platinum save files. I think I will upload these save files in this thread later, then everyone who wants to help with the research can use them.
HaxAras Posted September 11, 2017 Posted September 11, 2017 NA/English Emerald to NA/English Heart Gold. I'll try to convert my JP Heart Gold save to SS and write it to my JP SS cart tomorrow after work. If that works, I'll migrate 6 more from my JP Sapphire. 276 - A - A8D2244773E7.pk4 293 - A - A711867475BA.pk4 300 - A - 03447AE0C3BF.pk4 309 - A - 9D3B1694C150.pk4 345 - A - 9AD0DE5C97DE.pk4 261 - A - BC65F8672B30.pk4 1
Guest Posted September 11, 2017 Posted September 11, 2017 (edited) Thank you! I finally uploaded the save files for this Research. Sorry for the long wait. Please feel free to use them. Pal Park Research save files (Gen 3).7zPal Park Research save files (Gen 4).7z Edit: Just checked your new files. Looks like they're in random order. @HaxAras in which order did you Pal Park them? That's very important otherwise I can't look further into the random trash bytes. edit: Sorry, I didn't saw the Screenshot. Thanks again! Edited September 11, 2017 by ajxpk
Guest Posted September 12, 2017 Posted September 12, 2017 (edited) OK, this was damn easy. Statement from 9/15/2017: Not as easy as I hoped... As an example let's take the Nickname Strings from Pokemon uploaded from @HaxAras:Pokemon Platinum ENG 1st Pokemon 2B 01 FF FF 00 00 00 00 42 00 00 00 00 00 00 00 C8 19 0C 02 E0 FF 2nd Pokemon 2B 01 FF FF 05 00 00 00 C8 A9 28 02 34 E1 27 02 4D 75 07 02 00 00 3rd Pokemon 2B 01 FF FF 05 00 00 00 B4 AA 28 02 34 E1 27 02 4D 75 07 02 00 00 4th Pokemon 2B 01 FF FF 1B 00 00 00 A0 AB 28 02 34 E1 27 02 4D 75 07 02 00 00 5th Pokemon AC 00 FF FF 05 00 00 00 8C AC 28 02 34 E1 27 02 4D 75 07 02 00 00 6th Pokemon AC 00 FF FF 05 00 00 00 78 AD 28 02 34 E1 27 02 4D 75 07 02 00 00 The Trash Bytes of the 1st Pokemon are static as most people who ever messed with it might already know. Nothing special about it. What's interesting are the Strings from Pokemon #2 - #6. Take a loot at what I marked blue at String Offset 4. It looks kinda random, right? The truth is this isn't the case at all actually. It's damn simple. These are the LV of these Pokemon. It's appearently what's stored into the Met Location. I think this needs no further explanation and @HaxAras gave us good examples to visualize this. The Pokemon he gave us have the LV 12, 5, 5, 14, 5 and 5. Now let's move on with what I marked in Offset 8-9 in red. These are Offset values from the Pal Park Team Offsets of the English Platinum Version, however the number variates between Migration Sessions. The distance between each Pokemon however is always 236 Bytes, that's the size of the data of a Party Pokemon. To see what I mean you have to read these numbers as little-endian. Or you can just take the 1st one as le and add 236, you will get the same numbers: 0xA9C8 + 236 = 0xAAB4 + 236 = 0xABA0 + 236 = 0xAC8C + 236 = 0xAD78 Of course aren't the full Offsets, just the lower 16bits. The full Offsets would be: 0x0228A9C8 0x0228AAB4 0x0228ABA0 0x0228AC8C 0x0228AD78 I admit that this was no rocket science... The rest of the string looks completely static, but it should be said that there are two more Offsets in these Strings. In this example the Offsets are: 0x0227E134 and 0x0207754D So with that in mind, there is no randomness at all, but it has yet to be confirmed what these Offsets are... Also I will have to check migrated Pokemon of other Versions to see if they're all exactly the same. For now I can confirm this for both English Platinum and English HeartGold. I would prefer to migrate Pokemon with blank names though, which would allow us to get a better view and I would like to document the complete Strings with all 22 Bytes if possible. Update from 9/15/2017: I marked the 2nd Offset in green now. It looks fix in one session, it's related to the Offset in red therefore differs. The distance between the lowest red number to the the green number is 51348 Bytes in the above example. This should be the same size in all migrated Pokemon to ENG Platinum, but has yet to be confirmed. Edited September 15, 2017 by ajxpk
Sabresite Posted September 12, 2017 Posted September 12, 2017 @ajxpk, migrate multiple sets for every language. See if the red number changed but still has the same distance. Thanks for your work! Kind of makes me want to go back to D/P and retest those lol. 1
Guest Posted September 12, 2017 Posted September 12, 2017 (edited) I think we will have to check DP again. I saw some stuff in the wikia article which didn't occured in the examples so far. I think it was at Offset 13. Edit: It would be great if someone could help with migrating more Pokemon. Edited September 13, 2017 by ajxpk
HaxAras Posted September 14, 2017 Posted September 14, 2017 Japanese Sapphire to Pearl: Done Japanese Sapphire to Platinum: Platinum only has 7 badges. Japanese Sapphire to Soul Silver: Still working on messing with a complte SS save. English Emerald to Diamond: To do list English Emerald to Heart Gold: Done English Emerald to Platinum: Done 043 - A - F8813A8C9505.pk4 261 - A - 805C4D78A883.pk4 261 - A - B875B127E1EB.pk4 314 - A - 2F14C5B5698A.pk4 316 - A - 556006D7F577.pk4 041 - A - 1709FDA33907.pk4
ZZAZZ Posted September 14, 2017 Posted September 14, 2017 I saw you guys needed more people contributing and figured I'd contribute what I can. I used the provided saves, and kept track of everything I used in case it makes any difference. Hardware DS Lite Original DS All 5 US GBA carts DSTwo Plus DS Card for Korean region Gen 4 games Game Versions DS Korea - Platinum, Pearl, Diamond, SoulSilver, HeartGold GBA US Emerald US FireRed (Rev 0) US LeafGreen (Rev 1) US Ruby (Rev 2) US Sapphire (Rev 0) I did a single pal park import on each game combination, using the same row of dittos per DS game from each GBA title. US Emerald to Korean.rar US Fire Red (Rev 0) to Korean.rar US LeafGreen (Rev 1) to Korean.rar US Ruby (Rev 2) to Korean.rar US Sapphire (Rev 0) to Korean.rar I would have tried more gba cart languages, but unfortunately the DS games failed to recognize my GBA Everdrive X5.
Guest Posted September 14, 2017 Posted September 14, 2017 (edited) Wow! Thanks! I really appreciate it. You did actually more than necessary. I will start making a list and check these out very soon. One question about migrated Pokemon in the Korean games, I heard they're compatible with all different language versions? I'm currently trinking about how to improve the research. Today I did some tests if I can get see more of the strings using blank names. But unfortunately it can't be done without Terminator, which is something I expected anyway... the game fails copying the name string and this is what happens: 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 FF FF So I went on with using at least one Terminator and then it worked and to my surprise (I used the Japanese Diamond Version) I got correct Trash Bytes on an Emulator... Anyway this is for Japanese Diamond only. I can imagine that the Emulator bugs happening in other versions. Or who knows... This is from my first Pal Park: FF FF 00 00 00 00 00 00 B4 C5 0C 02 E0 FF 7F 02 42 00 00 00 00 00 And this is from the 2nd to the 6th: FF FF 06 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Yep. Not exactly all solid 0... I wished we would see what's under the first two Bytes but we might never know... It shouldn't matter too much anyway, since a name can't be shorter than one character as we all know. And since the DS game using 2 terminators to terminate names we have at least 4 Bytes that should never be affected. Also that makes every name that is shorter illegal anyway...For this research it was still interesting to see. I think I will update my save files with Pokemon that have blank names. After we documented all the different strings my idea is actually that we might try different things, like changing the length of the names or something like that, to see if results changing. So my uploaded save files are just for in case you don't have own save files to mess with. I don't have a flash cart yet to do much myself, but stay tuned! Edited September 14, 2017 by ajxpk
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now