Von: herbert 
14.06.07 - 21:04
14.06.07 - 21:04 
wie kommt man eigentlich darauf, dass die chance, ein shiny zu finden, bei 1:1892 liegt?
Von: peNNy de LuXo
14.06.07 - 22:28
14.06.07 - 22:28
Entweder, Nintendo hat es bekannt gegeben, man hat das Spiel gehackt und nachgeschaut(geht das? :D) oder irgendwelche Nasen haben es errechnet :D
Von: TCCPhreak
15.06.07 - 08:24
15.06.07 - 08:24
und Mogelpower hat den Thread inzwischen gelöscht.
---
Zunächst einmal - wie schon angedroht - ein wenig Mathematik:
(an die Freaks, die sich ein wenig besser auskenne: 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:
2 Hunderter, also 100 * 2
5 Zehner, also 10 * 5
3 Einer, also 1 *3
und das liegt einfach daran, dass die letzte Stelle "eins" wert ist, die vorletzte "zehn" und die davor "einhundert". Jede Stelle ist *zehn*mal soviel wert wie die davor.
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:
1 Hundertvierundvierziger, also 12*12 * 1
3 Zwölfer, also 12 * 3
6 Einer, also 1 * 6
im Dezimalsystem würden wir diese Zahl als 144+36+6 = 186 schreiben.
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:
4 Zwölfer, also 12 * 4
A=10 Einer, also 1 * 10
Ergeben: 48 + 10 = 58 im Dezimalsystem.
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?
Okay, etwas weg von philosophischen Betrachten (noch jemand da?) und wieder etwas zurück zum Thema:
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 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 eine 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:
1 Vierundsechsziger 64 * 1
1 Zweiunddreißiger 32 * 1
0 Sechzehner 16 * 0
0 Achter8 * 0
1 Vierer4 * 1
0 Zweier2 * 0
1 Einer 1 * 1
ergibt 64+32+4+1 = 101... was aber diesmal wirklich "einhundertundeins" ist und nur zufällig die Ziffern 2 bis 9 nicht nutzt.
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.
Manchmal hat man Zahlen im Binärformat und möchte diese lieber dezimal haben.
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.
Bisher schon ausreichend geschockt?
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.
Manchmal hat man Zahlen im Dezimalformat und braucht diese eher im Binärformat.
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.
Umwandlung Dezimal nach Binär:
DEC anklicken, Zahl eingeben, BIN anklicken
Umwandlung Binär nach Dezimal:
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 dann 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
Allerdings muss noch gesagt werden, dass man unterschiedlich lange Zahlen XORen kann, indem man die kürzere Zahl vorne mit Nullen auffüllt, bis sie lang genug ist (habe ich hier für die erste getan)
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.
Vielleicht schonmal ein Ausblick:
Ob ein Pokemon shiny ist, ergibt sich aus dem Verschlüsselungscode. und 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.
Das solls dann aber auch für den Anfang gewesen sein.
Grüße,
TCC
-------
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
Windows-Taschenrechner sagt das selbe.
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
und das ist nun die Pokemon ID, PID, im Pokemon Reader auch RND und manchmal auch Personality Value genannt, relativ einzigartig für jedes Pokemon und wenn man zwei mit der gleichen PID trifft, dann ist das ein sehr großer Zufall (läst sich wohl meist eher auf Cheaten zurückführen)
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.
---
Die einfache Methode:
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:
1001 -> 9
1101 -> 13 = D
0100 -> 4
1011 -> 11 = B
1101 -> 13 = D
0101 -> 5
1111 -> 15 = F
0010 -> 2
9D4BD5F2
Diese Zahl steht auch im Maker unter XKey. Dies ist nämlich der Schlüssel, mit dem hinterher große Teile der Pokemon-Daten verschlüsselt sind. Die Verschlüsselung interessiert uns erstmal nicht (Widersprüche?).
Diesen XKey teilen wir nun wieder in Stücke zu 16 Bit auf und machen ein XOR davon:
1001110101001011
1101010111110010
----------------
0100100010111001
Wer will, kann diese Nummer jetzt noch einmal umwandeln (18617 dez), wer genau hinguckt, merkt aber schon vorher, dass diese Zahl größer als 7 ist.
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
=> Shiny.
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.
Trotzdem will ich das etwas weiter im Detail erläutern.
Wenn es bis dahin (themenbezogene) Fragen gibt, nur her damit!
Grüße,
TCC
------
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)
Das ist ein wenig doof, weil wir unsere "Variable" PID sowohl links als auch rechts haben. Das möchten wir gerne ändern:
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)
und jetzt haben wir die linke Seite von der ShinyNr fest. Wir müssen also nur noch schauen, wie wir die rechte Seite nutzen können, um das Ergebnis unter 8 zu prügeln. Das heißt, die ersten 13 Zahlen müssen auf Null gedrückt werden.
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)
Die letzten drei Stellen sind uns völlig egal, weil man mit ihnen nur Zahlen unter 8 darstellen kann.
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.
Mal wieder ein Matheeinschub:
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)
ups... dass PID.High dabei komplett Null wird, war jetzt wirklich nicht beabsichtigt, ist aber logisch.
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).
------
So... hier nochmal ein wenig Nachtrag mit einer Kurzanleitung bzw einem weiteren Beispiel:
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):
Meine OT Secret ID: 49095
meine OT ID: 50910
Alte PID: 2581459242
Die Trainer-IDs wandel ich über den Windows-Rechner in Binär um:
Secret: 1011111111000111
Offen : 1100011011011110
und ergänze die Zahlen mit Nullen vorne, bis sie 16 Stellen haben.
Hier sind die Zahlen bereits groß genug, also keine Änderung.
Jetzt ermittle ich das XOR der beiden Zahlen (entweder von Hand oder über den Rechner)
1011111111000111
1100011011011110
----------------
0111100100011001
Anschließend suche ich mir zwei beliebige Zahlen, deren XOR in den ersten 13 Stellen mit dem ersten übereinstimmt:
0111100100011001
----------------
1010110101011010
1101010001000000
hänge eine vor die andere (beliebig)
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.
---
Noch eine lange Kleinigkeit:
Wir verändern die PID. Nun gibt allerdings die PID neben des Shiny-Status noch andere Dinge über das Pokemon vor:
Nature (Wesen, Mod 25)
Datensortierung (mod 24)
Spindas (Pandirs) Punkte (Jedes Byte ein Punkt, jedes Nibble eine Koordinate)
Den Buchstaben, wenn es ein Icognito ist. (BitMasking)
Die Entwicklungsrichtung von Wurmple (Einfluss nicht bekannt, Wiki-Information inkorrekt)
und das Geschlecht. (mod 256)
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 13%), 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:
Das erste XOR-Bit wird zu Bit 15 von PID.High und Bit 15 von PID.Low
PID.High wird zum Schluss vor PID.Low geklebt, somit wandert Bit 15 um 16 Stellen, also:
Das erste XOR-Bit wird zu Bit 31 und 15 der PID.
Bit 31 ist 2147483648 wert, Bit 15 ist 32768 wert.
Das zweite XOR-Bit wird zu Bit 30 und 14 der PID
Bit 30 ist 1073741824 wert, Bit 14 ist 16384 wert
Bit 29 ist 536870912 wert, Bit 12 ist 8192 wert
Bit 28 ist 268435456 wert, Bit 12 ist 4096 wert
Bit 27 ist 134217728 wert, Bit 11 ist 2048 wert
Bit 26 ist 67108864 wert, Bit 10 ist 1024 wert
Bit 25 ist 33554432 wert, Bit 9 ist 512 wert
Bit 24 ist 16777216 wert, Bit 8 ist 256 wert
Bit 23 ist 8388608 wert, Bit 7 ist 128 wert
Bit 22 ist 4194304 wert, Bit 6 ist 64 wert
Bit 21 ist 2097152 wert, Bit 5 ist 32 wert
Bit 20 ist 1048576 wert, Bit 4 ist 16 wert
Bit 19 ist 524288 wert, Bit 3 ist 8 wert
Bit 18 ist 262144 wert, Bit 2 ist 4 wert
Bit 17 ist 131072 wert, Bit 1 ist 2 wert
Bit 16 ist 65536 wert, Bit 0 ist 1 wert
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:
Bit 18: entweder 0 oder 262144
Bit 17: entweder 0 oder 131072
Bit 16: entweder 0 oder 65536
Bit 2: entweder 0 oder 4
Bit 1: entweder 0 oder 2
Bit 0: entweder 0 oder 1
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
aus jeder Zeile suche ich mir einen Wert auf und addiere die alle zusammen (Tipp: M+ auf Taschenrechner)
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
puh... es kommt tatsächlich das Gleiche raus. Zwischenzeitlich hatte ich da so meine Bedenken.
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?
Dazu ein kleines Spielchen:
Denk Dir eine Zahl zwischen 0 und 255. Wandel diese in Hex um.
Zähle zu Deiner Zahl 256 dazu. Wandel das Ergebnis in Hex um. Betrachte die letzten beiden Ziffern.
Zähle zu Deiner Zahl 2147483648 dazu. Wandel das Ergebnis in Hex um. Betrachte die letzten beiden Ziffern.
Nimm nochmal Deine alte Zahl, zähle 32768 dazu, Wandel das Ergebnis in Hex um. Betrachte die letzten beiden Ziffern.
Nimm nochmal Deine alte Zahl, zähle 32768+2147483648=2147516416 dazu. Wandel das Ergebnis in Hex um...
Ich hoffe, an dieser Stelle fällt etwas auf: Es gibt Zahlen, die können wir beliebig aufaddieren, das letzte Byte ändert sich dabei nicht.
Wer den mathematischen Hintergrund haben will: Die letzten beiden Ziffern in Hex entsprechen dem Rest, wenn man die Zahl durch 256 teilt... So wie die letzten beiden Ziffern in Dez dem Rest entsprechen, den man übrig hat, wenn man durch 100 teilt.
und ob ich nun den Rest von 75 durch 100 oder 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
Beide Werte 0: insbesondere das "kleine" Bit ist 0
Beide Werte 1: insbesondere das "kleine" Bit ist 1, das größere beeinflusst unseren 256-Rest nicht.
XOR = 1 : Exakt ein Wert 1, der andere 0
"Kleines" Bit 1, das andere 0, aber beeinflusst nicht
"großes" Bit 1 (aber beeinflusst nicht), das kleine 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
Bit 7 darf nicht gesetzt sein, XOR muss 0 ergeben, also wähle ich die "beide Null"-Version
Bit 6 darf nicht gesetzt sein, XOR muss 0 ergeben, also wähle ich die "beide Null"-Version
Bit 5 muss gesetzt sein, XOR muss 0 ergeben, also wähle ich die "beide Eins"-Version
Bit 4 darf nicht gesetzt sein, XOR muss 1 ergeben, also wähle ich die "kleines Bit Null"-Version (großes Bit Eins)
Bit 3 muss gesetzt sein, XOR muss 1 ergeben, also wähle ich die "kleines Bit Eins"-Version (großes Bit Null)
Bit 2 darf nicht gesetzt sein, XOR gibt keine Einschränkung.
Bit 1 muss gesetzt sein, XOR gibt keine Einschränkung.
Bit 0 darf nicht gesetzt sein, XOR gibt keine Einschränkung.
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.
Insbesondere weiß ich, dass einige Leute hier eher abgeschreckt sind. Sicherlich, es gibt Leute, für die ist das interessant, 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. und 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.
Grüße,
TCC
---
Das Folgende ist noch nicht im Netz und noch nicht ganz fertig, aber vielleicht hilft das trotzdem dem einen oder anderen weiter:
In Sachen Shiny (etwas mehr Richtung Wahrscheinlichkeiten)
Zunächst:
- Jedes Pokemon existiert auch in einer Shiny-Variante.
- Die Shiny-Pokemon halten sich genau dort auf, wo man auch die "normalen" Pokemon finden kann.
- Ab Gold/Silber/Kristall ist der Shiny-Status sichtbar
in Blau/Rot/Gelb wurde er nicht angezeigt. Aber auch Pokemon dort können shiny sein - auch wenn man es nicht sieht. Tauscht man ein Shiny aus G/S/C in B/R/G und anschließend wieder zurück, so ist es weiterhin shiny.
- Shiny-Pokemon sind nicht zwangsläufig stärker als andere.
- Ein Pokemon in der Wildnis ist mit der Wahrscheinlichkeit 1/8192 shiny. Woher diese Zahl 8192=2^13 stammt, kann man in der mathematischen Erklärung nachlesen.
Zu der Wahrscheinlichkeit wollte ich hier etwas mehr erklären - gerade, weil dazu auch immer wieder Fragen aufkommen. Ich möchte allerdings auch kurz anmerken, dass viele Fragen auch vom Mathelehrer des Vertrauens beantwortet werden.
1:8192 ist erstmal eine Wahrscheinlichkeit. Dieser wollen wir nun ein Bild geben:
Stellen wir uns eine Schüssel mit 8192 Gummibärchen vor. Davon sind 8191 einfache rote Gummibärchen, das letzte ist ein besonderes Goldbärchen.
Stellen wir uns nun vor, wir dürfen aus dieser Schüssel mit geschlossen Augen ein Gummibärchen ziehen und uns dann ansehen, welche Farbe es hat. Anschließend legen wir es wieder zurück. Eventuell ziehen wir danach unter den gleichen Bedingungen nochmal.. und nochmal..
An dieser Stelle sollten wir uns klar machen, dass wir schon mit dem ersten Griff das Goldbärchen erwischen können. Ich sage nicht, dass das sehr wahrscheinlich ist, aber es ist möglich.
Außerdem sollte uns klar sein, dass wir eventuell bis in alle Ewigkeit ziehen und doch immer wieder daneben greifen können. Intuitiv glauben wir zwar "irgendwann erwische ich das Teil!", aber es ist halt doch möglich, es immer wieder zu verfehlen.
Auf Pokemon bezogen:
Es ist möglich, das Spiel erstmalig anzuschalten und sofort einen Shiny Starter zu bekommen.
Und es ist möglich, Hunderte von Spielstunden anzusammeln ohne jemals ein einziges Shiny auch nur zu sehen. ("und das ist soooo gemein... Da mache ich soviel Mathematik und Wahrscheinlichkeitsrechnung und spiele solche Ewigkeiten auf so vielen verschiedenen Editionen - und doch ist noch nie ein Shiny aufgetaucht")
---
Wie gesagt: Intuitiv glauben wir "es ist doch nicht möglich, dass ich immer wieder versuche und doch nie eines kriege". Dazu muss man nun sagen: Es ist nicht unmöglich. Es wird nur "sehr sehr unwahrscheinlich." (wer das Zitat nicht kennt, muss was nachholen)
Aber wie unwahrscheinlich wird das eigentlich?
An dieser Stelle ändern wir mal unsere Vorstellung. von unseren 8191 gewöhnlichen Gummibärchen werden 8186 an die kleine Schwester verfüttert, so dass es in unserer Schüssel nur noch 5 gewöhnliche Gummibärchen mit einem Goldbärchen streiten. Und wenn wir schon soweit sind, kleben wir die jetzt alle auf die 6 Seiten eines Würfels und stellen uns vor, wir würfeln nur noch. Also eine Seite des Würfels ist Gold, die anderen nur rot. Man kann sich auch vorstellen, dass wir versuchen, eine 6 zu würfeln.
Wie man nun wissen sollte, liegt die Wahrscheinlichkeit dazu bei 1/6 (bei einem fairen Würfel)
und auch hier wieder die Parallele: Mit Glück kann ich im ersten Zug mein Männchen vom Start ins Spielfeld bringen. Mit viel Pech haben alle Mitspieler alle Männchen schon im Ziel bevor ich das erste Mal eine 6 sehe.
Aber was heißt "viel Pech"?
Nunja:
Im ersten Wurf beträgt die Wahrscheinlichkeit, *keine* 6 zu würfeln 5/6 (= 1 - 1/6)
Im zweiten Wurf beträgt die Wahrscheinlichkeit, *keine* 6 zu würfeln 5/6 (= 1 - 1/6)
Im dritten Wurf beträgt die Wahrscheinlichkeit, *keine* 6 zu würfeln 5/6 (= 1 - 1/6)
und dabei ist immer egal, was ich vorher schon gewürfelt habe.
Das heißt: wenn ich wutentbrannt meinen Würfel das hundertste Mal durch den Raum pfeffer, dann ist das Ergebnis des Wurfes "unabhängig" von den ersten 99 erfüwrfelten Zahlen.
Wie bringt uns das weiter? Es gibt nun eine Regel in der Wahrscheinlichkeitsrechnung, die uns sagt, dass die Wahrscheinlichkeit für zwei _unabhängige_ Ereignisse gleich dem Produkt der Einzelwahrscheinlichkeiten ist.
Das heißt: Die Wahrscheinlichkeit, im ersten Wurf keine 6 zu würfeln UND im zweiten Wurf keine 6 zu würfeln ist 5/6 * 5/6 = 25/36.
Schauen wir uns das mal in Dezimal an:
5/6 ~ 0,833333
25/36 ~ 0,69444
das heißt, die Wahrscheinlichkeit, zweimal keine 6 zu würfeln, ist schon kleiner als die Wahrscheinlichkeit einmal keine 6 zu würfeln. Umgekehrt heißt das, dass wir eine bessere Chance haben, mindestens eine sechs zu würfeln, wenn wir zweimal würfeln.
(und das war uns irgendwie vorher auch schon klar, aber jetzt haben wir da wenigstens etwas Mathematik drin)
Wie sieht das nun aus, wenn wir dreimal würfeln? Im ersten Wurf keine 6 => 5/6, im zweiten Wurf keine 6 => 5/6, im dritten Wurf keine 6 => 5/6, also (5/6)*(5/6)*(5/6) = 125/216 ~ 0,578703
Ab dem vierten Wurf sollte das Prinzip dann klar sein. Aus der Grundschulmathematik nehmen wir dann noch das praktische ^ - Zeichen mit und finden heraus (5/6)*(5/6)*(5/6)*(5/6)= (5/6)^4 ~ 0,48225
Moment! Wenn die Wahrscheinlichkeit, viermal _keine_ 6 zu würfeln, unter 0,5 liegt, so heißt das doch, dass die Wahrscheinlichkeit, mindestens einmal eine 6 zu würfeln, besser als 50% ist. Und das ist mathematisch auch völlig korrekt.
Die Sache mit den 8192 Gummibärchen sieht natürlich von der Wahrscheinlichkeit her sehr viel fieser aus, aber das Prinzip ist das gleiche.
---
Kehren wir also nun wieder zu unserer Schüssel zurück; lösen die Gummibärchen vom Würfel ab und packen sie mit 8186 _neuen_ roten Gummibärchen wieder zurück in die Schüssel.
Irgendwann zwischendurch trösten wir die kleine Schwester dann auch, dass das mit den Bauchschmerzen "ganz bestimmt und ganz bald" wieder besser wird - und überlegen uns, wie wir die Fragen der Eltern beantworten:
"WOHER hattest Du 1600 einfarbige Gummibärchen?" - "Du hast WAS damit gemacht?"
Wie mit dem Würfel arbeiten wir nun mit 8191/8192
Erster Versuch kein Shiny: 8191/8192 ~ 0,999877929
zweiter Versuch (8191/8192)^2 ~ 0,999755874
dritter Versuch (8191/8192)^3 ~ 0,999633833
vierter Versuch (8191/8192)^4 ~ 0,999511808
Man kann nun sehen, dass das nicht so schnell unter 50% fällt wie bei dem Würfel. Ab dem wievielten Wurf wird das denn nun so *richtig* unwahrscheinlich, niemals ein Shiny bekommen zu haben?
Für die Antwort kann man nun tapfer weiter rechnen. Oder Papa fragen, wie man Excel benutzt. Oder den Mathelehrer seines Vertrauens fragen, was "Logarithmus" heißt und wozu man den braucht.
Ich will hier nur mal ein paar Ergebnisse aufschreiben:
5678.ter Versuch (8191/8192)^5678 ~ 0,49999482
Das heißt: Wenn man 5678 Pokemon trifft... (oder 5678 mal das gleiche Pokemon trifft - um mal die "Ich starte so lange neu, bis der Starter/das Legendäre/das Evoli"-Fraktion einzubeziehen), ist die Wahrscheinlichkeit, dass eines davon shiny war, leicht besser als 50%.
Bildbeispiel: Sperre 1000 Spieler in einen Raum, lasse jeden 5678 Pokemon treffen und bei einem guten Zufallsgenerator werden 500 Spieler hinterher mindestens ein Shiny gesehen haben. Die anderen halt nicht. (und laut Murphy bin ich einer der "anderen")
11356.ter Versuch (8191/8192)^11356 ~ 0,24999482 < 25%
gleiches Beispiel: 3 von 4 Spielern werden mindestens ein Shiny gesehen haben. Immerhin nur noch 250 Spieler, die leer ausgehen.
18862.ter Versuch: ~0,099995432 < 10%
Also wenn man das Spiel zum 18862. Mal neu gestartet hat, hat man entweder mindestens ein Shiny gesehen oder gehört zu den unglücklichen 10%
56585.ter Versuch: ~0,00099985 < 0,1%
Im Bildbeispiel würde das heißen, dass ein einziger ohne Shiny nach Hause gehen muss.
Auf der anderen Seite kann man das natürlich auch so sehen, dass bei 1000 Spielern mit je 56585 Versuchen im Erwartungswert etwa 6907 Shinys aufgetaucht sein sollten und sicherlich wird sich da einer der anderen Spieler erbarmen und dem unglücklichen Spieler (das bin ich) eines von seinen geben.
---
Um sich nun unter 5678 etwas vorzustellen: Wie lange braucht man, um das Spiel zu starten, dem Pokemon zu begegnen und zu prüfen, ob es shiny ist - und dann das Spiel wieder neu zu starten?
Man kann beliebig große Zahlen in den Raum werfen, aber mit diesem Zeitfaktor kann man sich schon vorstellen, dass Shiny-Suche eine zeitraubende Sache ist.
Und vor allem unvorhersehbar.
Wenn jemand fragt "Wie viele Stunden muss ich neustarten, bis ich ein Shiny habe?" dann ist die richtige Antwort "das kommt auf Dein Glück an"
Wenn jemand fragt "Wie viele Stunden muss ich neustarten, damit ich sicher ein Shiny habe?", dann ist die richtige Antwort "Was heißt 'sicher?'"
Wenn jemand fragt "Wie viele Stunden muss ich neustarten, damit ich mit 100% Wahrscheinlichkeit ein Shiny habe?", dann ist die richtige Antwort "Wie lange wirst Du leben?"
---
Grüße,
TCC
---
Zunächst einmal - wie schon angedroht - ein wenig Mathematik:
(an die Freaks, die sich ein wenig besser auskenne: 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:
2 Hunderter, also 100 * 2
5 Zehner, also 10 * 5
3 Einer, also 1 *3
und das liegt einfach daran, dass die letzte Stelle "eins" wert ist, die vorletzte "zehn" und die davor "einhundert". Jede Stelle ist *zehn*mal soviel wert wie die davor.
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:
1 Hundertvierundvierziger, also 12*12 * 1
3 Zwölfer, also 12 * 3
6 Einer, also 1 * 6
im Dezimalsystem würden wir diese Zahl als 144+36+6 = 186 schreiben.
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:
4 Zwölfer, also 12 * 4
A=10 Einer, also 1 * 10
Ergeben: 48 + 10 = 58 im Dezimalsystem.
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?
Okay, etwas weg von philosophischen Betrachten (noch jemand da?) und wieder etwas zurück zum Thema:
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 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 eine 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:
1 Vierundsechsziger 64 * 1
1 Zweiunddreißiger 32 * 1
0 Sechzehner 16 * 0
0 Achter8 * 0
1 Vierer4 * 1
0 Zweier2 * 0
1 Einer 1 * 1
ergibt 64+32+4+1 = 101... was aber diesmal wirklich "einhundertundeins" ist und nur zufällig die Ziffern 2 bis 9 nicht nutzt.
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.
Manchmal hat man Zahlen im Binärformat und möchte diese lieber dezimal haben.
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.
Bisher schon ausreichend geschockt?
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.
Manchmal hat man Zahlen im Dezimalformat und braucht diese eher im Binärformat.
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.
Umwandlung Dezimal nach Binär:
DEC anklicken, Zahl eingeben, BIN anklicken
Umwandlung Binär nach Dezimal:
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 dann 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
Allerdings muss noch gesagt werden, dass man unterschiedlich lange Zahlen XORen kann, indem man die kürzere Zahl vorne mit Nullen auffüllt, bis sie lang genug ist (habe ich hier für die erste getan)
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.
Vielleicht schonmal ein Ausblick:
Ob ein Pokemon shiny ist, ergibt sich aus dem Verschlüsselungscode. und 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.
Das solls dann aber auch für den Anfang gewesen sein.
Grüße,
TCC
-------
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
Windows-Taschenrechner sagt das selbe.
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
und das ist nun die Pokemon ID, PID, im Pokemon Reader auch RND und manchmal auch Personality Value genannt, relativ einzigartig für jedes Pokemon und wenn man zwei mit der gleichen PID trifft, dann ist das ein sehr großer Zufall (läst sich wohl meist eher auf Cheaten zurückführen)
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.
---
Die einfache Methode:
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:
1001 -> 9
1101 -> 13 = D
0100 -> 4
1011 -> 11 = B
1101 -> 13 = D
0101 -> 5
1111 -> 15 = F
0010 -> 2
9D4BD5F2
Diese Zahl steht auch im Maker unter XKey. Dies ist nämlich der Schlüssel, mit dem hinterher große Teile der Pokemon-Daten verschlüsselt sind. Die Verschlüsselung interessiert uns erstmal nicht (Widersprüche?).
Diesen XKey teilen wir nun wieder in Stücke zu 16 Bit auf und machen ein XOR davon:
1001110101001011
1101010111110010
----------------
0100100010111001
Wer will, kann diese Nummer jetzt noch einmal umwandeln (18617 dez), wer genau hinguckt, merkt aber schon vorher, dass diese Zahl größer als 7 ist.
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
=> Shiny.
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.
Trotzdem will ich das etwas weiter im Detail erläutern.
Wenn es bis dahin (themenbezogene) Fragen gibt, nur her damit!
Grüße,
TCC
------
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)
Das ist ein wenig doof, weil wir unsere "Variable" PID sowohl links als auch rechts haben. Das möchten wir gerne ändern:
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)
und jetzt haben wir die linke Seite von der ShinyNr fest. Wir müssen also nur noch schauen, wie wir die rechte Seite nutzen können, um das Ergebnis unter 8 zu prügeln. Das heißt, die ersten 13 Zahlen müssen auf Null gedrückt werden.
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)
Die letzten drei Stellen sind uns völlig egal, weil man mit ihnen nur Zahlen unter 8 darstellen kann.
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.
Mal wieder ein Matheeinschub:
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)
ups... dass PID.High dabei komplett Null wird, war jetzt wirklich nicht beabsichtigt, ist aber logisch.
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).
------
So... hier nochmal ein wenig Nachtrag mit einer Kurzanleitung bzw einem weiteren Beispiel:
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):
Meine OT Secret ID: 49095
meine OT ID: 50910
Alte PID: 2581459242
Die Trainer-IDs wandel ich über den Windows-Rechner in Binär um:
Secret: 1011111111000111
Offen : 1100011011011110
und ergänze die Zahlen mit Nullen vorne, bis sie 16 Stellen haben.
Hier sind die Zahlen bereits groß genug, also keine Änderung.
Jetzt ermittle ich das XOR der beiden Zahlen (entweder von Hand oder über den Rechner)
1011111111000111
1100011011011110
----------------
0111100100011001
Anschließend suche ich mir zwei beliebige Zahlen, deren XOR in den ersten 13 Stellen mit dem ersten übereinstimmt:
0111100100011001
----------------
1010110101011010
1101010001000000
hänge eine vor die andere (beliebig)
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.
---
Noch eine lange Kleinigkeit:
Wir verändern die PID. Nun gibt allerdings die PID neben des Shiny-Status noch andere Dinge über das Pokemon vor:
Nature (Wesen, Mod 25)
Datensortierung (mod 24)
Spindas (Pandirs) Punkte (Jedes Byte ein Punkt, jedes Nibble eine Koordinate)
Den Buchstaben, wenn es ein Icognito ist. (BitMasking)
Die Entwicklungsrichtung von Wurmple (Einfluss nicht bekannt, Wiki-Information inkorrekt)
und das Geschlecht. (mod 256)
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 13%), 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:
Das erste XOR-Bit wird zu Bit 15 von PID.High und Bit 15 von PID.Low
PID.High wird zum Schluss vor PID.Low geklebt, somit wandert Bit 15 um 16 Stellen, also:
Das erste XOR-Bit wird zu Bit 31 und 15 der PID.
Bit 31 ist 2147483648 wert, Bit 15 ist 32768 wert.
Das zweite XOR-Bit wird zu Bit 30 und 14 der PID
Bit 30 ist 1073741824 wert, Bit 14 ist 16384 wert
Bit 29 ist 536870912 wert, Bit 12 ist 8192 wert
Bit 28 ist 268435456 wert, Bit 12 ist 4096 wert
Bit 27 ist 134217728 wert, Bit 11 ist 2048 wert
Bit 26 ist 67108864 wert, Bit 10 ist 1024 wert
Bit 25 ist 33554432 wert, Bit 9 ist 512 wert
Bit 24 ist 16777216 wert, Bit 8 ist 256 wert
Bit 23 ist 8388608 wert, Bit 7 ist 128 wert
Bit 22 ist 4194304 wert, Bit 6 ist 64 wert
Bit 21 ist 2097152 wert, Bit 5 ist 32 wert
Bit 20 ist 1048576 wert, Bit 4 ist 16 wert
Bit 19 ist 524288 wert, Bit 3 ist 8 wert
Bit 18 ist 262144 wert, Bit 2 ist 4 wert
Bit 17 ist 131072 wert, Bit 1 ist 2 wert
Bit 16 ist 65536 wert, Bit 0 ist 1 wert
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:
Bit 18: entweder 0 oder 262144
Bit 17: entweder 0 oder 131072
Bit 16: entweder 0 oder 65536
Bit 2: entweder 0 oder 4
Bit 1: entweder 0 oder 2
Bit 0: entweder 0 oder 1
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
aus jeder Zeile suche ich mir einen Wert auf und addiere die alle zusammen (Tipp: M+ auf Taschenrechner)
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
puh... es kommt tatsächlich das Gleiche raus. Zwischenzeitlich hatte ich da so meine Bedenken.
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?
Dazu ein kleines Spielchen:
Denk Dir eine Zahl zwischen 0 und 255. Wandel diese in Hex um.
Zähle zu Deiner Zahl 256 dazu. Wandel das Ergebnis in Hex um. Betrachte die letzten beiden Ziffern.
Zähle zu Deiner Zahl 2147483648 dazu. Wandel das Ergebnis in Hex um. Betrachte die letzten beiden Ziffern.
Nimm nochmal Deine alte Zahl, zähle 32768 dazu, Wandel das Ergebnis in Hex um. Betrachte die letzten beiden Ziffern.
Nimm nochmal Deine alte Zahl, zähle 32768+2147483648=2147516416 dazu. Wandel das Ergebnis in Hex um...
Ich hoffe, an dieser Stelle fällt etwas auf: Es gibt Zahlen, die können wir beliebig aufaddieren, das letzte Byte ändert sich dabei nicht.
Wer den mathematischen Hintergrund haben will: Die letzten beiden Ziffern in Hex entsprechen dem Rest, wenn man die Zahl durch 256 teilt... So wie die letzten beiden Ziffern in Dez dem Rest entsprechen, den man übrig hat, wenn man durch 100 teilt.
und ob ich nun den Rest von 75 durch 100 oder 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
Beide Werte 0: insbesondere das "kleine" Bit ist 0
Beide Werte 1: insbesondere das "kleine" Bit ist 1, das größere beeinflusst unseren 256-Rest nicht.
XOR = 1 : Exakt ein Wert 1, der andere 0
"Kleines" Bit 1, das andere 0, aber beeinflusst nicht
"großes" Bit 1 (aber beeinflusst nicht), das kleine 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
Bit 7 darf nicht gesetzt sein, XOR muss 0 ergeben, also wähle ich die "beide Null"-Version
Bit 6 darf nicht gesetzt sein, XOR muss 0 ergeben, also wähle ich die "beide Null"-Version
Bit 5 muss gesetzt sein, XOR muss 0 ergeben, also wähle ich die "beide Eins"-Version
Bit 4 darf nicht gesetzt sein, XOR muss 1 ergeben, also wähle ich die "kleines Bit Null"-Version (großes Bit Eins)
Bit 3 muss gesetzt sein, XOR muss 1 ergeben, also wähle ich die "kleines Bit Eins"-Version (großes Bit Null)
Bit 2 darf nicht gesetzt sein, XOR gibt keine Einschränkung.
Bit 1 muss gesetzt sein, XOR gibt keine Einschränkung.
Bit 0 darf nicht gesetzt sein, XOR gibt keine Einschränkung.
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.
Insbesondere weiß ich, dass einige Leute hier eher abgeschreckt sind. Sicherlich, es gibt Leute, für die ist das interessant, 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. und 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.
Grüße,
TCC
---
Das Folgende ist noch nicht im Netz und noch nicht ganz fertig, aber vielleicht hilft das trotzdem dem einen oder anderen weiter:
In Sachen Shiny (etwas mehr Richtung Wahrscheinlichkeiten)
Zunächst:
- Jedes Pokemon existiert auch in einer Shiny-Variante.
- Die Shiny-Pokemon halten sich genau dort auf, wo man auch die "normalen" Pokemon finden kann.
- Ab Gold/Silber/Kristall ist der Shiny-Status sichtbar
in Blau/Rot/Gelb wurde er nicht angezeigt. Aber auch Pokemon dort können shiny sein - auch wenn man es nicht sieht. Tauscht man ein Shiny aus G/S/C in B/R/G und anschließend wieder zurück, so ist es weiterhin shiny.
- Shiny-Pokemon sind nicht zwangsläufig stärker als andere.
- Ein Pokemon in der Wildnis ist mit der Wahrscheinlichkeit 1/8192 shiny. Woher diese Zahl 8192=2^13 stammt, kann man in der mathematischen Erklärung nachlesen.
Zu der Wahrscheinlichkeit wollte ich hier etwas mehr erklären - gerade, weil dazu auch immer wieder Fragen aufkommen. Ich möchte allerdings auch kurz anmerken, dass viele Fragen auch vom Mathelehrer des Vertrauens beantwortet werden.
1:8192 ist erstmal eine Wahrscheinlichkeit. Dieser wollen wir nun ein Bild geben:
Stellen wir uns eine Schüssel mit 8192 Gummibärchen vor. Davon sind 8191 einfache rote Gummibärchen, das letzte ist ein besonderes Goldbärchen.
Stellen wir uns nun vor, wir dürfen aus dieser Schüssel mit geschlossen Augen ein Gummibärchen ziehen und uns dann ansehen, welche Farbe es hat. Anschließend legen wir es wieder zurück. Eventuell ziehen wir danach unter den gleichen Bedingungen nochmal.. und nochmal..
An dieser Stelle sollten wir uns klar machen, dass wir schon mit dem ersten Griff das Goldbärchen erwischen können. Ich sage nicht, dass das sehr wahrscheinlich ist, aber es ist möglich.
Außerdem sollte uns klar sein, dass wir eventuell bis in alle Ewigkeit ziehen und doch immer wieder daneben greifen können. Intuitiv glauben wir zwar "irgendwann erwische ich das Teil!", aber es ist halt doch möglich, es immer wieder zu verfehlen.
Auf Pokemon bezogen:
Es ist möglich, das Spiel erstmalig anzuschalten und sofort einen Shiny Starter zu bekommen.
Und es ist möglich, Hunderte von Spielstunden anzusammeln ohne jemals ein einziges Shiny auch nur zu sehen. ("und das ist soooo gemein... Da mache ich soviel Mathematik und Wahrscheinlichkeitsrechnung und spiele solche Ewigkeiten auf so vielen verschiedenen Editionen - und doch ist noch nie ein Shiny aufgetaucht")
---
Wie gesagt: Intuitiv glauben wir "es ist doch nicht möglich, dass ich immer wieder versuche und doch nie eines kriege". Dazu muss man nun sagen: Es ist nicht unmöglich. Es wird nur "sehr sehr unwahrscheinlich." (wer das Zitat nicht kennt, muss was nachholen)
Aber wie unwahrscheinlich wird das eigentlich?
An dieser Stelle ändern wir mal unsere Vorstellung. von unseren 8191 gewöhnlichen Gummibärchen werden 8186 an die kleine Schwester verfüttert, so dass es in unserer Schüssel nur noch 5 gewöhnliche Gummibärchen mit einem Goldbärchen streiten. Und wenn wir schon soweit sind, kleben wir die jetzt alle auf die 6 Seiten eines Würfels und stellen uns vor, wir würfeln nur noch. Also eine Seite des Würfels ist Gold, die anderen nur rot. Man kann sich auch vorstellen, dass wir versuchen, eine 6 zu würfeln.
Wie man nun wissen sollte, liegt die Wahrscheinlichkeit dazu bei 1/6 (bei einem fairen Würfel)
und auch hier wieder die Parallele: Mit Glück kann ich im ersten Zug mein Männchen vom Start ins Spielfeld bringen. Mit viel Pech haben alle Mitspieler alle Männchen schon im Ziel bevor ich das erste Mal eine 6 sehe.
Aber was heißt "viel Pech"?
Nunja:
Im ersten Wurf beträgt die Wahrscheinlichkeit, *keine* 6 zu würfeln 5/6 (= 1 - 1/6)
Im zweiten Wurf beträgt die Wahrscheinlichkeit, *keine* 6 zu würfeln 5/6 (= 1 - 1/6)
Im dritten Wurf beträgt die Wahrscheinlichkeit, *keine* 6 zu würfeln 5/6 (= 1 - 1/6)
und dabei ist immer egal, was ich vorher schon gewürfelt habe.
Das heißt: wenn ich wutentbrannt meinen Würfel das hundertste Mal durch den Raum pfeffer, dann ist das Ergebnis des Wurfes "unabhängig" von den ersten 99 erfüwrfelten Zahlen.
Wie bringt uns das weiter? Es gibt nun eine Regel in der Wahrscheinlichkeitsrechnung, die uns sagt, dass die Wahrscheinlichkeit für zwei _unabhängige_ Ereignisse gleich dem Produkt der Einzelwahrscheinlichkeiten ist.
Das heißt: Die Wahrscheinlichkeit, im ersten Wurf keine 6 zu würfeln UND im zweiten Wurf keine 6 zu würfeln ist 5/6 * 5/6 = 25/36.
Schauen wir uns das mal in Dezimal an:
5/6 ~ 0,833333
25/36 ~ 0,69444
das heißt, die Wahrscheinlichkeit, zweimal keine 6 zu würfeln, ist schon kleiner als die Wahrscheinlichkeit einmal keine 6 zu würfeln. Umgekehrt heißt das, dass wir eine bessere Chance haben, mindestens eine sechs zu würfeln, wenn wir zweimal würfeln.
(und das war uns irgendwie vorher auch schon klar, aber jetzt haben wir da wenigstens etwas Mathematik drin)
Wie sieht das nun aus, wenn wir dreimal würfeln? Im ersten Wurf keine 6 => 5/6, im zweiten Wurf keine 6 => 5/6, im dritten Wurf keine 6 => 5/6, also (5/6)*(5/6)*(5/6) = 125/216 ~ 0,578703
Ab dem vierten Wurf sollte das Prinzip dann klar sein. Aus der Grundschulmathematik nehmen wir dann noch das praktische ^ - Zeichen mit und finden heraus (5/6)*(5/6)*(5/6)*(5/6)= (5/6)^4 ~ 0,48225
Moment! Wenn die Wahrscheinlichkeit, viermal _keine_ 6 zu würfeln, unter 0,5 liegt, so heißt das doch, dass die Wahrscheinlichkeit, mindestens einmal eine 6 zu würfeln, besser als 50% ist. Und das ist mathematisch auch völlig korrekt.
Die Sache mit den 8192 Gummibärchen sieht natürlich von der Wahrscheinlichkeit her sehr viel fieser aus, aber das Prinzip ist das gleiche.
---
Kehren wir also nun wieder zu unserer Schüssel zurück; lösen die Gummibärchen vom Würfel ab und packen sie mit 8186 _neuen_ roten Gummibärchen wieder zurück in die Schüssel.
Irgendwann zwischendurch trösten wir die kleine Schwester dann auch, dass das mit den Bauchschmerzen "ganz bestimmt und ganz bald" wieder besser wird - und überlegen uns, wie wir die Fragen der Eltern beantworten:
"WOHER hattest Du 1600 einfarbige Gummibärchen?" - "Du hast WAS damit gemacht?"
Wie mit dem Würfel arbeiten wir nun mit 8191/8192
Erster Versuch kein Shiny: 8191/8192 ~ 0,999877929
zweiter Versuch (8191/8192)^2 ~ 0,999755874
dritter Versuch (8191/8192)^3 ~ 0,999633833
vierter Versuch (8191/8192)^4 ~ 0,999511808
Man kann nun sehen, dass das nicht so schnell unter 50% fällt wie bei dem Würfel. Ab dem wievielten Wurf wird das denn nun so *richtig* unwahrscheinlich, niemals ein Shiny bekommen zu haben?
Für die Antwort kann man nun tapfer weiter rechnen. Oder Papa fragen, wie man Excel benutzt. Oder den Mathelehrer seines Vertrauens fragen, was "Logarithmus" heißt und wozu man den braucht.
Ich will hier nur mal ein paar Ergebnisse aufschreiben:
5678.ter Versuch (8191/8192)^5678 ~ 0,49999482
Das heißt: Wenn man 5678 Pokemon trifft... (oder 5678 mal das gleiche Pokemon trifft - um mal die "Ich starte so lange neu, bis der Starter/das Legendäre/das Evoli"-Fraktion einzubeziehen), ist die Wahrscheinlichkeit, dass eines davon shiny war, leicht besser als 50%.
Bildbeispiel: Sperre 1000 Spieler in einen Raum, lasse jeden 5678 Pokemon treffen und bei einem guten Zufallsgenerator werden 500 Spieler hinterher mindestens ein Shiny gesehen haben. Die anderen halt nicht. (und laut Murphy bin ich einer der "anderen")
11356.ter Versuch (8191/8192)^11356 ~ 0,24999482 < 25%
gleiches Beispiel: 3 von 4 Spielern werden mindestens ein Shiny gesehen haben. Immerhin nur noch 250 Spieler, die leer ausgehen.
18862.ter Versuch: ~0,099995432 < 10%
Also wenn man das Spiel zum 18862. Mal neu gestartet hat, hat man entweder mindestens ein Shiny gesehen oder gehört zu den unglücklichen 10%
56585.ter Versuch: ~0,00099985 < 0,1%
Im Bildbeispiel würde das heißen, dass ein einziger ohne Shiny nach Hause gehen muss.
Auf der anderen Seite kann man das natürlich auch so sehen, dass bei 1000 Spielern mit je 56585 Versuchen im Erwartungswert etwa 6907 Shinys aufgetaucht sein sollten und sicherlich wird sich da einer der anderen Spieler erbarmen und dem unglücklichen Spieler (das bin ich) eines von seinen geben.
---
Um sich nun unter 5678 etwas vorzustellen: Wie lange braucht man, um das Spiel zu starten, dem Pokemon zu begegnen und zu prüfen, ob es shiny ist - und dann das Spiel wieder neu zu starten?
Man kann beliebig große Zahlen in den Raum werfen, aber mit diesem Zeitfaktor kann man sich schon vorstellen, dass Shiny-Suche eine zeitraubende Sache ist.
Und vor allem unvorhersehbar.
Wenn jemand fragt "Wie viele Stunden muss ich neustarten, bis ich ein Shiny habe?" dann ist die richtige Antwort "das kommt auf Dein Glück an"
Wenn jemand fragt "Wie viele Stunden muss ich neustarten, damit ich sicher ein Shiny habe?", dann ist die richtige Antwort "Was heißt 'sicher?'"
Wenn jemand fragt "Wie viele Stunden muss ich neustarten, damit ich mit 100% Wahrscheinlichkeit ein Shiny habe?", dann ist die richtige Antwort "Wie lange wirst Du leben?"
---
Grüße,
TCC
Von: Junger Link
16.06.07 - 12:58 (16.06.07 - 12:59)
16.06.07 - 12:58 (16.06.07 - 12:59)
So viel kann ich nicht lesen.......... =O
Hast du das alles selber geschrieben??? =O
Hast du das alles selber geschrieben??? =O
Von: Nintendogsfreund
16.06.07 - 14:04
16.06.07 - 14:04
LoL...
Also ich hab es nicht kapiert!
Ich bleib dabei: Shiny ist sehrsehrsehr selten und mir ist es egal wie selten, hauptsache ich weiß ob shiny pokemon häufig manchmal oder sehr selten sind.
Also ich hab es nicht kapiert!
Ich bleib dabei: Shiny ist sehrsehrsehr selten und mir ist es egal wie selten, hauptsache ich weiß ob shiny pokemon häufig manchmal oder sehr selten sind.
Von: TCCPhreak
16.06.07 - 15:29
16.06.07 - 15:29
junger Link:
jaja... die jungen von heute... einfach keine Ausdauer mehr. :-P
Klar ist das alles selbst geschrieben... allerdings hatte ich das vor ein paar Monaten und in mehreren Abschnitten geschrieben (und gepostet)
Nintendogsfreund:
Wenn Du mir sagst, ab welcher Stelle Du es nicht mehr kapiert hast, kann ich gerne versuchen, weiterzuhelfen. Ich gebe zu, dass der erste Teil mit der Mathematik etwas abschreckend ist - und zudem durch "benutz den Taschenrechner" abgekürzt werden könnte.
1:8192 ist selten. Ja. "Etwa" so selten, wie 13mal in Folge Kopf mit einer fairen Münze zu werfen. oder 13mal in Folge mit einem Würfel eine gerade Zahl.
(oder 13mal in Folge mit einem Würfel eine ungerade Zahl *G*)
Grüße,
TCC
jaja... die jungen von heute... einfach keine Ausdauer mehr. :-P
Klar ist das alles selbst geschrieben... allerdings hatte ich das vor ein paar Monaten und in mehreren Abschnitten geschrieben (und gepostet)
Nintendogsfreund:
Wenn Du mir sagst, ab welcher Stelle Du es nicht mehr kapiert hast, kann ich gerne versuchen, weiterzuhelfen. Ich gebe zu, dass der erste Teil mit der Mathematik etwas abschreckend ist - und zudem durch "benutz den Taschenrechner" abgekürzt werden könnte.
1:8192 ist selten. Ja. "Etwa" so selten, wie 13mal in Folge Kopf mit einer fairen Münze zu werfen. oder 13mal in Folge mit einem Würfel eine gerade Zahl.
(oder 13mal in Folge mit einem Würfel eine ungerade Zahl *G*)
Grüße,
TCC
Von: zythoplasma
16.06.07 - 16:01
16.06.07 - 16:01
tcc
tipp für dich SCHREIB NET ZU VIEL
kein schwein liest,geschweige denn versteht diesen roman.
wenn ich dir schreiben würde an welcher stelle ich was nicht versteh dann müsstes du mir ALLES übersetzen
Ps:ist nicht böse gemeint
tipp für dich SCHREIB NET ZU VIEL
kein schwein liest,geschweige denn versteht diesen roman.
wenn ich dir schreiben würde an welcher stelle ich was nicht versteh dann müsstes du mir ALLES übersetzen
Ps:ist nicht böse gemeint
Von: TCCPhreak
16.06.07 - 19:36
16.06.07 - 19:36
zytho:
Das ist lieb gemeint... aber trotzdem hatte ich das nunmal geschrieben... und wenn das jemand nochmal wissen will, poste ich das gerne.
Dass ich das damals geschrieben habe, war übrigens auch für mich. Damit kann ich mir sicherer sein, dass ich es verstanden habe... dass ich es erklären kann... und auf diese Art und Weise gibt es dieses Textdokument, wenn doch mal jemand lesen will. (und das hoffe ich mal)
Zu übersetzen gibt es da eh nix... höchstens zu erklären. und eigentlich fängt man damit oben an.
Grüße,
TCC
Das ist lieb gemeint... aber trotzdem hatte ich das nunmal geschrieben... und wenn das jemand nochmal wissen will, poste ich das gerne.
Dass ich das damals geschrieben habe, war übrigens auch für mich. Damit kann ich mir sicherer sein, dass ich es verstanden habe... dass ich es erklären kann... und auf diese Art und Weise gibt es dieses Textdokument, wenn doch mal jemand lesen will. (und das hoffe ich mal)
Zu übersetzen gibt es da eh nix... höchstens zu erklären. und eigentlich fängt man damit oben an.
Grüße,
TCC
Von: Dialga das Pokemon
07.07.07 - 12:09
07.07.07 - 12:09
wie lange hast du fuer das alles gebraucht um das zu schreiben?
Von: SuperMario1
07.07.07 - 15:36
07.07.07 - 15:36
ok tcc...
erklär mir das ganze mal in kurzer formulierung
ps:hab mir das ganze durchgelesen hab aber nichts verstanden
thx im vorraus
erklär mir das ganze mal in kurzer formulierung
ps:hab mir das ganze durchgelesen hab aber nichts verstanden
thx im vorraus
Von: TCCPhreak
07.07.07 - 18:08
07.07.07 - 18:08
Die kurze Formulierung:
Wenn Du ein wildes Pokemon triffst, wird dafür eine Pokemon-ID ausge"würfelt". (32 Bit) Diese wird mit Deiner Trainer-ID zusammengerechnet (XOR) und das Resultat nochmal mit sich selbst (High XOR Low).
Wenn die resultierende Zahl dann kleiner 8 sind (von 16 bit müssen die ersten 13 =0 sein.), ist das Pokemon shiny.
mit einigen "oBdAs" heißt das: Der Gameboy muss 13 mal hintereinander "Kopf" beim Münzwurf schaffen. Die Wahrscheinlichkeit für 1mal Kopf ist 1/2, für zweimal Kopf ist (1/2)*(1/2)=1/4=1/2^2
für dreimal Kopf ist 1/2^3=1/8
und für dreizehnmal Kopf 1/2^13=1/8192
Stell Dir vor, Du hast 13 1-Cent-Münzen, wirfst sie alle zusammen in die Luft und hoffst darauf, dass alle auf der Zahlenseite landen.
Grüße,
TCC
(der gestern endlich sein allererstes Shiny gefangen hat *freu*)
Wenn Du ein wildes Pokemon triffst, wird dafür eine Pokemon-ID ausge"würfelt". (32 Bit) Diese wird mit Deiner Trainer-ID zusammengerechnet (XOR) und das Resultat nochmal mit sich selbst (High XOR Low).
Wenn die resultierende Zahl dann kleiner 8 sind (von 16 bit müssen die ersten 13 =0 sein.), ist das Pokemon shiny.
mit einigen "oBdAs" heißt das: Der Gameboy muss 13 mal hintereinander "Kopf" beim Münzwurf schaffen. Die Wahrscheinlichkeit für 1mal Kopf ist 1/2, für zweimal Kopf ist (1/2)*(1/2)=1/4=1/2^2
für dreimal Kopf ist 1/2^3=1/8
und für dreizehnmal Kopf 1/2^13=1/8192
Stell Dir vor, Du hast 13 1-Cent-Münzen, wirfst sie alle zusammen in die Luft und hoffst darauf, dass alle auf der Zahlenseite landen.
Grüße,
TCC
(der gestern endlich sein allererstes Shiny gefangen hat *freu*)
Von: Hannibal Lecter
09.07.07 - 18:59
09.07.07 - 18:59
ich habe mal ein shiny regiroc gesehen und dann 4 oder 5 stunden an und aus gemacht weil ich des eine nicht gefangen habe und kein neues shiny kam.danch kam ich zu dem entschluss, das ein shiny sehr selten ist.dafür bracuhe ich keine fromel aber trotzdem danke TCC.
@ TCC in der zeit, in der du das geschrieben hasst, hätteste sicherlich 1 shiny gesehen^^
@ TCC in der zeit, in der du das geschrieben hasst, hätteste sicherlich 1 shiny gesehen^^
Von: TCCPhreak
10.07.07 - 22:49
10.07.07 - 22:49
Hannibal:
Dadurch, dass ich mir die Zeit genommen habe, mal darüber nachzudenken, konnte ich wissen, dass eine direkte Suche zu langwierig wäre - somit habe ich Zeit gespart... und wenn ich mit dem Text andere davon abgebracht habe, die Zeit zu verschwenden, hat sich das schon gelohnt.
Abgesehen davon:
Ich wollte ebenfalls mal wissen, woher diese Zahl genau kommt und wie das alles intern funktioniert. Ich bin einfach neugierig. Und wenn ich das erstmal raushabe und meine Notizen wegpacken will, ist es am einfachsten, sie direkt ins Netz zu stellen.
Also die Zeit, die ich mit Recherche und Schreiben verbracht habe, hätte ich eh nicht mit Shiny-Suchen verbracht.
Grüße,
TCC
Dadurch, dass ich mir die Zeit genommen habe, mal darüber nachzudenken, konnte ich wissen, dass eine direkte Suche zu langwierig wäre - somit habe ich Zeit gespart... und wenn ich mit dem Text andere davon abgebracht habe, die Zeit zu verschwenden, hat sich das schon gelohnt.
Abgesehen davon:
Ich wollte ebenfalls mal wissen, woher diese Zahl genau kommt und wie das alles intern funktioniert. Ich bin einfach neugierig. Und wenn ich das erstmal raushabe und meine Notizen wegpacken will, ist es am einfachsten, sie direkt ins Netz zu stellen.
Also die Zeit, die ich mit Recherche und Schreiben verbracht habe, hätte ich eh nicht mit Shiny-Suchen verbracht.
Grüße,
TCC
Von: Hannibal Lecter
10.07.07 - 22:59 (10.07.07 - 23:01)
10.07.07 - 22:59 (10.07.07 - 23:01)
cool ich dachte du hasst mal gelesen wie man auf die zahl kommt hätte nciht gedacht das du das selbst gemacht hast.
und meine bemerkung sollte ein spaß sein, weil du so viiiel geschrieben hasst. auch wenn du es in abschnitten geschrieben hasst, weist du noch ungefähr wie lange es gedauert hat? würde mich interriseren^^
PS: ich glaube nicht, das du 6 oder 7 jahre alt bist^^ vonwegen am 1.1.2001 geboren^^
und meine bemerkung sollte ein spaß sein, weil du so viiiel geschrieben hasst. auch wenn du es in abschnitten geschrieben hasst, weist du noch ungefähr wie lange es gedauert hat? würde mich interriseren^^
PS: ich glaube nicht, das du 6 oder 7 jahre alt bist^^ vonwegen am 1.1.2001 geboren^^
Von: TCCPhreak
11.07.07 - 16:47
11.07.07 - 16:47
Ich hatte die Zahl auch zuerst irgendwo gelesen... aber weil ich dann mal erfahren habe, was genau die Kriterien für Shiny sind, wollte ich das mal damit nachrechnen.
Gibt ja genug Schund im Netz, den man einfach nur mal ausprobieren oder drüber nachdenken muss, um zu sehen, dass er nicht stimmt.
Außerdem hat mir diese Recherche sehr dabei geholfen, Shinys zu erstellen, die nicht gekünstelt aussehen. Natürlich nur einmal als Proof-of-concept und nicht für die eigene Sammlung.
Die Frage ist, was Du zum "Dauern" zählst... Das Schreiben oder das Experimentieren... das drüber nachdenken oder das Einlesen. Ich denke, man kann schwer einschätzen, wie lange man an sowas gesessen hat.
und mein Alter... tja, ich weiß nicht, ob ich Default gelassen habe oder schon damals dachte, dass es niemanden interessiert... aber das ist so falsch wie mein ICQ-Profil (aber aus anderen Gründen)
Grüße,
TCC
Gibt ja genug Schund im Netz, den man einfach nur mal ausprobieren oder drüber nachdenken muss, um zu sehen, dass er nicht stimmt.
Außerdem hat mir diese Recherche sehr dabei geholfen, Shinys zu erstellen, die nicht gekünstelt aussehen. Natürlich nur einmal als Proof-of-concept und nicht für die eigene Sammlung.
Die Frage ist, was Du zum "Dauern" zählst... Das Schreiben oder das Experimentieren... das drüber nachdenken oder das Einlesen. Ich denke, man kann schwer einschätzen, wie lange man an sowas gesessen hat.
und mein Alter... tja, ich weiß nicht, ob ich Default gelassen habe oder schon damals dachte, dass es niemanden interessiert... aber das ist so falsch wie mein ICQ-Profil (aber aus anderen Gründen)
Grüße,
TCC
Logge dich ein um einen Beitrag zu schreiben.