Hrmpf...
Wie kann es passieren, dass ein Event seine Move Route mit der HALBEN Frequency ausführt?
Hrmpf...
Wie kann es passieren, dass ein Event seine Move Route mit der HALBEN Frequency ausführt?
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:CherryShare | Patches und Tools | Programmwunschthread | www.cherrytree.at | Cherry = CherryDT
Das wär deine Theorie dazu. Btw ist es im Endeffekt die GeschwindigkeitZitat von Cherry[b]1[/b]
gewesen, die sich geändert hatte.
Beweise deine Bug-Theorie.
Freirunde, da mich das hier kein Stück juckt.
--"Diese Divs sind magische Wesen."
HTML = schwarze Magie?
Richtig, mir ist ja auch nichts besseres eingefallen.
Und es ist NICHT die Geschwindigkeit.
mfG Cherry
EDIT: Hier mal ein Demoprojekt: http://cherry1.ch.funpic.de/bug.rar
Der Hund hat vor dem "Switch ON" ein "Face right", die Katze nicht. Ansonsten ist das Event kopiert. Einfach mal im Maker ankucken. Macht man nach dem Move Event (also vor dem Switch ON) ein Wait 0.0, funktioniert es normal.
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:CherryShare | Patches und Tools | Programmwunschthread | www.cherrytree.at | Cherry = CherryDT
Geändert von Cherry (09.05.2008 um 21:03 Uhr)
Ah, interessant.
Ich glaube den Fehler hatte ich auch mal vor einer Weile.
Ich denke aber es hat genauer gesagt eher damit zu tun, dass während einem Move-Event die Event-Seite gewechselt wird.
Genau das passiert nämlich auch bei dir: Das Move-Event startet, scheint aber anscheinend zumindest einen Frame anzudauern (wieso auch immer), weshalb der Seitenwechsel erzeugt durch den Switch danach noch während des Move-Events stattfindet.
Du kannst den gleichen Effekt erreichen, indem du das Event mit einen länger andauernden Move-Event bewegst (etwa Schritt nach rechts), danach eine kurze Wartezeit einfügst (kürzer als die Dauer des Move-Events) und dann den Switch aktivierst.
Was ich nicht wusste, ist, dass diese Frequenz änderung selbst nach ablaufen des Move-Events erhalten bleibt.
Und da ja wieder Freirunde ist, komme ich wieder mit einer Frage :P
Frage: Wie ist es möglich, eine gleichmäßig verteilte Zufallszahl von 0 bis X zu erzeugen (wobei X kleiner als 10 sein muss), ohne den X-Wert mit Forks abzufragen? Mit anderen Worten: Es darf nur einmal ein Random-Wert erzeugt werden und dieser muss irgendwie bearbeitet werden.
Diesmal ist es kein RPG-Maker Bug. Geht eher um Verständnis von Variablen und Variablen Operatoren. Ist also mal was praktisches :P
C ya
Lachsen
Ich denke da musst du schon etwas genauer beschreiben was du meinst. Inwiefern gleichmässig verteilt? Mir wird da der Bezug zwischen der Zufallszahl und der Forc-Abfrage nicht ganz klar.
Okay... dann, beschreibe ich es halt genauer:
- Gesucht ist eine Folge von Event-Befehlen, die keine Fork-Condition enthält
- Vor dem Ausführen dieser Folge, hat die Variable "X" einen Wert von 1 bis 9
- Nachdem die Folge durchgelaufen ist, soll in der Variable "Y" ein zufälliger Wert größer gleich 0 und kleiner gleich [Wert von X] gespeichert sein.
- Die wahrscheinlichkeit für jeden dieser Werte soll gleich groß sein (gleichverteilte Zufallsverteilung)
- Beispiel: Wenn X den Wert 5 hat, soll in Variable Y ein zufälliger Wert aus dem Bereich 0 bis 5 abgespeichert werden, wobei jeder Wert die Wahrscheinlichkeit 1/6 (in einem von 6 Fällen) hat.
- Und bevor jemand doof fragt: Es kann davon ausgegangen werden, dass die Standard-Zufallszahl Funktion des RPG-Makers eine gleichverteilte Zufallszahl (des jeweiligen Bereiches) simuliert.
So deutlich genug?
Set Var: X + 1
Set Var: Y = 100
Set Var: Y % X
Dürfte verständlich sein und passen.
--"Diese Divs sind magische Wesen."
HTML = schwarze Magie?
Aber nach diesem Code wird y ja nicht zufällig bestimmt, sondern wird durch x gegeben. Wenn x z.B. 1 ist, dann ist y immer 0.
Ich hab noch mal darüber nachgedacht. Funktioniert das so?
y = RND(0-9)
x += 1
y % x
Geändert von Kelven (10.05.2008 um 23:41 Uhr)
Euer Ansatz ist richtig, allerdings sind eure Zufallszahlen nicht gleichverteilt, für alle Werte von X.
Beispiel zu Kelven's Lösung:
Angenommen X=3
Dann berechnen wir Y%4, wobei Y eine Zahl von 0 bis 9 ist.
Hier die Wahrscheinlichkeiten für die einzelnen Zahlen:
0 = 0%4 = 4%4 = 8%4 (3/10)
1 = 1%4 = 5%4 = 9%4 (3/10)
2 = 2%4 = 6%4 (2/10)
3 = 3%4 = 7%4 (2/10)
Wie man sieht, sind die Zahlen 0 und 1 in diesem Fall wahrscheinlicher als die Zahlen 2 und 3, damit ist die Zufallszahl nicht gleichverteilt.
Aber ihr seid schon nah dran![]()
Geändert von Lachsen (11.05.2008 um 11:51 Uhr)