-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate migration to DS games #18
Comments
Also, Apricorn Balls should use the Poké Ball identifier for the "real" ball ID so that they show up as such in gen IV. |
I’ve been thinking and couldn’t you make Apricorn Balls use the same IDs as they are in HGSS? In gen 4, any of the Apricorn Balls load as Poké Balls. The IDs after Premier and before the first Apricorn Ball ID can just be filler. |
DPPt and HGSS access two different data fields in the Pokémon structure when it comes to Poké Balls. DPPt uses 0x83 and HGSS uses 0x86 (This field is possibly only used if 0x83 has a value of 0x04; I'm not sure on the logic). In HGSS, any Poké Ball that exists in DPPt (Master Ball-Cherish Ball/0x01-0x10) has the same value stored in both these addresses. For the new/returning Poké Balls added in HGSS, the ID of the actual ball used (I think 0x11-0x18) is stored in 0x86 while the value for Poké Ball (0x04) is stored in 0x83. Thus, any Pokémon in an Apricorn Ball transferred to DPPt displays a Poké Ball, while still retaining the data of what it was actually caught in, similar to the altBall strategy of CrystalDust. I've only done my Pal Park tests in HGSS, but I expect the conversion behavior to be the same in DPPt. Based on my experience, Pal Park doesn't do any error checking, at least on the Poké Ball value, so any value set to substruct3->pokeball will get carried over, but any value over 0x10 at address 0x83 is rendered as a Poké Ball for the error case. And of course, Pal Park doesn't have any capability to set 0x83 to the placeholder Poké Ball value and set 0x86 to one of the Apricorn Ball values as that was never intended for Gen 3 to Gen 4 transfer and wasn't even a mechanic when Pal Park was being written. Based on my understanding, the most you can stretch out of Pal Park functionality when it comes to Poké Balls not normally existing in Gen 3 games are Dusk Ball, Heal Ball, Quick Ball, and Cherish Ball. |
Not only this, but the Poké Ball field in gen III is limited to 4 bits (so only values 0x0-0xF are allowed), which means that not even the Cherish Ball could be set, let alone 0x11-0x18 even if it used the same field in HGSS. |
Ah, yes. I forgot that some of the higher-value test files I have were from editing Pokémon already in Gen 4. |
Figured I might as well contribute to this issue. Gen 4 completely discards what we call the Also, if you do anything like add formes under new index numbers, Gen 4 uses a conversion table to convert species starting at Treecko from the Gen 3 index numbers, and anything above SPECIES_EGG is specifically not migrate-able (SPECIES_EGG is handled like Eggs and therefore also not migrate-able, but isn't excluded in the same way as the others). They are displayed with the Pokemon icons of the ? between Celebi and Treecko. It seems like the ? between Celebi and Treecko have their index numbers preserved, but they are also explicitly excluded according to Bulbapedia (I have not tested this myself with the ? between Celebi and Treecko). Deoxys formes are set depending on the game it is migrating up from, so if you keep the gamecode as BPEE it'll get to Gen 4 in Speed Forme. |
If the Pokémon could be transferred to NDS games, then it may be done in a way that migrated Pokémon will be legal to pass Pokébank later. For this reason, the Johto Balls may be replaced as normal Poké Balls, since it's not possible to obtain gen III Pokémon in those Balls. |
The Pokemon from Crystaldust will use the HGSS game origin so technically any Gen 4 balls would be legal on them. Without hacking DPPtHGSS, however, there is no way to trick Pal Park's transfer process into putting transferred Pokemon in Apricorn Balls. I've looked at the leaked Diamond source and specifically into how Pal Park transfers work and there is little that can be done to manipulate it from the GBA side. |
OK, but in that case there's another problem. If the Pokémon from CrystalDust are marked as from HG/SS, they couldn't hold Gen III exclusive ribbons, so if you transfer a Pokémon to R/S/E and manage to win one of those ribbons this will lead to an illegal combination. |
They'd also be likely to have illegal levels, movesets, and PIDIV types as well as be missing an Encounter Type. There's a lot of issues with creating "legal" Pokémon in a ROM hack, especially when trying to masquerade as a game on a different console, but I don't believe they are really priorities for this project. |
Levels can be raised, and moves can be forgotten, these are minor issues. Pal Park sets the met level as the current level the Pokémon have, so the only problem would be with Pokemon at very low levels. The PID/IV relationship indeed could be a problem, but if it's decided Pokémon are treated as from gen IV then there's nothing to do. |
This should work if the total size of the saveblocks remains the same as or smaller than Emerald. I'm sure there are plenty of things to clean out of the saveblock that no utilities would break under (e.g. migration, Box).
The text was updated successfully, but these errors were encountered: