Move Event Befehl "Move Frequency Down"? Würde mich zwar wundern, aber egal XD
Druckbare Version
Move Event Befehl "Move Frequency Down"? Würde mich zwar wundern, aber egal XD
Das wär deine Theorie dazu. Btw ist es im Endeffekt die GeschwindigkeitZitat:
Zitat von Cherry[b]1[/b]
gewesen, die sich geändert hatte.
Beweise deine Bug-Theorie.
Freirunde, da mich das hier kein Stück juckt.
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.
Ah, interessant.Zitat:
Zitat von Cherry1
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.
geht mir auch so^^ Ich glaube ich weiß worauf du hinnaus willst vertsehe es rad irgendwie nich o.o
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.
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
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 :O
arg... Kein plan @___@
so?
y = rnd(0-9)
x += rnd(0-9)
y % x
Edit: ach verdammt >.<''
Ich geb's auf. ^^" Vermutlich ist die Lösung einfacher als ich denke, aber ich hab im Internet jetzt so viel über lineare Kongruenzgeneratoren usw. gelesen, dass mir die Lust vergangen ist. Wenn man mit dem Maker eine Zufallszahl im Interval [0,1[ erzeugen könnte wäre die Lösung einfach, da hab ich was gefunden.
set: x = rand(0, 9)
set: x + 1
set: y = 2520
set: y % x
Es muss gleichverteilt sein, weil 2520 durch alles von
1-10 geteilt werden kann, also die Restwerte gleichmäßig
auftreten.
Oder?
x ist doch der Grundwert und damit fest.
Ich bin jetzt verwirrt. Wenn X fest ist, dann denke man sich eben
den ersten Befehl weg. Der eigentliche Algorithmus fängt eh erst
ab Zeile 2 an.
Die Frage ist sehr verwirrend. Echt jetzt.
Ich dachte x wird random gesetzt?? o.o''
irgenwie komm ich nich mehr mit....
Lachsen hat doch weiter oben die Erklärung gepostet. Man wählt für x eine Zahl zwischen 1 und 9 und auf dieser Grundlage wird dann eine Zahl y zwischen 0 und x zufällig bestimmt. Die Schwierigkeit dabei ist ohne eine Forc die Menge der Zufallszahlen irgendwie einzuschränken und dass die Zufallsverteilung gleichmässig sein soll.
das hab ich ja verstanden^^
Ich hab bloß gedacht Nightgirls antwort wäre richtig o.o''
Ich hatte es so gedacht, das X = Zahl 1-9 * y(zahl 1-9)
Den wert dann durch x oder y^^
Meine Güte xD
Erstmal zu meiner Verteidigung:
Ich finde meine Beschreibung eigentlich eindeutig.
Man beachte das "VOR", d.h. es hat nichts mit der Event-Befehl-Folge zu tun, die man als Löung angeben soll.Zitat:
Vor dem Ausführen dieser Folge, hat die Variable "X" einen Wert von 1 bis 9
d.h. hier muss nichts zufällig ausgewählt werden. der Wert von X ist bereits gegeben. Sieht X einfach als Argument der Funktion (auch wenn es keine FUnktionen gibt, im RPG-Maker)
Hier steht doch mehr als eindeutig, dass Y den Zufalls-Wert enthalten soll.Zitat:
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.
Wieso kommt ihr jetzt auf die Idee, das X nen zufälligen Wert zugewiesen bekommt, in der Befehls-Folge?
Zur Auflösung:
Wenn man jetzt die Lösung von nightgirl1200 und Kelven zusammen fustioniert, bekommt man die richtige Lösung:
set: x + 1
set: y = rnd(1 - 2520)
set: y % x
So gesehen: Die Lösung von Kelven war korrekt, es musste nur der Bereich der zufälligen Zahl angepasst werden.
nightgirl1200 hat da genau richtig gedacht: Die obere Grenze der Zufallszahl muss durch alle Zahlen von 1 bis 10 teilbar sein.
(Beachtlich ist hierbei noch, das 2520 die kleinste Zahl ist, die das erfüllt. :A)
Eine Falle, wo man noch aufpassen muss:
Entweder lässt man den Bereich von 0 bis 2519 oder von 1 bis 2520 laufen.
Lässt man den Bereich von 0 bis 2520 laufen, ist das Ergebnis 0 immer (etwas) wahrscheinlicher.
So. Ich würde mal sagen, Kelven und nightgirl1200 haben gemeinsam gewonnen. Kann sich ja einer von beiden aussuchen, wer als nächstes die Frage stellt.
C ya
Lachsen
Ich weiß keine Fragen (erst recht nicht so kranke xD), deshalb sag ich
einfach mal: Go Kelven!