Von: TCCPhreak 
22.12.06 - 16:06 (22.12.06 - 16:11)
22.12.06 - 16:06 (22.12.06 - 16:11) 
Hallo,
nachdem im damaligen Thread http://www.mogelpower.de/forum/thread.php?thread_id=193644 unheimlich viele Fragen aufgekommen und beantwortet worden sind (Lach) und ich jede Menge Fanpost erhalten habe (Doppel-Lach) überlege ich nun, nochmal ein Thema detaillierter in Angriff zu nehmen.
Ginge um das Thema der "Pokemon in AlternativFarbe". Ich denke, dieses Thema ist für einige Leute sehr interessant.
Im Prinzip ist das ja im Maker relativ einfach: Man klickt das Feld [] Shiny an, lässt neue PIDs zu, und gibt das Ergebnis hinter in sein Spiel ein.
Ich habe mich allerdings mal darüber informiert, wie das spielintern mit den Shinys wirklich funktioniert und vor kurzem mal überlegt, welche Nummern eigentlich für Shinys erlaubt sind - so dass man sich seine eigene Nummer erzeugen kann und nicht auf die Zufallsfunktion des Makers angewiesen ist - und gerne würde ich meine Erkenntnisse mit anderen Interessierten teilen.
Grundidee dabei ist, dass man kein neues Shiny-Pokemon einfach anlegt, sondern ein bestehendes in ein Shiny umwandelt. (Würde im Beispiel geschehen)
Ich hoffe, dass das nicht zu mathematisch wird (alles mathematische wird vorher erklärt - ist wirklich nicht viel) und dass jeder hinterher mit einem normalen Taschenrechner selber in der Lage ist, die "richtigen" Nummern zu finden. (Taschenrechner optional *g*)
Dabei wird dann erklärt, woher eigentlich diese Wahrscheinlichkeit 1:8192 kommt, und dass es eigentlich "relativ viele" Pokemon in der Wildnis gibt, die Shiny sind. Wenn man zufällig auf ein Pokemon trifft, gibt es nicht nur eines oder zwei... oder acht oder 8192, die shiny wären, sondern mehr als eine halbe Million. (was dann aber auch bedeutet, dass es noch ein "paar" mehr gibt, die nicht shiny sind).
Bevor ich mich aber daran setze und meine Unterlagen nochmal für Leser aufbereite, wollte ich doch erstmal fragen, ob das jemanden interessiert.
Denn wenn das eh keiner lesen möchte (nicht jeder interessiert sich für solche Sachen), dann wäre es schön, wenn hier vorher jemand schreiben würde, dass das niemand wissen will, bevor ich mich umsonst an Romane setze.
Grüße,
TCC
@Moderatoren:
Eigentlich wollte ich diesen Beitrag an den alten Thread dranhängen - schließlich soll man ja nicht für alles neue Thread aufmachen -, aber leider hat der Forum-Roboter mir gesagt, dass das nicht erwünscht ist. Tut mir Leid.
nachdem im damaligen Thread http://www.mogelpower.de/forum/thread.php?thread_id=193644 unheimlich viele Fragen aufgekommen und beantwortet worden sind (Lach) und ich jede Menge Fanpost erhalten habe (Doppel-Lach) überlege ich nun, nochmal ein Thema detaillierter in Angriff zu nehmen.
Ginge um das Thema der "Pokemon in AlternativFarbe". Ich denke, dieses Thema ist für einige Leute sehr interessant.
Im Prinzip ist das ja im Maker relativ einfach: Man klickt das Feld [] Shiny an, lässt neue PIDs zu, und gibt das Ergebnis hinter in sein Spiel ein.
Ich habe mich allerdings mal darüber informiert, wie das spielintern mit den Shinys wirklich funktioniert und vor kurzem mal überlegt, welche Nummern eigentlich für Shinys erlaubt sind - so dass man sich seine eigene Nummer erzeugen kann und nicht auf die Zufallsfunktion des Makers angewiesen ist - und gerne würde ich meine Erkenntnisse mit anderen Interessierten teilen.
Grundidee dabei ist, dass man kein neues Shiny-Pokemon einfach anlegt, sondern ein bestehendes in ein Shiny umwandelt. (Würde im Beispiel geschehen)
Ich hoffe, dass das nicht zu mathematisch wird (alles mathematische wird vorher erklärt - ist wirklich nicht viel) und dass jeder hinterher mit einem normalen Taschenrechner selber in der Lage ist, die "richtigen" Nummern zu finden. (Taschenrechner optional *g*)
Dabei wird dann erklärt, woher eigentlich diese Wahrscheinlichkeit 1:8192 kommt, und dass es eigentlich "relativ viele" Pokemon in der Wildnis gibt, die Shiny sind. Wenn man zufällig auf ein Pokemon trifft, gibt es nicht nur eines oder zwei... oder acht oder 8192, die shiny wären, sondern mehr als eine halbe Million. (was dann aber auch bedeutet, dass es noch ein "paar" mehr gibt, die nicht shiny sind).
Bevor ich mich aber daran setze und meine Unterlagen nochmal für Leser aufbereite, wollte ich doch erstmal fragen, ob das jemanden interessiert.
Denn wenn das eh keiner lesen möchte (nicht jeder interessiert sich für solche Sachen), dann wäre es schön, wenn hier vorher jemand schreiben würde, dass das niemand wissen will, bevor ich mich umsonst an Romane setze.
Grüße,
TCC
@Moderatoren:
Eigentlich wollte ich diesen Beitrag an den alten Thread dranhängen - schließlich soll man ja nicht für alles neue Thread aufmachen -, aber leider hat der Forum-Roboter mir gesagt, dass das nicht erwünscht ist. Tut mir Leid.
Von: Mr. dark Spider
22.12.06 - 17:01
22.12.06 - 17:01
Denn 7. Absatz(Dabei wir dann...) verstehe ich nicht ganz.
Von: TCCPhreak
22.12.06 - 19:16
22.12.06 - 19:16
Ich denke, es ist inzwischen relativ bekannt, dass die Chance, dass ein zufällig in der Wildnis gefundenes Pokemon shiny ist, bei 1:8192 liegt. Also von 8192 Pokemon ist eines shiny (wobei ich mir sicher bin, ich habe schon gegen viel mehr gekämpft - und doch noch kein Shiny gefunden).
Freaks interessieren sich nun aber nicht nur dafür, dass diese Zahl 8192 lautet, sondern auch, wie sich diese Zahl herleitet. In dem Moment kann man auch um einiges fundierter den Leuten widersprechen, die irgendwelche anderen wilden Zahlen in den Raum werfen.
Jetzt klingt 1:8192 sehr unwahrscheinlich und man glaubt eigentlich kaum, dass so viele shiny-Pokemon in der Wildnis rumlaufen. Und doch gibt es unter allen Möglichkeiten mehr als eine halbe Million davon. (Auch diese Zahl würde ich einmal herleiten)
Grüße,
TCC
Freaks interessieren sich nun aber nicht nur dafür, dass diese Zahl 8192 lautet, sondern auch, wie sich diese Zahl herleitet. In dem Moment kann man auch um einiges fundierter den Leuten widersprechen, die irgendwelche anderen wilden Zahlen in den Raum werfen.
Jetzt klingt 1:8192 sehr unwahrscheinlich und man glaubt eigentlich kaum, dass so viele shiny-Pokemon in der Wildnis rumlaufen. Und doch gibt es unter allen Möglichkeiten mehr als eine halbe Million davon. (Auch diese Zahl würde ich einmal herleiten)
Grüße,
TCC
Von: TCCPhreak
22.12.06 - 21:27
22.12.06 - 21:27
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
(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
Von: Mr. dark Spider
22.12.06 - 23:55
22.12.06 - 23:55
Ich habe mir jetzt nicht alles durchgelesen(zu müde)
aber ist dass nicht dass selbe wie dass hier:
http://pokemonpalace.net/maker/ ?
aber ist dass nicht dass selbe wie dass hier:
http://pokemonpalace.net/maker/ ?
Von: TCCPhreak
23.12.06 - 11:20 (23.12.06 - 11:21)
23.12.06 - 11:20 (23.12.06 - 11:21)
Das selbe ist es sicherlich nicht.
Wir werden wahrscheinlich an ein paar Stellen den PokemonMaker von kpdAvatar verwenden (Auslesen von IDs, berechnen des Shiny-Pokemon) - obwohl das auch ohne Maker möglich wäre.
Man kann auch einfach im Maker [] shiny anklicken und dann sucht der automatisch eine passende Nummer raus. Dieser Thread ist aber eher für die Leute gedacht, die gerne wissen wollen, wie das wirklich funktioniert und sich eigene Nummern erstellen möchten.
Grüße,
TCC
PS: Der Link von Dir verweist nicht auf die aktuellste Version. Eine aktuellere findet man bei BoomSpeed und irgendjemand hat mal den AR für die deutsche Smaragd geaddet und woanders online gestellt.
Wir werden wahrscheinlich an ein paar Stellen den PokemonMaker von kpdAvatar verwenden (Auslesen von IDs, berechnen des Shiny-Pokemon) - obwohl das auch ohne Maker möglich wäre.
Man kann auch einfach im Maker [] shiny anklicken und dann sucht der automatisch eine passende Nummer raus. Dieser Thread ist aber eher für die Leute gedacht, die gerne wissen wollen, wie das wirklich funktioniert und sich eigene Nummern erstellen möchten.
Grüße,
TCC
PS: Der Link von Dir verweist nicht auf die aktuellste Version. Eine aktuellere findet man bei BoomSpeed und irgendjemand hat mal den AR für die deutsche Smaragd geaddet und woanders online gestellt.
Von: LinG LinG
23.12.06 - 15:42
23.12.06 - 15:42
Ich glaube, Du hast zuviel freie Zeit TCCPhreak.. xD
Von: TCCPhreak
23.12.06 - 18:25
23.12.06 - 18:25
LinG:
Weil ich das analysiere? Oder weil ich das weitererkläre?
Das eine ist einfach Neugierde (und dann ist die Zeit eher nebensächlich), das andere ist Fairness.
Grüße,
TCC
Weil ich das analysiere? Oder weil ich das weitererkläre?
Das eine ist einfach Neugierde (und dann ist die Zeit eher nebensächlich), das andere ist Fairness.
Grüße,
TCC
Von: TCCPhreak
24.12.06 - 08:56 (24.12.06 - 08:57)
24.12.06 - 08:56 (24.12.06 - 08:57)
Hallo,
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
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
Von: TCCPhreak
24.12.06 - 13:58
24.12.06 - 13:58
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 einShiny 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).
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 einShiny 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).
Von: ike111
24.12.06 - 23:10
24.12.06 - 23:10
@TCCPhreak
Ich glaube nicht das irgendjemand das alles da oben schnallt.Das Einzige was ich jetzt weiß,ist das du aus normalen Pokemon,Shinys machen willst.Mehr erklärt mir der Text da oben nicht.Und wie willst du die Pokemon Edition mit dem Pc verbinden?
Ich glaube nicht das irgendjemand das alles da oben schnallt.Das Einzige was ich jetzt weiß,ist das du aus normalen Pokemon,Shinys machen willst.Mehr erklärt mir der Text da oben nicht.Und wie willst du die Pokemon Edition mit dem Pc verbinden?
Von: TCCPhreak
25.12.06 - 11:34
25.12.06 - 11:34
Hallo Ike,
ich finde es auf jeden Fall schön, eine Rückmeldung zu bekommen, auch wenn es eine "das versteht wahrscheinlich niemand" ist. Natürlich würde mich da interessieren, wo das mit dem Verständnis aufhört, damit ich das dann an der Stelle etwas detaillierter und/oder verständlicher erklären kann.
Wie man die Pokemon vom Spiel auf den PC bekommt und umgekehrt, überlasse ich eher dem Anwender. Wenn man sich das Modul _legal_ auf den PC kopiert hat, dann wird wohl der virtuelle GBA schon direkt seine Savegams auf Platte ausgeben, so dass man dadran kann. Einige Mogelmodule unterstützen die Übertragung des Spielstandes auf den PC, andere auch wieder zurück. Wenn man sich das Pokemon umgewandelt hat und wieder einen 80Byte-Code hat, dann kann man es auch per BoxCode wieder auf sein Modul spielen.
Mein Setup:
Auslesen des Spielstandes über ein FlashAdvance (oder so) Kabel. Normalerweise wird das wohl verwendet, Sicherheitskopien von Spielen zu machen oder selbstprogrammierte Spiele auf ein programmierbares Modul zu schreiben (obwohl es sicherlich auch Nutzer gibt, die das illegal nutzen).
Rückspielen der Einzelpokemon per BoxCode über XPloder.
Grüße,
TCC
ich finde es auf jeden Fall schön, eine Rückmeldung zu bekommen, auch wenn es eine "das versteht wahrscheinlich niemand" ist. Natürlich würde mich da interessieren, wo das mit dem Verständnis aufhört, damit ich das dann an der Stelle etwas detaillierter und/oder verständlicher erklären kann.
Wie man die Pokemon vom Spiel auf den PC bekommt und umgekehrt, überlasse ich eher dem Anwender. Wenn man sich das Modul _legal_ auf den PC kopiert hat, dann wird wohl der virtuelle GBA schon direkt seine Savegams auf Platte ausgeben, so dass man dadran kann. Einige Mogelmodule unterstützen die Übertragung des Spielstandes auf den PC, andere auch wieder zurück. Wenn man sich das Pokemon umgewandelt hat und wieder einen 80Byte-Code hat, dann kann man es auch per BoxCode wieder auf sein Modul spielen.
Mein Setup:
Auslesen des Spielstandes über ein FlashAdvance (oder so) Kabel. Normalerweise wird das wohl verwendet, Sicherheitskopien von Spielen zu machen oder selbstprogrammierte Spiele auf ein programmierbares Modul zu schreiben (obwohl es sicherlich auch Nutzer gibt, die das illegal nutzen).
Rückspielen der Einzelpokemon per BoxCode über XPloder.
Grüße,
TCC
Von: TCCPhreak
26.12.06 - 22:23
26.12.06 - 22:23
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
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
Von: goldener scherox
27.12.06 - 02:02
27.12.06 - 02:02
@tcc
ich fands besonderst interessant (hab viel gelernt)
aber was genau entscheidet, welche farben die shinys haben? zB: von rosa Kyogre war noch niemand beeindruckend...
was entscheidet, wie schwer ein pkmn zu fangen ist?
was entscheidet,wo welche pkmn wie selten kommen
palimpalim zb: ich habe 2 stunden danach gesucht
-.-* , um auf ein shiny palimpalim zu treffen ist die chonce bestimmt NOCH geringer O_O
wrd bei ninjatom auch die IDs und all das zeug kopiert?
wenn ja, könnte man aus shiny nincada, shiny ninjast UND shiny ninjatom machen. ;)
also ich veränder nix an mein spielstand, ich möchte mein shinys per zufall finden *g*
ich fands besonderst interessant (hab viel gelernt)
aber was genau entscheidet, welche farben die shinys haben? zB: von rosa Kyogre war noch niemand beeindruckend...
was entscheidet, wie schwer ein pkmn zu fangen ist?
was entscheidet,wo welche pkmn wie selten kommen
palimpalim zb: ich habe 2 stunden danach gesucht
-.-* , um auf ein shiny palimpalim zu treffen ist die chonce bestimmt NOCH geringer O_O
wrd bei ninjatom auch die IDs und all das zeug kopiert?
wenn ja, könnte man aus shiny nincada, shiny ninjast UND shiny ninjatom machen. ;)
also ich veränder nix an mein spielstand, ich möchte mein shinys per zufall finden *g*
Von: TCCPhreak
27.12.06 - 14:15
27.12.06 - 14:15
Was entscheidet, welche Farben die Shinys haben:
Das entscheiden die Programmierer. Jede Species gibt es nur in Normal- und in Alternativfarbe. Wenn Du zehn Shiny Kyogre hast, dann sehen sie alle gleich aus. Ohne ernsthafte Reprogrammierung wirst Du die Farbe nicht ändern können.
Wie schwer ein Pokemon zu fangen ist:
Jede Species hat in seinen Daten eine sogenannte "Fangrate" zwischen 3 und 255. Wenn Du einen Ball wirfst, wird eine Zufallszahl ermittelt (mit diversen Faktoren, wie der Typ des Balles, der Status des Pokemon etc) und wenn diese unterhalb der Fangrate ist, wird das Pokemon gefangen. Sonst nicht.
Wo welche Pokemon wie selten kommen:
Ist im Spiel programmiert. Irgendwo habe ich mal eine Liste gesehen und war doch sehr abgeschreckt, dass die WKeit für Icognito ? und Icognito ! bei 1% bzw 2% liegt.
Mein Ninjask und Ninjatom haben die gleiche PID, also gehe ich davon aus, dass das für alle gilt. Somit müsste Deine Entwicklung möglich sein. Wenn Du das mal ausprobieren willst, weißt Du ja jetzt, wie Du ein Shiny Nincada bekommst.
BTW: Die PID ändert sich beim Entwickeln nicht, also wird ein Shiny auch nach der Entwicklung noch shiny sein.
Ich habe auch nicht vor, mir massenweise Shinys auf meinen Spielstand zu laden. Ich wollte nur mal sehen und erklären, wie es funktioniert.
Grüße,
TCC
Das entscheiden die Programmierer. Jede Species gibt es nur in Normal- und in Alternativfarbe. Wenn Du zehn Shiny Kyogre hast, dann sehen sie alle gleich aus. Ohne ernsthafte Reprogrammierung wirst Du die Farbe nicht ändern können.
Wie schwer ein Pokemon zu fangen ist:
Jede Species hat in seinen Daten eine sogenannte "Fangrate" zwischen 3 und 255. Wenn Du einen Ball wirfst, wird eine Zufallszahl ermittelt (mit diversen Faktoren, wie der Typ des Balles, der Status des Pokemon etc) und wenn diese unterhalb der Fangrate ist, wird das Pokemon gefangen. Sonst nicht.
Wo welche Pokemon wie selten kommen:
Ist im Spiel programmiert. Irgendwo habe ich mal eine Liste gesehen und war doch sehr abgeschreckt, dass die WKeit für Icognito ? und Icognito ! bei 1% bzw 2% liegt.
Mein Ninjask und Ninjatom haben die gleiche PID, also gehe ich davon aus, dass das für alle gilt. Somit müsste Deine Entwicklung möglich sein. Wenn Du das mal ausprobieren willst, weißt Du ja jetzt, wie Du ein Shiny Nincada bekommst.
BTW: Die PID ändert sich beim Entwickeln nicht, also wird ein Shiny auch nach der Entwicklung noch shiny sein.
Ich habe auch nicht vor, mir massenweise Shinys auf meinen Spielstand zu laden. Ich wollte nur mal sehen und erklären, wie es funktioniert.
Grüße,
TCC
Logge dich ein um einen Beitrag zu schreiben.