kazumi213

Exactly my point. The date-PID relation exists, of course. But it can be used for legality checks only if OT claims for RNG abuse as method for getting the pokemon (not part of the data in PKM file). Then a "feasibility" estimation of this claim can be performed, which is usually based on ability to attain the required "Delay" according to RNG Reporter. For me this is inconclusive too. You could attain any required delay on emulator. Otherwise OT just needs to claim for a random capture. My previous post shows a completely feasible set of conditions for such a capture. Just remember that people can take as much time as they want before pressing A/Start button at titlescreen, and that yes, it can be "exactly" the required time for an incredible capture.

Sorry KazoWAR, I'm not sure whether I'm correctly using RNG Reporter (v7.10), but how about this?

@codemonkey85: Mappings for latin and kana characters were known and well documented long before I build my table, but yeah, I reviewed them all and did the mapping for the remaining 2400 or so hangul chars . Some mappings had to be arbitrary, due to lack of better Unicode equivalents (special characters in the pokemon font). Here are some screenshots from my program showing correct kana and hangul glyphs on a WC. I expect to help Grovyle91 to implement them on his program. These shots are from an old alpha GUI that I used to focus on developing the WC display part. Raw byte values from the PCD had to be manually pasted... JPN Enigma Crystal Present before and after clicking on "Generate" button: KOR Secret Key before and after clicking on "Generate": These are the resulting images after clicking on "Save Image" button: JPN KOR

Thanks a lot for the info. Yeah, i was expecting a bit field Regarding the font, just wanted to note that games contain kana and hangul glyphs in several versions: small (used while playing, dialogs with NPCs, etc) and big (used i.e. in WCs). There's a third (fat) kana version that I think it's used for the Pokédex (main scrollable index). I finally chose to use small version of kana and hangul in the TTF. Big kana version without shadow simply looks horrible, and using big hangul would look unbalanced vs latin and kana small versions. JPN latins are included and still easily distinguishable from western ones in small version, so just a cosmetic decision to ensure balance given TTF limitations. **EDIT** I've been checking your program and the WC preview is quite nice so far. Releasing my program would not make sense with all the additional features in yours. However I might help you in fine tuning/adding kana and hangul display on the preview. Just PM me with details on how do you need the required glyphs (bitmaps) to be formatted (arranged/colored) and I will supply them. I'm assuming that you are overwritting a base empty WC with the glyphs (my approach), but I'm not really sure.

Sadly, you can't create TTF or other Windows directly usable (no plugins or software limitations) fonts other than B/W. Trust me, I tried. Just read the notes about colored fonts on that DarkAngelX site that you link on the fonts thread. He had to use PHF format for them. Other than my font just being B/W, it is 1:1 to the pixel and complete. Size and spacing is quite accurate when used at 12 pt. JPN HG/SS don't add any extra glyph to kanas nor latins that I've noticed, and KOR Pt contains same hangul as KOR D/P (the latter used for my TTF). I have ready a 1:1 wonder card viewer, I mean WC is *exactly* displayed as in-game, no matter of WC data (latin, kana or hangul). As I said it is just a viewer, it won't support editing, but I plan to add *extraction* support from saves. The idea is a tool for quickly inspecting WC, visually, using as close as possible game rules display, since I've found that WCs with evident char corruption keep being uploaded and remain unnoticed. The only info I think I still need is a *detailed* explanation of how the game determines which game(s) the WC applies to, i.e how the 2 bytes starting at 0x14C in a PCD work. The remaining problem is that I have all this coded in MATLAB, but I think it will be possible to compile into stand alone app with some kind of support library (like .NET is required for the app on this thead). Are you including the required char code mapping (Pokemon<->Unicode)?

Ok then I'll create the list by inspection. It should not take more than a couple hours. I'll post it here anyway. It could be useful for somebody else. EDIT: I attach the list. Merry Christmas everybody. poke_icon_palettes_hgss.zip

Could anybody supply/easily compile an accurate list indicating which palette (1st, 2nd or 3rd) is used by each of the 544 icon pairs on these .narc files poke_icon.narc / pl_poke_icon.narc / a-0-2-0.narc I'm working with the latest one (HG/SS), but having the info for any of the previous ones would help as well. Just an ordered txt list containing 1, 2 or 3 for each icon pair will work. Thanks in advance.

I would like to suggest the following notation: Apl-Bph-Cil-Dih (Current A-B-C-D) This way you can have Aph-Bpl-Cil-Dih (instead of current B-A-C-D) without conflicting with the actual RNG call order. You can even represent things like: Apl3-Bph3-Mil-Nih The funny thing here is that the sequences above can be seen as genetic ones (if we admit new DNA nucleotides for pokemon :tongue:)

This option, of course. Only altered parameter will be "Date Met", but final user usually changes it to suit their needs after downloading the pokemon from here, so don't bother with it. Please be sure to include your AGETO and BATORUYAMA pokemon. Legit reference pokemon are always welcome.

Thank you Sabresite. So you mean that given a Method 1 PV-IV combo, and no syncher, is it possible that you can't find a previous PRN which matches PV nature as described by mingot? And assuming a succesful synch, do you mean that for that very same combo it is possible that you can't find a previous PRN with its highest bit set to 0? For a failed synch, I understand that there's a relation between first 2 calls (trigger + nature target), but previous 2 cases amaze me. Could you supply a PV-IV example which is Synch-Invalid?

Hi Sabresite. What's exactly this new restriction? I've performed a random test using Rotom with PV-IVs combo from my generator and "Sync" still shows "Valid". Is it related to "Method J" being used instead of "Method 1" for PV generation as described by mingot? I read it some time ago but I don't see how can it be restrictive if you only know the PV. Algorithm is supposed to perform as many calls as required (according to mingot) to match the nature in the first call. Having a party syncher introduces a slight change in algorithm but, how do you know whether a syncher was used? Thanks in advance.

Please go ahead and try to catch Latias at Sapphire's Southern Island.

Yes, whatever, except that those IVs are impossible for your Latias.

Latias is still an obvious hack.

Absolutely no problem Sabresite :wink: