Bond697

i'm pretty sure that for the nintendo hack check, pokecheck pretends to be a game validating a pokemon and taking the result back from the validation server. how exactly we did that, i don't recall anymore because it was once about 2 years ago. we did a fair amount of disassembly, though.

that's why i mentioned it...

reread what i said.

here's something someone might want to look into:

in personal.narc for bw2, there's a 16-bit value(bytes 11 and 12) that's used for how many of each ev a pokemon gives out when defeated. the first 12 bits are used for that because it's 2 bits per stat, 6 stats. however, the 13th bit is also used for something. it might be worth figuring out what that's for.

it will never exceed pokecheck because gamefreak considers pids to be random numbers used for bit flags and such, so they will never use them to check anything, and they don't even recognize the existence of trashbytes because they're really garbage created due to programming flaws that happen to have some consistency.

see here: http://tcrf.net/Notes:Pok%C3%A9mon_HeartGold_and_SoulSilver

"Random value" a little ways down is the pid. and a bit of trivia: "Rare" means shiny.

anyway, my point is that they don't consider a lot of what pokecheck checks to be part of a poke's legality, so it will never match what pokecheck does.

pkm extraction isn't the problem. the pkms in pokegen are being slightly broken when they're re-opened after being extracted. you can keep using pokegen to extract the gen 3 pkms you've palparked/poketransfered, just don't re-open them in pokegen.

pokecheck queries pkvldtprod.nintendo.co.jp for the nintendo hack checking. as for the overall site, it's just the gts exploit that you'll see in other programs here mixed in with some other things that we worked on privately.

e:

well, https://pkvldtprod.nintendo.co.jp/pokemon/validate

oh, interesting. the standard they use is seconds since 1/1/2000. i'm surprised it's something different.

come back- i know what the problem is, but i'm still looking for it.

found the problem and am working on fixing it. thanks!

what version of pokegen are you using?

post the pkm. i have tried every possible way i can think of of replicating this and i can;t get it to happen.

"08 28" @ 0x18DF0 in the arm9.

that's the number of seconds between 0:0:0 1/1/2000 and whatever time on 10/28/2012.

i will never "watch how i speak" to people who refuse to read and help themselves. your problem was *your* problem. so it went somewhere more appropriate.

no, it wasn't "related to pokegen". it was "your fault for using pokegen wrong".

did you get it as a gift when the game was new? back in 2003 or whatever? if so, i'm sure the cart is fine. if you got it new in the box in 2013, it's almost definitely a knockoff cart.

desmume .9.9 with the JIT compiler should be fast enough that most people can get away from junk like no$zoomer.

i'm starting to wonder if there's ever going to be a question posed in the pokegen forum that is related to pokegen ever again.

i'm getting really sick of these.

what you have now works for online battling, which is all you need.

pretty sure nintendo eventually blocked that model completely.

see how many pokemon you can generate at once before you hit 185. should be like 2 or 3.

the ar dies at around 185 lines. nothing we can do about a hardware limitation.

ds roms are compiled as binaries to 32-byte alignment. their page size is 512 bytes. there are 2 types of ds card, actually: maskrom and one-time prom. maskrom has a much faster transfer rate(6MB/sec vs 1.5MB/sec) on access, while the prom is faster when it comes to many quick, successive card accesses. the prom can also go up to 4gbit in size, whereas the maskrom can only go up to 512mbit. dsi hybrid and limited games are prom-only, so bw1 and bw2 are all prom games. actually, all the pokemon games are probably prom.

anyway, what i was getting around to saying is that the reason it's expanded and filled with FFs is by nintendo's mandate. depending on the size of your chosen card, and regardless of rom type, the last part of the rom is made up of a few pieces. roms which are 128mb and above have a use-forbidden region at the end which gets bigger as you increase in rom size. this region is mandated to be filled with nothing but FFs as part of the build process. the rest of the end is made up of(if it's a dsi hybrid or limited rom) the arm7i bin, the arm9i bin, and overlays for the arm9i- none of which any current dumper has any chance of handling, so you end up with more FFs. the last piece is actual unused space, which is also mandated to be filled with FFs by nintendo.