Jump to content

[Feature Request] Update block C data when importing pokemon (memories, geolocation, handler...)


Recommended Posts

Posted

Hi,

I've been researching how pokemon data is handled/modified when they are transfered to pokemon bank and then they are either returned to the same cartridge or transfered to a different one.

I'm talkin about this data: http://projectpokemon.org/wiki/Pokemon_X/Y_3DS_Structure#Block_C_.280x78-0xAF.29

PKHex currently copy-pastes the pokemon data without modifying it, and this can be a potential legitimacy check when the pokemon is copied over.

Example:

If I transfer a pokemon caught in game A to game B via pkHex, the pokemon is treated as if being under another trainer due to TID/SID/NAME/GENDER discordance, but in fact the pokemon data says it is under its original trainer, and that friendship value is used, so if it ever returns to OT via console trade, friendship would have been modified.

Example 2:

If pokemon caught in game A is traded (via console trade) to game B, then transfered to game C via pkHex; handler is set to notOT, but the memory data is still that of trainer from game B (including notOT name).

I've been researching how pokemon bank deals with this and after much testing I can say I know how to replicate it: pokemon bank efectively simulates a trade when it transfers from bank to cartridge.

I've also researched how egg pk6 data is modified when trading.

Also, I checked and this kind of data is already taken care of when importing gen III/IV/V pokemon (just saying it for the record).

So, is this an interesting addition to pkHex? I think the fact that this is a potential legality check (i.e.: trainer is not OT, but handler is OT) is enough to justify it. The idea is to replicate a pokemon bank transfer when importing .pk6 files. I would do a pull request but C# isn't my forte.

ps: Kaphotics, I saw you post at PHbank thread in another forum, so maybe you are already aware of all this.

Posted (edited)

I've seen this commit: https://github.com/kwsch/PKHeX/commit/b07359f8ddfdc8015a0b8f39df51d59da4ffa1bb

There's a couple things wrong:

1.- To know if it is the original trainer, the game checks the following: TID, SID, Name, Gender

2.- I would suggest using HT_TextVar = 0; ("Somewhere") This is what pokemon bank uses, setting it to pokemon center is not accurate since location is set to that of the player's when the pokemon is received, not necessarily a Pokemon Center.

3.- Eggs do have memory data set when trading:

A newly generated egg has these values set to 0x00 while in OT savegame:
0xD4-0xD6 Date Met
0xDA-0xDB Met At Location
Whenever the egg is traded, the values are updated. Met at location is set to 0x3275 (this is direct hex view from pk6 file, you should probably use 0x7532), which corresponds to "a Link Trade (Egg)".
Date met is set to console's date (0xD4 is year (0x00-> year 2000, 0x0F-->year 2015, etc), 0xD5 is month (0x01-0C (1-12)), 0xD6 day (0x01-0x1F (1-31)).

This happens always that the egg is traded, regardless if receiver is OT or notOT. Also (obviously) checksum is updated.

What I don't know is if date met and met at location is updated when it hatches, but regardless, an egg with those set as 0x00 in a save from a different trainer is "illegal" (not that nintendo checks it though...)

4.- This is the logic that determines if memories have to be updated in pokemon bank.

OK, here's what official bank does when a pokemon is transfered from bank to savegame:

- Is savegame trainer the OT?
   - if it is, notOT handler is set to 0x00
   - if it is not the original trainer, the following check is made: is the notOT handler already 0x01?
       - if it is 0x00, it is set to 0x01 and all notOT data is reset, adding a new geolocation.
       - if it is 0x01, the following check is made: is notOT name the same as the receiving trainer?
           - if notOT name is blank (all 0x00) or if the names differ, all notOT data is set, including adding a new geolocation data (that can lead to repeated geolocation data).
           - if it is the same name, notOT handler is set to 0x01. There are no TID, SID or regional checks in place, only trainer name.

As you can see, the last check is only trainer name, but I think nintendo did to simplify with the following logic: users will only use bank with their own games, and even if they use a friend's cartridge, the trainer name will most likely be different.
There is no bad outcome to this behavior unless the pokemon has been fed items to purposedly decreades friendship value and the receiver trainer expected it to return to base friendship.

Edited by suloku
Posted

Egg Location/Date isn't memory related, it's persistent :)

The synthetic memory creation was for trading between players (not receiving from bank).

I'm still not confident enough on if I want to use these methods when importing to a save file (user flexibility), may have to figure out some sort of solution (since Nintendo/GF doesn't even care about this stuff I may just leave it up to the user to enable/perform).

Implemented in latest commit; still is inaccessible code but anyone can call 'em :)

Posted (edited)
Egg Location/Date isn't memory related, it's persistent :)

I'm not talking about egg data, but pokemon data: 0xD1-0xD6 as referenced here http://projectpokemon.org/wiki/Pokemon_X/Y_3DS_Structure

This data is updated each time the egg is traded, in fact is the only data modified (checksum aside). Even if the egg returns to OT the data is updated when trading.

What I don't know is if that data is converted into "hatch location" and "hatch date" when the egg hatches --> I will check later

The synthetic memory creation was for trading between players (not receiving from bank).

I guess a "pokémon center" is the best generic location for that.

On a side note, the bank essentially trades the pokemon from the bank to the receiving cartridge, it uses the same logic as trading.

I'm still not confident enough on if I want to use these methods when importing to a save file (user flexibility), may have to figure out some sort of solution (since Nintendo/GF doesn't even care about this stuff I may just leave it up to the user to enable/perform).

Implemented in latest commit; still is inaccessible code but anyone can call 'em :)

I too think this should be configurable, but I also think it should be enabled by default even though

An intermediate solution might be prompting the user the first time a foreign pokémon (handler 0x00 but OT is different or handle 0x01) is imported and keep the setting to whatever he chooses; and also have a configuration toogle in the menu bar. This would skip the need for a config file to store the setting, but maybe it can be made too as a way to "not prompt anymore".

EDIT: @Kaphotics, I was checking latest commit:

HT_Feeling = Util.rand.Next(0, 9);

That's only for bank "trade", normal link trade can have more feeling values; I think it went up to 20 from the 24 different memories, but I'm not sure right now, I need to check more.

EDIT2: also, TradeHT() should have:

HT_Name = SAV_Trainer;

HT_Gender = SAV_GENDER;

I haven't seen that anywhere.

EDIT3: @Kaphotics, I can confirm that link trade uses at least 20 different feeling values, I haven't seen any of the last four except on catched pokemon, but to trully confirm a substantially bigger amount of traded pokemon should be checked. I don't think leaving out 4 possible memoeries we aren't even sure can be set when trading will hurt since there's 20 more.

HT_Feeling = Util.rand.Next(0, 19);

Edited by suloku

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...