kazumi213

All right then Thank you SCV.

I know SCV I saw you starting to speak about it and hoped to "squeeze" a bit more info I understand what you mean. It's just that I thought that I had figured out how Legal was dealing with ID combo exceptions... until the calculator. I still can't see how it can apply corrections for certain cases (last example in my previous post, calculator results are the expected ones, ok), but doesn't do the same for the first example and reports the same tree twice. I mean, are you sure is not a calculator coding fault for such special ID combos? Have you actually confirmed in-game that only 3 valid HTs are possible? I won't post on this again

Glitched GBA roaming pokemon (aka "Roaming GBA" type) - Lati@s (from R/S only) - Dog trio IVs: HP = 0-31 Atk = 0-7 Rest = 0 (always) Emerald roaming Latis are not glitched.

These are personally confirmed facts: - Saving pokemon from your boxes into .PKM files, then deleting them, then saving the changes to your save file DOESN'T leave "Pokesav traces" in your save file. - Those .PKM files DON'T have "Pokesav traces" - Loading .PKM files into your boxes, then saving the changes to your save file DOESN'T leave "Pokesav traces" in your save file. - Editing pokemon in your boxes then saving changes to your save file CAN leave "Pokesav traces" (in the pokemon, but no other parts of the save file) due to wrong character support, loss of trash bytes and of course user's lack of editing experience. At worst you get a poorly hacked pokemon, but there won't be "Pokesav traces" in your save file. (end of facts) I can't speak for editing Pokedex entries with DSPokeEdit, I've never checked how "clean" is that. Until then and to be on the safe side I suggest getting missing Pokedex entries by hatching eggs for those pokemon able to breed. And I mean breeding and hatching in-game. Also remember that using a pokemon in a battle grants you a partial pokedex entry (seen), enough to allow you to get the full entry by GTS trading. The problem is that you don't have Wi-Fi, iirc. As for editing trading statistics with DSPokeEdit, I have yet to check how clean is that too. Again, until then safe practice would be getting useless GTS and Wi-Fi trades to increase your numbers. Other than that wait for Pokemod, those are fixable hacking flaws as I've said before. And please note that probably nobody will ever check your save file that deep. Better enjoy the game.

Thank you xeomyr. So after trading any pokemon using GTS, Wi-Fi or Link: Met Location: Doesn't change Egg Location: Doesn't change After trading eggs: Met Location: None Egg Location: Link Trade (Met) Finally, Link Trade (Arrived) is used as Met Location for in-game trades only.

I can't personally test all forms of trading iirc: GTS, Wi-Fi and Link, and I would like to be sure once and for all. 1. When using any of the the 3 methods above to trade pokemon/eggs: which cases require Met Location Egg Location fields to be set to "Link Trade (Arrived)" or "Link Trade (Met)" on the received pokemon/egg? 2. When to use "Link Trade (Arrived)" and when to use "Link Trade (Met)" as locations? I still have doubts even after the previous replies, because all in-game trades have Met Location set to "Link Trade (Arrived)", so I wonder whether real life trades must have it too.

And don't forget the "Mold Breaker" ability.

Sorry, I forgot to check for your reply. Thanks a lot. Your reply is quite inspirational Definitely I agree with the combined IV2PV+PV2IV approach, depending on the task. Limited IV ranges cases benefit from the former indeed, and all possible results are achieved in seconds. You can even go for full 0-31 scans in resonable time (a few minutes) as long as you fix 2 IVs, which is more than enough from the battle design point of view. Also, the algorithm can be optimized for the IV trio getting the less possible combinations according to input. PV2IV works best for PV designs ("is this possible?" cases), which are satisfied just by a very limited set of IV combos, and you are aiming for the best one, so want to be sure to find them all (if any)

Zowayix, as long as the only Pokesav operations that you performed on your save files are save/load .PKM files from/to your boxes, there won't be Pokesav "traces". You could just be missing expected data like Pokédex entries or trade statistics, but both can be fixed, and they can always wait for Pokemod. Other than that, if you edited pokemon using Pokesav, depending on its version, there could be Pokesav traces on the edited pokemon. But then you can check and fix the .PKM files, no problem with the sav file.

Do you mean that given an algorithm, you can get all valid PVs corresponding to all combinations of the 6 IVs ranging from 0-31 in less than 10 minutes? What's your approach?

Thank you, but Sabresite those are not the trees reported by the calculator for that ID combo, but 13 0 14 0 Now, this is ok: However this is not actually performed by the calculator But something like: (WW==XX) 13 == 0 = false (WW==YY) 13 == 14 = false (XX==YY) 0 == 14 = false (WW==ZZ) 13 == 13 = true, 13+1 = 14 (recheck) (can't be 14) (can't be 15 then 0) (WW becomes 0) (XX==ZZ) 0 == 13 = false (YY==ZZ) 14 == 13 = false for the actually reported trees to be possible, though reported order doesn't match However your logic explains tree results for the swapped ID case: TID = 37120 (9100) (YYZZ) SID = 37521 (9291) (WWXX) ( 92 % 15 ) = 14 = WW ( 91 % 15 ) = 13 = XX ( 91 % 15 ) = 13 = YY ( 00 % 15 ) = 0 = ZZ (WW==XX) 14 == 13 = false (WW==YY) 14 == 13 = false (XX==YY) 13 == 13 = true, 13+1 = 14 (XX becomes 14) (WW==ZZ) 14 == 0 = false (XX==ZZ) 14 == 0 = false (YY==ZZ) 13 == 0 = false 14 (WW) 14 (XX) 13 (YY) 0 (ZZ) Ok, although the tree order reported by calculator is 14, 13, 14, 0, so I'm not sure what's happening. But again your logic doesn't explain calculated trees on this case TID = 21504 (5400) (YYZZ) SID = 10773 (2A15) (WWXX) ( 2A % 15 ) = 0 = WW ( 15 % 15 ) = 0 = XX ( 54 % 15 ) = 0 = YY ( 00 % 15 ) = 0 = ZZ (WW==XX) 0 == 0 = true, 0+1 = 1 (WW becomes 1) (WW==YY) 1 == 0 = false (XX==YY) 0 == 0 = true, 0+1 = 1 (XX becomes 1) (WW==ZZ) 1 == 0 = false (XX==ZZ) 1 == 0 = false (YY==ZZ) 0 == 0 = true, 0+1 = 1 (YY becomes 1) 1 (WW) 1 (XX) 1 (YY) 0 (ZZ) Don't match calculator results, which are 0, 1, 2, 3

I'm not sure whether you have correctly explained this. I can't get the calculator results for the ID combo in my previous post: TID = 37521 (9291-h) (YYZZ) SID = 37120 (9100-h) (WWXX) If ZZ%15 = WW%14 (I guess you mean WW%15) => 13 = 13 (true) then XX%15=ZZ%15 +1 => XX%15 = 13 + 1 = 14 YY%15=ZZ%15 +2 => YY%15 = 13 + 2 = 15 (can't be 15) According to calculator, valid trees are 13 (ok), 0 (ok), 14 (ok), 0 (again) So your logic explains one of the zeros if we assume that 15 is converted to 0, but not the other (I mean you don't show how one of the 13's becomes 0, if that is what it is happening) Now if we swap IDs TID = 37120 (9100-h) (YYZZ) SID = 37521 (9291-h) (WWXX) If ZZ%15 = WW%14 (I guess you mean WW%15) => 0 = 14 (false) then XX%15=ZZ%15 +1 => XX%15 = 0 + 1 = 1 (doesn't apply, condition is false) YY%15=ZZ%15 +2 => YY%15 = 0 + 2 = 2 (doesn't apply, condition is false) Your logic doesn't explain calculator results either: 14 (ok), 13 (ok), 14 (again?), 0 (ok)

So do you mean that there can be less than 4 valid trees after all?

@Sabresite: A few days ago you explained that the game can handle "problematic" ID combos to always allow for 4 different valid Munchlax Honey Trees to be available to the player. So I think that there is a little problem with the current calculator, because it is reporting the same tree twice for OTID = 37521, OTSID = 37120. I think one of them should be the 205 *north* one.