Hier soll einmal erklärt werden, wie im GBA entschieden wird, ob ein Pokemon shiny ist. Dies ist dann
die Grundlage dazu, bestehende Pokemon durch Àndering ihrer PID in Shinys zu verwandeln.
Leider lässt sich dabei ein kleiner Ausflug in die Mathematik nicht vermeiden. Ich weiß, dass das
für einige Leser etwas anstrengend ist, daher empfehle ich, Abschnitte, die zu schwer erscheinen, erstmal zu überlesen und
erstmal ein wenig den Text komplett wahrzunehmen. Wenn man solche Dinge zum ersten Mal macht, sollte man auch nicht erwarten,
dass einmal Lesen ausreicht. (Ich hab mich da auch mehrfach durchlesen müssen)
Ursprünglich habe ich diesen Text stückweise im Mogelpower-Forum gepostet.
Als Quellen verwendet wurde die PokemonMaker-Hilfe, grundlegendes Wissen zum Binärsystem und Operatoren, Schulmathematik, etc.
(an die Freaks, die sich ein wenig besser auskennen: Möglicherweise bin ich an einigen Stellen etwas ungenau oder vereinfache.
Das dient dann lediglich dem Verständnis.)
Wir werden hier ein wenig das binäre Zahlensystem nutzen müssen und deswegen ist es sehr hilfreich, wenn man das verstanden hat und Zahlen umrechnen kann.
Wen das Verständnis eher nervt, der kann besser direkt zur Umrechnung springen.
Gewöhnlicherweise arbeiten wir Menschen im Dezimalsystem. Dezimal kommt von Dezi und bedeutet Zehn.
Tatsächlich haben wir zehn Finger und kennen zehn verschiedene Ziffern (die Zehn ist dabei keine Ziffer, ich rede hier von "Null" bis "Neun").
Und was machen wir, wenn wir Zahlen größer als 9 darstellen wollen? Wir brechen eine neue Stelle an - die aber mehr wert ist als die andere.
Hat bestimmt jeder mal in der Schule gemacht 253 steht für:
Dass wir die meiste Zeit im dezimalen System arbeiten, heißt bei weitem nicht, dass es das einzige System ist, dass es gibt. Grundsätzlich kann man jede beliebige Zahl als Basis nutzen. In der Tat nutzen wir auch andere Zahlensysteme, ohne es zu bemerken:
Etwas aus der Mode gerade ist ein Zahlensystem mit der Basis 12.
Die Spuren davon lassen sich aber sofort erkennen, wenn man darüber nachdenkt, dass wir von "Elf" und "Zwölf" reden und nicht von "Einszehn" und "zweizehn".
In einem Zahlensystem zur Basis 12 ist dann jede Stelle das zwölffache der letzten wert:
Beispiel: 136 im Zwölfersystem wären:
Weiteres Beispiel: 4A im Zwölfersystem.
"MOMENT! Was ist A denn bitteschön für eine Zahl?"
Wie man einfach sehen kann, würde 09 im zwölfersystem für 9 im Dezimalsystem stehen, 10 im Zwölfersystem aber schon für 12 im Dezimalsystem,
also brauchen wir noch Ziffern für 10 und 11. hier habe ich einfach mal gesagt A = 10 und B = 11... also weiter:
Wenn man auf die Uhr sieht, so merkt man, dass dort nicht von 10 oder 100 Minuten pro Stunde die Rede ist, sondern von 60.
In der Tat lassen sich in Sachen Planetenbewegungen viele Dinge besser in einem 60er-System darstellen als in einem dezimalen.
Fragt mich aber jetzt nicht, wie die anderen 50 Ziffern aussehen *g*.
Übrigens ist die 60 sehr schön, wenn man mal die Teiler mit denen der 100 vergleicht.
Außerdem kann man sich überlegen, dass in der 60 auch die 12 drinsteckt - was ja irgendwie mit den Stunden eines Tages zu tun hat. Zufall?
Wenn man sich jemals gewundert hat, warum in Cheatcodes und Computerprogrammen so komische Buchstaben bis F auftauchen,
so kann man an dieser Stelle mal überlegen, wie viele Ziffern man bis dahin hat.
(und wenn man sich jemals gewundert hat, warum in Gamecube-AR-Codes auch so komische Buchstaben bis Z auftauchen, so kann ich an dieser Stelle nur sagen,
dass AR-Codes blöd sind, weil sie extra verschlüsseln und nochmal weiter mappen)
Für den Computer sehr relevant ist das Binärsystem. Das ist ein Zahlensystem mit der Basis 2. Wir haben also nur zwei Ziffern "0" und "1", was den beiden Zuständen "falsch" und "wahr" entspicht.. oder "aus" und "an". Mehr kann ein Computer nicht unterscheiden - das allerdings sehr, sehr oft.
Wenn wir also beispielsweise die Zahl 1100101 im Binärsystem sehen, so können wir diese lesen:
achja: die 16 von Stelle fünf ist wirklich die, die Ihr beim Zählen bis F gefunden habt. Weil nämlich so ewig lange Kolonnen von Nullen und Einsen nicht ganz schön zu Lesen und zu Tippen sind, fasst man oftmals vier Bits zusammen.
Ups, ein Fremdwort: ein "Bit". Ein Bit steht für eine Informationseinheit. Und ein Bit kann auch nur zwei Zustände haben, 0 und 1.
Aber keine Panik, die hexadezimale Darstellung (Zahlensystem mit Basis Hexadez = Sechzehn) werden wir nicht brauchen.
So, ich hoffe, dass ich hier wieder die Leute auffange, die direkt zur Umrechnung gesprungen sind.
Jetzt kann man natürlich das wie oben machen (wer in Mathe schonmal das Wort "Potenz" gehört hat, erkennt vielleicht ein Muster wieder), aber "die Jugend von heute" gibt ja lieber einfache Befehle in den Taschenrechner ein.
"Man startet mit 0, liest die Zahl von vorne und gibt immer * 2 + #ziffer# = ein"
Beispiel:
1
Wir starten mit 0, *2, +1 = "1"
10
Wir starten mit 0, *2, +1, *2, +1 = "2"
100
Wir starten mit 0, *2, +1, *2, +0, *2 +0 = "4"
okay, bis dahin ist das ja noch einfach, aber machen wir mal was komplizierteres:
1100101
Wir starten mit 0, *2 +1 = "1"; *2 +1 = "3"; *2 +0 = "6"; *2 +0 = "12"; *2 +1 = "25"; *2 + 0 ="50" *2 +1= "101"
Wer genauer hinguckt, merkt, dass man sich das +0 eigentlich sparen kann und stattdessen direkt mit *2 weitermachen kann.
Wichtig ist allerdings wirklich, dass man nach jedem "+1" einmal "=" drückt.
Wenn man nämlich einen "wissenschaftlichen" Taschenrechner hat (so einen für die Schule), dann ist nämlich
110 => 2+1*2 = "4"
obwohl wir eine Umrechnung zu 2+1 ="3" *2 = "6" brauchen.
Noch nicht? Okay:
Der GBA arbeitet mit 32-Bit Zahlen. Das heißt, wir werden mit Zahlen in der Größenordnung von:
10000010010100111011001100111111 (meine Trainer-ID)
arbeiten müssen.
An dieser Stelle kann man sich denken, dass ein Computer für diese langweilige Arbeit besser geeignet ist,
als ein Mensch mit Taschenrechner.
Ich lasse die Zahl da mal als Übung stehen. Wer möchte, kann die ja mal zur Übung umrechnen und mir sagen, zu welchem Ergebnis er kommt.
Auch hier gibt es wieder eine Methode für den Taschenrechner:
"Man tippt die Zahl ein. Anschließend rechnet man immer wieder /2.
Wenn man .5 hinter dem Komma hat, schreibt man eine 1 auf und zieht die 0.5 ab.
Wenn man nichts hinter dem Komma hat, schreibt man eine 0 auf.
Das macht man so lange, bis nur noch die "0" im Display ist.
Achtung: Man schreibt sich die Ziffern von Rechts auf."
Beispiel:
Die Zahl 5
"5" /2 => "2.5", also schreiben wir eine 1 (=> "1") und ziehen die .5 ab
"2" / 2 => "1", also schreiben wir eine 0 (=> "0 1") und ziehen nichts ab.
"1" / 2 => "0.5", also schreiben wir eine 1 (=> "1 01") und ziehen die .5 ab
"0" , wir sind fertig und haben "101" raus.
anderes Beispiel: Die Dezimalzahl 101
"101" / 2 => "50.5", also "1"
"50" / 2 => "25", also "0 1"
"25" / 2 => "12.5" , also "1 01"
"12" / 2 => "6" , also "0 101"
"6" / 2 => "3", also "0 0101"
"3" / 2 => "1.5", also "1 00101"
"1" / 2 => "0.5", also "1 100101"
und somit haben wir "1100101" raus. Immerhin schon 7 Bit. Im GBA können natürlich wieder entsprechend lange Zahlen auftreten.
Wer nochmal probieren möchte: 2186523455
Wer sich ein wenig besser auskennt, kann auch direkt durch 4 teilen und muss dann unterscheiden
glatt => "00"
0.25 => "01"
0.5 => "10"
0.75 => "11"
natürlich geht das auch direkt mit 8 oder 16. Echte Freaks können wahrscheinlich Zahlen auch abbrechen,
wenn sie Zahlen unter 256 sehen ("ach, da ist ja eine 101, die Zahl kenne ich doch, schreibe ich also direkt die 1100101 hin")
Außerdem gibt es für sowas auch Tabellen.
Noch ein kurzer Kommentar an Programmierer unter Java: "int" reicht für solche Zahlen nicht aus, man sollte schon auf "long" umsteigen. Ich gehe auch mal davon aus, dass es fertige Programme oder sogar einfache Internet-Skripte gibt, die so etwas umwandeln.
Ich merke gerade: (Fast) jeder Windows-Benutzer hat so ein Programm schon installiert. Der Taschenrechner von Windows lässt sich unter "Ansicht" auf "Wissenschaftlich" umschalten.
DEC anklicken, Zahl eingeben, BIN anklicken
BIN anklicken, Zahl eingeben, DEC anklicken
Okay, ich gebe zu, das mit dem Zweiersystem ist schon etwas harter Stoff. Deswegen wird das mit dem XOR jetzt auch ganz einfach.
XOR ist eine logische Operation, die die Pokemonspiele an diversen Stellen zur Verschlüsselung einsetzen.
Über XOR wird auch bestimmt, ob ein Pokemon shiny ist, also werden wir uns das auch kurz ansehen müssen.
Allerdings haben wir das durch das binäre System auf eine eher triviale Geschichte runtergedrückt:
a XOR b ist genau dann 0, wenn a und b den gleichen Wert haben.
also
0 XOR 0 ist 0,
0 XOR 1 ist 1,
1 XOR 0 ist 1,
0 XOR 0 ist 0,
Es hat etwas von dem logischen ODER (wenn ich etwas kaputt mache ODER frech bin, bekomme ich Ärger),
allerdings verhält es sich für den und-fall etwas anders
(man bekommt bei XOR keinen Ärger, wenn man frech ist und etwas kaputt macht)
XOR von längeren Zahlen macht man nun, indem man jede Stelle für sich betrachtet:
also XOR von 1100101 und 1010110 ist
1100101
1010110
-------
0110011
(einfach immer eine Null hinschreiben, wenn die beiden Zahlen darüber gleich sind, eine Eins,
wenn man nur einmal eine Eins dabei hat)
Auch hier werden wir für GBA mit 32-Bit-Zahlen arbeiten müssen, aber hier kann man sowas quasi per Anschauen lösen:
00110011011001000100110101110011
10000010010100111011001100111111
--------------------------------
10110001001101111111111001001100
Wenn man nun das logische XOR von zwei Dezimalzahlen sucht, findet man dies, indem man die Zahlen erst ins binäre umwandelt, dort dann das einfache XOR macht und das Ergebnis hinterher wieder ins dezimale umwandelt.
nochmal Nachtrag: Der Windows-Taschenrechner hat im Wissenschaftsmodus auch einen Knopf "Xor".
Ich gebe zu, das war jetzt sehr viel Mathematik (und auch das XOR ist vielleicht nicht ganz so einfach erklärt, wie es hätte sein können), aber das wird nunmal später gebraucht. Keine Panik, wenn man das erstmal verstanden hat - oder zumindest anwenden kann - ist das Schlimmste überstanden.
Ob ein Pokemon shiny ist, ergibt sich aus dem Verschlüsselungscode. Dieser ergibt sich aus der Pokemon-ID und der ID des Trainers. Der 32-Bit-Vergleich da oben ist genau ein Beispiel dafür und das Ergebnis ist dann auch tatsächlich der Schlüssel, mit dem eines meiner Pokemon verschlüsselt ist.
Nach den mathematischen Vorbemerkungen des letzten Mals wollen wir diesmal etwas näher an die Praxis kommen.
Praxis funktioniert immer gut mit Beispiel und deswegen werden wir folgendes Pokemon betrachten:
3FD78573CD02CEEEC5C3BEBEBBFFFFFFFFFF0502CDBBBCBCC9FFFF00A37F0000ADD5DF9DAFD5159DE6C1529378D44B9D2FF8489D722B4B9DF2C4CF049EE1533BF2554B9D77976C31D8EF4B9DF2D54B9D
Dieses wurde mir freundlicherweise von einer Freundin zur Verfügung gestellt - nachdem ich versprochen hatte,
dass sie es als Shiny zurück bekommen würde.
Ich erkläre jetzt mal kurz, wie man aus diesem Pokemon nun "per manum" (von Hand) die Pokemon-ID und die Trainer-ID auslesen kann,
aber das geht ins hexadezimale (und ich habe versprochen, dass das ohne geht) und für die, die das nicht wollen,
folgt danach eine einfachere Methode.
Man nehme sich die ersten acht Ziffern (4 Byte)
3FD78573
diese werden umgedreht: die ersten zwei Zeichen werden die letzen, Ziffer 3 und 4 werden 5 und 6.
7385D73F
Diese hexadezimale Zahl wandeln wir ins dezimale um:
(A=10 B=11 C=12 D=13 E=14 F=15 ich hoffe, ich spoile gerade nicht)
0
*16+7=7
*16+3=115
*16+8=1848
*16+5=29573
*16+13=473181
*16+7=7570903
*16+3=121134451
*16+15=1938151231
Und wo wir schonmal dabei sind (und das später brauchen), können wir daraus auch direkt eine Binärzahl machen:
Hier mal ein kleiner Trick (wurde zwar schonmal gesagt, aber hier dann nochmal verdeutlicht):
Die Hexadezimalzahlen sind deswegen so "schön", weil jeweils eine Ziffer für vier Bits steht.
Hat man also eine Zahl im Hexadezimalen, so ist die in fast Nullzeit in Binär umzurechnen:
7=0111
3=0011
8=1000
5=0101
D=1101
7=0111
3=0011
F=1111
also
01110011100001011101011100111111
Kleines Rechenexempel:
Ein Bit kann 2 Werte annehmen
Zwei Bit können 2*2=4 Werte annehmen (00, 01, 10, 11)
Drei Bit können 2*2*2=8 Werte annehmen (000, 001, 010, 011, 100, 101, 110, 111)
Vier Bit können 2*2*2*2=16 Werte annehmen (hex: 0 1 2 3 4 5 6 7 8 9 A B C D E F)
...
Acht Bit können 16*16=256 Werte annehmen (jemals gewundert, woher die 255 als Grenze in Programmen und Spielen kommt? DA!)
Wieviele Werte können 32 Bit annehmen?
Abermals ist der im Vorteil, der in Mathe beim Begriff "Potenz" aufgepasst hat und nun weiß,
mit welcher Taste auf dem Taschenrechner er sich 30 Tastendrücke ersparen kann.
Für die Trainer-ID nehmen wir nun die acht Byte danach:
CD02CEEE
Diese werden auch wieder paarweise umgedreht:
EECE02CD
und in dezimal verwandelt:
4006478541
und einmal in binär verwandelt:
11101110110011100000001011001101
weil's so schön ist, trennen wir das mal auf in die ersten 16 Bits und die letzten 16 Bits:
1110111011001110
0000001011001101
respektive
EECE
02CD
und daraus ergibt sich dann dezimal
61134
717
717 ist die öffentliche TrainerID besagter Freundin
61134 ist die versteckte ID besagter Freundin.
Jedes Pokemon ist ja (wie von damals im PokemonMaker-Thread erwähnt) untrennbar mit seinem Original-Trainer verbunden ("Für ein Mädchen gibt es nur eine erste Liebe") - egal, wie wild es getauscht wurde.
Man nehme sich diesen Wulst von 80 Bytes, gebe ihn in das linke Feld vom Pokemonmaker ein und klickt auf [Code to Samples].
Die PID steht dann bei "PID", die Trainer-IDs unter "Trainer Info",
für die zusammengesetzte Trainer-ID kann man das jetzt wie oben zusammensetzen,
oder man multipliziert die SecretID mit 65536 und addiert sie auf die offene ID.
Dass für die offene Trainer-ID "nur" 16 Bit zur Verfügung stehen, erklärt auch, warum man niemandem trauen sollte, der eine Trainer-ID über 65536 hat. *g*
Die Umwandlung in Binär und Hexadezimal kann dann wieder der Windows-Taschenrechner erledigen - oder ein Programm Eurer Wahl.
Schreiben wir nun PID und komplette Trainer ID untereinander und machen - wie bereits gelernt - ein XOR:
01110011100001011101011100111111
11101110110011100000001011001101
--------------------------------
10011101010010111101010111110010
Kurze Kontrolle:
Diesen XKey teilen wir nun wieder in Stücke zu 16 Bit auf und machen ein XOR davon:
1001110101001011
1101010111110010
----------------
0100100010111001
Schnell erkennen kann man das daran, dass es Einsen links von den rechten drei Stellen gibt.
Und sobald dieses Ergebnis acht oder größer ist, ist das Pokemon *NICHT* Shiny.
So "einfach" ist das.
Gegenbeispiel:
FD98FF74 => 74FF98FD PID
CD02CEEE => EECE02CD Trainer-ID
01110100111111111001100011111101
11101110110011100000001011001101
--------------------------------
10011010001100011001101000110000
XKey
1001101000110001
1001101000110000
----------------
0000000000000001
Somit wisst Ihr jetzt, wie Ihr aus einem gegebenem Pokemon (oder gegebenen PID und OTrainer-ID) ermitteln könnt, ob es shiny ist (klar, der Maker zeigt das in einem Feld auch an, aber das macht ja keinen Spaß).
In der nächsten "Lektion" wird dann gezeigt, wie man ein Pokemon dann wirklich shiny macht.
Der gaaanz einfachste Wert wäre natürlich, die Trainer-IDs und die PIDs komplett auf Nullen zu setzen,
dann taucht im XOR nirgendwo eine Eins auf, die sich auswirken könnte -
allerdings stimmt die Trainer-ID nicht mehr mit dem Spieler überein.
Etwas witziger - aber immer noch einfach - ist es, die PID auf die Trainer-ID zu setzen.
Dann fliegen beim ersten XOR schon alle Zahlen raus, so dass der XKey komplett Null ist. und Null ist kleiner als 8.
In der Tat scheint der Shiny-Cheat für Smaragd (ausprobiert auf XPloder) genau das zu machen:
Die PID von wilden Pokemon wird auf die Trainer-ID gedrückt - was ich für billig halte,
was aber zumindest einen relativ kurzen Cheatcode ermöglicht.
Soweit ich weiß, funktioniert der AR-Code ähnlich, aber erheblich schlechter. Die Pokemon gehören einem wieder nicht.
Trotzdem will ich das etwas weiter im Detail erläutern.
Einfach nur einen Knopf im Maker zu drücken, ist ja auch billig, wir wollen
eine schöne PID selber bauen.
Kommen wir nun zum nächsten Kapitel. Wir wissen, wieviel Spaß Mathematik machen kann. Wir wissen, wie wir herausfinden, ob ein Pokemon shiny ist. Jetzt wollen wir nur noch wissen, wie wir es selber bunt anmalen können.
Wie wir ja gesehen haben, hängt dieser Status nur von der ID des Originaltrainers und von der ID des Pokemon ab. Die ID des Originaltrainers wollen wir nicht anfassen, denn dann würde uns das Pokemon ja nicht mehr gehören (und eventuell nicht gehorchen). Also werden wir nur an der PID rumbasteln.
Worauf genau müssen wir da achten? Wer die Rechenaufgabe aus dem letzten Teil gelöst hat, weiß, dass es "sehr sehr viele" verschiedene PIDs gibt, Ausprobieren wäre also nicht ganz so die ideale Idee.
Aber wir können uns überlegen, was für solche PIDs gelten muss.
XKey = PID XOR OTId
ShinyNr = XKey.High XOR XKey.Low
und ShinyNr < 8
Jetzt taucht da eben .High und .Low auf und das werden wir auch noch weiter brauchen. Das steht dann dafür, dass wir von den 32 Bit die ersten 16 (High) oder die letzten 16 (Low) nehmen - also trennen, wie schonmal gemacht.
Nun wissen wir, dass dieses XOR immer nur die untereinanderstehenden Bits betrifft.
Das heißt, wenn wir die PID und die OTId in High und Low aufteilen, macht uns das überhaupt nichts aus:
XKey.High = PID.High XOR OTId.High
XKey.Low = PID.Low XOR OTId.Low
ShinyNr = XKey.High XOR XKey.Low
und da wir uns nur für die ShinyNr interessieren, brauchen wir den XKey gar nicht mehr zwischenzuspeichern.
ShinyNr = (PID.High XOR OTId.High) XOR (PID.Low XOR OTId.Low)
Jetzt verbuddeln wir und nochmal kurz in die Mathematik und stellen fest, dass XOR "kommutativ" und "assoziativ" ist.
(Wenn Euch Euer Lehrer mal erzählt hat, dass man die Begriffe irgendwann nochmal brauchen kann, dann wisst Ihr jetzt, wozu).
Wer nicht genau weiß, was das bedeutet:
A XOR B = B XOR A
(A XOR B) XOR C = A XOR (B XOR C)
und für uns heißt das, dass wir umsortieren können:
ShinyNr = (OTId.High XOR OTId.Low) XOR (PID.High XOR PID.Low)
und auf einmal haben wir auf der linken Seite nur noch Dinge die vorgegeben sind und auf der rechten Seite nur noch Dinge,
die wie selber vergeben dürfen.
Wer letztens den langen Absatz gelesen hat, könnte sich auch erinnern, dass OTId.High nichts anderes war als die
versteckte Trainer-ID und OTId.Low sich in der öffentlichen Trainer-ID wiederspiegelte.
Suchen wir diese für unser Beispiel nochmal heraus:
1110111011001110 versteckt
0000001011001101 offen
----------------
1110110000000011 (XOR)
Denken wir zurück an die Funktionsweise von XOR: Damit das XOR von zwei Zahlen Null ist, müssen die beiden Zahlen gleich sein.
Wir müssen also im nächsten XOR auf den ersten 13 Stellen die gleiche Zahl haben:
1110110000000011 (OTId.XOR)
1110110000000??? (PID.XOR)
----------------
0000000000000??? (< 8 wie gewünscht)
An dieser Stelle treten wir mal einen Schritt zurück und überlegen uns nochmal, dass das Spiel solche PIDs zufällig erzeugt. Das heißt, man kann davon ausgehen, dass auch die PID.XOR zufällig sind. Aus der Analyse gerade kann man entnehmen, dass von diesen zufälligen PID.XOR insgesamt 8 für ein shiny Pokemon sorgen. Aber wie viele zufällige PID.XOR gibt es überhaupt?
Mathematiker vor! Insbesondere jene, die sich noch an das Potenzzeichen erinnern!
unsere PID.XOR ist 16 Stellen lang. Wieviele Zahlen kann man mit 16 Bits darstellen?
Wir waren ja oben schonmal bei 8 Bit => 256 Zahlen
8 Bit sind zweimal 4 Bit... und mit 4 Bit gingen 16 Zahlen. 256 ist 16 * 16, das ist kein Zufall.
16 Bit sind zweimal 8 Bit. und mit 8 Bit gingen 256. 256*256 ist 65536.
Das heißt, unter 65536 möglichen PID-XORs sorgen 8 für ein Shiny.
Einfache Bruchrechnung zeigt uns nun, dass dies einem Shiny unter 8192 PID-XORs entspricht.
Ups. Die Zahl hat man schonmal gehört.
Und wenn man davon ausgeht, dass die PID-XORs genauso zufällig sind wie die PIDs an sich, dann kann man jetzt verstehen,
warum durchschnittlich ein Pokemon unter 8192 ein Shiny ist.
Aber wir wollen ja kein PID-XOR haben, sondern eine endgültige PID. Wir wissen zwar jetzt, dass
PID.High XOR PID.Low = 1110110000000???
aber wie hilft uns das weiter?
Abermals erinnern wir uns daran, wie XOR definiert ist - und was wir eigentlich XORen
Die erste Stelle des XOR ist 1, also muss die erste Stelle von PID.High und PID.Low unterschiedlich sein.
Die zweite Stelle des XOR ist 1, also muss die zweite Stelle von PID.High und PID.Low unterschiedlich sein.
Die dritte Stelle des XOR ist 1, also muss die dritte Stelle von PID.High und PID.Low unterschiedlich sein.
Die vierte Stelle des XOR ist 0, also muss die vierte Stelle von PID.High gleich der vierten Stelle von PID.Low sein.
usw.
Die vierzehnte Stelle ist beliebig, also können wir an entsprechender Stelle in beide etwas beliebiges schreiben.
Ebenso Stelle fünfzehn und sechzehn.
Wenn zwei Zahlen unterschiedlich sein müssen, muss eine 1 und die andere 0 sein. Aber welche wird was?
und wenn zwei Zahlen gleich sein müssen, werden sie dann beide 1 oder beide 0?
Jetzt kommt das Witzige: Das ist völlig egal und uns überlassen. Wir kriegen immer wieder ein Shiny heraus.
und wir haben - egal, was rauskommen muss, bei den ersten dreizehn Stellen immer exakt zwei Auswahlmöglichkeiten.
Wir dürfen uns dreizehnmal zwischen zwei Möglichkeiten entscheiden UND
wir dürfen uns noch dreimal für PID.High frei entscheiden (die letzten drei Stellen)
UND wir dürfen uns noch dreimal für PID.Low frei entscheiden.
Insgesamt können wir uns also 19 Mal frei zwischen zwei Möglichkeiten entscheiden und haben bei jeder Auswahl ein Shiny.
Wieviele verschiedene PIDs gibt es denn dann insgesamt?
2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2 (16 mal zwei) kennen wir schon von oben, der Schritt zu 19 mal zwei ist dann nicht mehr weit:
65536*2*2*2=524288
Das heißt, für jeden Trainer gibt es 524288 verschiedene Pokemon-IDs, die zu einem shiny-Pokemon führen.
Ich werde sie hier nicht auflisten, aber dafür gibt es ja eine Bauanleitung.
Aber: "MOMENT! Wenn es eine halbe Million verschiedene Shiny-Nummern gibt.
Ist die Wahrscheinlichkeit auf ein Shiny immer noch 1:8192?"
Berechtigte Frage, 524288 erscheint erstmal sehr groß.
Aber (und hier kommen die Leute ins Spiel, die mal berechnet haben, wie viele Zahlen man mit 32 Bit darstellen kann)
es gibt ja auch sehr sehr viele Pokemon-IDs überhaupt.
Ich spoile mal: 2^32 ist 4294967296. Auf einmal ist 524288 nicht mehr ganz so groß.
524288 aus 4294967296 Pokemon sind Shiny. Bruchrechnung, kürzen, und auf einmal ist es wieder nur noch ein Pokemon aus 8192.
Wir können dieser Zahl einfach nicht entkommen.
Aber bis zur endgültigen PID ist es ja noch ein wenig Weg. Bisher haben wir ja immer noch
1110110000000???
und wissen, an welchen Stellen unsere PID.High gleich PID.Low sein muss.
Treffen wir hier jetzt einfach mal eine Entscheidung, mit der die Zahlen kleiner bleiben sollen
(und das ist jetzt der Punkt, an dem sich jeder später was eigenes überlegen darf)
Wenn ich Zahlen gleich Null setzen kann, werden sie Null.
Wenn ich eine Zahl gleich Eins setzen muss, nehme ich die aus PID.Low.
1110110000000??? (XOR)
0000000000000000 (High)
1110110000000000 (Low)
Jetzt kleben wir die beiden wieder zusammen:
00000000000000001110110000000000
=> 60416 Dezimal
und haben eine PID, mit der das Pokemon Shiny wird.
Zum Test kann man dem PokemonMaker ja mal dem Pokemon diese PID zuweisen (Random PIDs dabei deaktivieren)
und beobachten, dass das "Shiny"-Kästchen auf einmal aufblinkt (einmal auf [Samples to Code] klicken).
Ich habe dieser Freundin auch versprochen, ihr ein Shiny Zubat aufzuspielen.
Also fange ich mit meinem normalen Zubat an.
Dazu habe ich zuerst den Spielstand meines Moduls mit einem speziellen Kabel ausgelesen und anschließend aus
diesen Daten mein Zubat rausgeholt (so etwas ähnliches macht der PokemonReader von FILB auch)
2AF1DD99DEC6C7BFD4CFBCBBCEFF000390430502C4D9E2DDDAD9E600773A0000F4001D8797CFDB2BF4371A26DD371A26A3361A26F4711A2679372A26F4371A26FB231A26F4371A26F4371A26F4371A26
Das jage ich in den PokemonMaker (Code to Samples) und bekomme (neben vielen anderen Informationen):
Jetzt ermittle ich das XOR der beiden Zahlen (entweder von Hand oder über den Rechner)
1011111111000111
1100011011011110
----------------
0111100100011001
0111100100011001
----------------
1010110101011010
1101010001000000
10101101010110101101010001000000
und wandel die Zahl wieder in Dezimal um: (Rechner)
2908410944
Jetzt deaktiviere im Maker "Use Random PIDs" (wenn das aktiv ist, rechnet der sich die PIDs selber aus, ich will aber meine vorgeben) und gebe in PID diese Zahl ein.
Nach "Samples to Code" zeigt mir der Maker an, dass das "neue" Pokemon Shiny ist. Jetzt kann ich die 80 Bytes wieder in den Spielstand schreiben, oder mir (nach Anwahl des Spieles und meines Modules - XPloder ist CB) einen Code dafür erstellen lassen.
Wir verändern die PID. Nun gibt allerdings die PID neben des Shiny-Status noch andere Dinge über das Pokemon vor:
Wenn wir nun die PID verändern, dann kann sich hier also auch alles mögliche ändern.
Während die Datensortierung vom Maker alleine gemacht wird,
die Punkte von Pandir wohl nur die wenigsten interessieren und der Icognito-Buchstabe nur bei Icognitos relevant ist,
könnte es aber durchaus sein, dass ich beispielsweise das Geschlecht beibehalten möchte.
Für die anderen Dinge müsste ich wohl den chinesischen Restsatz bemühen (und um den zu kapieren,
brauche ich auch immer wieder sehr viel Zeit, deswegen lasse ich den hier mal weg),
aber das Geschlecht kann man noch relativ einfach beibehalten.
Das Geschlecht wird definiert durch das letzte Byte der PID (deswegen auch manchmal "GenderByte") und um das zu bekommen,
bemühen wir mal wieder unseren Taschenrechner:
Die alte PID wird ausnahmsweise mal in Hex umgewandelt (Bin geht auch, aber Hex geht schneller):
99DDF12A (Wer sich erinnert, kann das auch einfach aus den 80 Byte von oben rauslesen)
und das letzte Byte sind die letzten zwei Zeichen.
2A -> 42dez
Ruft da jemand mal eben dazwischen? "Moment! Ein Pokemon ist doch entweder männlich oder weiblich oder garnich!
Wieso dann 256 verschiedene Werte? und was heißt 42?"
Ihr habt bestimmt schonmal gehört, dass es Pokemon gibt, die es nur in weiblich gibt.
Andere gibt es nur in männlich. Andere sind meistens männlich (wie die Starter mit nur 13% Frauenanteil),
Andere sind meistens weiblich (Beispielsweise Vulpix mit 75%).
Um solche Verteilungen hinzubekommen, gibt es für jede Spezies Schwellwerte.
Wenn das Genderbyte darüber ist, ist das Pokemon männlich, wenn es darunter bleibt, so ist es weiblich.
Ausnahmen sind natürlich die Pokemon, die _immer_ männlich, weiblich oder garnich sind.
Jetzt könnte man sich aus gängigen Datenbanken raussuchen, welche Geschlechtsverteilung Zubat hat (50%/50%)
und wüsste dann, dass das Genderbyte zwischen 0 und 126 (einschließlich) liegen muss, damit das Pokemon weiblich bleibt.
Mir ist das zu einfach. Aus Prinzip will ich jetzt wieder genau den Wert 42 am Ende haben.
(Wem das reicht: 126 ist 7E, alles darunter ist female)
Dazu muss ich aber auch nochmal kurz ins Binärsystem gehen und überlegen, was wir mit der obigen Suche eigentlich machen:
Kommentar: Hier sind die Bits von hinten nach vorne gezählt, was den Vorteil hat,
dass das vorderste Bit die höchste Nummer hat - was auch dem höchsten Wert entspricht und das hinterste Bit die Nummer 0 bekommt.
Abermals verweise ich auf den Mathematikunterricht und die Potenzfunktion.
Wenn nun das vorderste XOR-Bit 0 werden muss, so müssen (wie oben erklärt) entweder beide Bits 0 oder beide Bits 1 sein.
Wenn beide Bits 0 sind, dann gehen beide Werte *nicht* in die Summe mit ein. => 0
Wenn beide Bits 1 sind, dann gehen beide Werte voll in die Summe mit ein. 2147483648 + 32768 = 2147516416
und zwischen diesen beiden Werten dürfen wir uns entscheiden (wenn das vorderste XOR-Bit 0 ist)
Ist das vorderste XOR-Bit 1, so muss ich exakt eines der beiden PID-Bits auf 1 setzen.
Das eine würde am Ende Bit 31 sein, also würde die 2147483648 in die Summe eingehen.
Das andere würde am Ende Bit 15 sein, also würde 32768 in die Summe eingehen,
und zwischen diesen beiden Werten dürfen wir uns entscheiden (wenn das vorderste XOR-Bit 1 ist)
So geht das runter bis zu Bit 19 (einschließlich)
XOR 0 => entweder 0 oder 524296
XOR 1 => entweder 8 oder 524288
die letzten drei Bits (von jeweils High und Low) können wir jeweils frei vergeben:
Für mein XOR heißt das also:
0111100100011001
0 2147516416
16384 1073741824
8192 536870912
4096 268435456
2048 134217728
0 67109888
0 33554944
256 16777216
0 8388736
0 4194368
0 2097184
16 1048576
8 524288
0 262144
0 131072
0 65536
0 4
0 2
0 1
Für meine Entscheidung von oben
1010110101011010 (High)
1101010001000000 (Low)
heißt das:
2147516416 (beide)
16384 (der kleinere)
536870912 (der größere)
4096 (der kleinere)
134217728 (der größere)
67109888 (beide)
0 (keiner)
16777216 (der größere)
0 (keiner)
4194368 (beide)
0 (keiner)
1048576 (der größere)
524288 (der größere)
0 (frei: nein)
131072 (frei: ja)
0 (frei: nein)
0 (frei: nein)
0 (frei: nein)
0 (frei: nein)
-----
2908410944
Damit haben wir schonmal eine Möglichkeit gefunden, wie wir aus den XOR-Bits direkt eine Auswahl bekommen, in der wir nur noch summieren müssen. Aber das bringt uns unserem Ziel, wieder zur 42 zu kommen (an die "Anhalter": Diese Zahl ist wirklich Zufall!), noch nicht näher, oder?
Denk Dir eine Zahl zwischen 0 und 255. Wandel diese in Hex um.
und ob ich nun den Rest von 75 durch 100 oder von 175 durch 100 betrachte... oder 4356789676897546775 durch hundert, macht irgendwie keinen Unterschied. Somit macht das für Hex keinen Unterschied, ob ich irgendwas aufaddiere, was glatt durch 256 teilbar ist - und irgendwie sind 512, 1024, 2048 usw glatt durch 256 teilbar.
Wer jetzt ein wenig weiter ausprobiert oder nachdenkt (und ich hoffe, dass das jemand tut), dass lediglich Bit 0 bis 7 unser Genderbyte beeinflussen. (analog kann man über den chinesischen Restsatz ermitteln, bis zu welchem Bit man gehen muss, um auch z.B. für Wesen immer eine gewünschte Zahl zu bekommen)
und "zufällig" wissen wir auch, dass man mit Bits 0 bis 7 alle Zahlen zwischen 0 und 255 darstellen kann... Aber können wir auch alle Zahlen frei setzen?
Gehen wir wieder zurück zu unserer Idee des XOR (nicht umsonst habe ich das in der allerersten Lektion gelernt)
XOR = 0 : Beide Werte 1 oder Beide Werte 0
Wir können also das "kleine" Bit immer beliebig setzen - unabhängig, welcher XOR-Bit sich ergeben muss.
nehmen wir nochmal den Taschenrechner und wandeln die gesuchte 42 in binär um.
00101010
(ich habe bereits die führenden Nullen angehängt)
Zur Erinnerung: mein XOR war 0111100100011001
davon interessieren aber eh nur die letzten 8 Bit. Die anderen beeinflussen unseren 256-Rest ja nicht.
00011001
Für meine PIDs ergibt das also schonal folgende Muster:
########00101010 low
########00110xxx high
Die # sind nun wieder "frei wählbar, soweit sie das XOR erfüllen" - die kann ich also z.B. von oben kopieren
Die x sind wieder "völlig frei wählbar", setze ich sie einfach mal 0
1010110100101010 low
1101010000110000 high
Das ganze wieder hintereinandergehängt
11010100001100001010110100101010
und ins dezimale umgewandelt:
3559959850
Der PokemonMaker bestätigt uns weiterhin, dass das Pokemon shiny und weiblich ist.
Ich will das genau wissen und wandel die letzten 8 Bits in dezimale um:
00101010
2+8+32 = 42
und weiß damit jetzt sicher, dass wieder der gleiche Wert im Genderbyte steht.
An dieser Stelle habe ich jetzt alles geschrieben, was auf meinem Notizzettel stand und was mir noch zu dem Thema einfiel.
Wenn noch Fragen sind, so würde ich die gerne hören.
nsbesondere weiß ich, dass einige Leute hier eher abgeschreckt sind.
Sicherlich, es gibt Leute, für die ist das uninteressant, weil sie keine Pokemon auf Ihr Spiel spielen können
(kein Modul, was BoxCodes unterstützt). Andere können ihre Pokemon nicht vom Spiel auf den PC bringen.
Wieder andere haben an dem Thema überhaupt kein interesse und wollen nur [x] shiny anklicken.
Ich hoffe aber doch, dass es den einen oder anderen gibt, der sich wirklich interessiert und
möglicherweise auch Spaß an der Mathematik hat.
Wenn von denen jemand hier irgendwann nicht mehr mitgekommen ist, dann würde ich gerne auch wissen,
wo man als Leser Probleme hat oder etwas nicht versteht -
damit ich dann versuchen kann, das Ganze etwas verständlicher zu machen.
Wenn jemand kein Interesse hat, ist das okay; aber ich fände es sehr schade,
wenn jemand Interesse hatte und ich das nur nicht richtig erklären konnte.