[RM2K3] Spiegelbild zum Spieler bewegt sich zu langsam
Hallo miteinander ^^.
Ich habe folgendes Problem: Ich möchte das sich ein Event ("Spiegelbild") genauso bewegt wie der Spieler es tut. Das habe ich bereits so umgesetzt bekommen. Jedoch bewegte sich das Event auch, wenn der Spieler gegen ein Hindernis läuft und sich somit gar nicht fortbewegt hat. Auch das habe ich geschafft, zu klären.
Jedoch habe ich nun das Problem, dass das Spiegelbild einen Bruchteil langsamer ist als meine Spielfigur. Und auch so viel langsamer, dass man es als Spieler mitbekommt.
Im folgenden zu meinem Code: Er besteht hauptsächlich aus 3 Common Events die auf Parallel Process laufen und sowohl die Bewegung, als auch Kollisionsabfrage steuern.
1.) Bewegung für den Spieler
2.) Bewegung für das Spiegelbild
3.) Rechner für die X - Position
Ich habe schon etliche Varianten mit Switches und Variablen als Kontrolleure ausprobiert und auch die Forks schon verschieden geschachtelt, aber das Spiegelbild hinkt immer noch etwas hinterher. Liegt vielleicht auch den Waits aber ich finde keine Lösung mehr, den Code noch weiter zu beschleunigen.
Vielleicht kann mir ja einer von euch helfen
Ich habe zwar gerade keinen RPG-Maker 2003 zur Hand um es zu testen, aber ich kann schon so sehen, dass deine Lösung Probleme hat.
Versuch es einmal wie folgt:
Benutze 2 Events mit Parallel Processing
Event 1:
^ Dieses Event speichert, in welche Richtung sich der Spieler gerade bewegt.
Event 2:
^ Dieses Event überprüft über den Vergleich der derzeitigen X-Koordinate mit der vorherigen X-Koordinate, ob sich der Spieler überhaupt bewegt hat. Falls der Spieler sich bewegt hat wird die Bewegung anhand der Variable BewegungsRichtung nachgespielt.
Alternativ kannst du dir die Variable BewegungsRichtung auch sparen und die Richtung einfach anhand der Differenz zwischen der neuen und alten Position berechnen.
Ohne jetzt genauer durchgeguckt zu haben:
Gibt das nicht alleine wegen des 0.1 waits Probleme? 0.1 bekommt das menschliche Auge ja durchaus problemlos mit, was wiederum dazu führen dürfte, dass das Spiegelbild sich leicht zeitversetzt bewegt? Wenn überhaupt würde ich bei sowas mit 0.0 arbeiten.
Spontaner Ansatz:
Sollte so eigentlich gehen (wenn ich nicht die Bewegungsrichtungen verwechselt habe...) und auf jeden Fall schneller sein als die 0.1-Varianten oder wenn mehrere PPs involviert sind. Ließe sich genau so mit einer zweiten Variable auch für die Y-Achse erweitern.
@ BDraw: Ich hatte es schon einmal geschafft, dass sich beide Events gleich schnell bewegen. Dann kam jedoch das Kollisionsproblem dazu. Und das funktionierte theoretisch mit 0.1 Wait ganz gut. Der 0.0 Wait hinter den Move Event des Spielers ist auch nur dazu da, damit die Variable schnell genug mit der neuen X - Koord. versehen werden kann. Seid ich jedoch die Kollisionssache mit drinne habe, buggt das so rum.
@ Cornix: Inwiefern hat meine Lösung denn Probleme? Ich dachte es wäre klüger, die einzelnen Berechnungen und Abläufe in einzelnen Common Events zu separieren. Zwecks Übersicht und das so natürlich manche Sachen gleichzeitig nebeneinander ablaufen können.
@ Beide und Allg.: Habe beide Sachen versucht versucht. Leider keine Verbesserung. Zu dem bewegen sich die Figuren teilweise auch bei nur einem minimalen Tastendruck mehr als ein Feld in die entsprechende Richtung, obwohl im Move Event nur eine Bewegung enthalten ist. Habs mit Waits als auch Proceed with Movement versucht, die Figuren laufen dennoch mehr als sie sollten. Vorzugsweise die Spielfigur.
Edit: Wenn ich alle Bewegungsabläufe, die Bestimmung der X - Koord. und auch die Eingabe separiere, funktionierts leider auch nicht
Ich hab's gerade mal getestet - bei mir hat es sich mit meinem Ansatz durchaus gleichschnell bewegt (und auch die korrekte Anzahl an Felder - sicher, dass du da mit Pos X und nicht Screen X gerechnet hast), allerdings hat es ab und an plötzlich ausgesetzt. Da ich allerdings ins Testmenü mit den Variablen komme, konnte ich nicht überprüfen, wann bzw. wo genau der Fehler auftrat, sprich, ob es irgendwo am Wait liegt, das dann die Berechnung verfälscht, oder mein Windows noch nicht ganz auf der Höhe war. Letzteres ist allerdings bei sowas simplen eher unwahrscheinlich, auch wenn Bootcamp + Windows + Steam immer etwas braucht, um in die Gänge zu kommen. :/
Was ich aber gerade nicht ganz verstehe: Weswegen steuerst du denn auch den Spielercharakter manuell? Für mehr Kontrolle über die genaue Position oder wozu?
@BDraw: Ich bewege den Helden manuell, damit er sich beim Drücken von Pfeiltaste Oben nach Oben-Rechts und beim Drücken von Pfeiltaste Unten nach Unten-Links bewegt. Diese Aussetzer habe ich auch manchmal. Aber irgendwie kommen und gehen die, wie es ihnen gerade passt. Manchmal habe ich sie auch gar nicht.
Hast du vielleicht noch einen Tipp, wie ich die Kollision einbauen kann? Weil irgendwie hardert das ganze System da dran und mir will nicht so ganz einleuchten, wieso es das tut.
Wenn du nicht bereits anderweitig Verwendung für die Terrain-IDs hast wäre das eine Möglichkeit. Du markierst in der Database alle nicht-passierbaren Tiles mit einer Terrain-ID und kannst so auf Maps ganz einfach abfragen, ob ein Tile passierbar ist oder nicht. Die leider ziemlich unpraktischen Nachteile sind, dass das nicht bei Upper Layer-Tiles hilft und auch mit Events nicht klappt - das lässt sich aber umgehen, da man afair mit Store Event ID auch Felder abfragen kann, auf denen kein Event ist (ergäbe dann ID = 0). So kann man das nutzen um abzufragen, ob überhaupt ein Event vorhanden ist.
Etwas elegantere Methoden würde auf Pixelbewegungen aufbauen, aber das ist dann wiederum recht kompliziert, da du das genau mit der Bewegungsgeschwindigkeit timen müsstest. Da ist vor allem dieser Post sehr hilfreich.
Meine Theorie was die Aussetzer angeht wäre, dass die mit den Waits zusammenhängen. Dadurch, dass der 2k/3 recht grobe Einheiten benutzt, kann es passieren, dass der Spieler genau dann eine Taste drückt, wenn ein Wait den Code am Weiterarbeiten "hindert". Beispiel: Du fragst eine Taste ab und hast am Ende ein Wait von 0.1 damit alles flüssig läuft. Der Spieler drückt die Taste (alles super soweit), lässt los, und drückt sofort die nächste Taste. Das ist aber viel schneller als 0.1s, wodurch das Event noch beschäftigt ist und so den Tastendruck noch gar nicht wieder abfragt. Gerade wenn du Abfragen hast die stattfinden, während der Spieler weiter lustig Tasten drücken kann, kann das zu ganz merkwürdigen Hängern führen, da du ja nach außen hin nicht weißt, ob der Spieler gerade genau so eine "Lücke" erwischt. Deswegen auch meine Skepsis bei so langen Waits wenn es um Bewegungsabfragen geht.
Vielleicht mal ein anderer Ansatz, der im Prinzip das selbe Ergebnis hat, aber technisch einfacher zu bewerkstelligen sein sollte:
Das Spiegelbild soll ja fix in Beziehung zum Spieler sein (z.B. 5 Felder rechts von ihr).
Dann erstelle einen Charakter, der in der Mitte deine Figur hat, 5 Felder nach Links geht (da aber transparent ist) und 5 Felder nach rechts geht und da deine Spiegelfigur hat.
Dann wären deine Figur und das Spiegelbild quasi die selbe Figur, die Bewegungen würden hundertprozentig synchron laufen und du könntest nicht mehr feststecken oder sonstwie sich die Positionen der Figuren zueinander ändern.
Das einzige was du noch machen müsstest, wäre transparente Blöcke dahin zu stellen, wo deine Spielfigur nicht hin kann, weil das Spiegelbild sonst in die Wand laufen würde.
Sollte sich die Position der beiden Figuren zueinander später ändern oder das Spiegelbild verschwinden, kannst du ja einfach eine neue Grafik für deinen Helden einfügen (das sollte der 2k3 über Events machen können).
Eins verstehe ich nicht: Wenn Spielfigur und Spiegelbild sich gleichzeitig bewegen sollen, warum packst du dann das Ausführen der Bewegung nicht in einen einzigen CE? Wenn du nach dem Move-Befehl ein "Proceed with Movement" platzierst, dann sorgt nämlich der Maker dafür, dass beide Events sich gleichzeitig bewegen.
Eins verstehe ich nicht: Wenn Spielfigur und Spiegelbild sich gleichzeitig bewegen sollen, warum packst du dann das Ausführen der Bewegung nicht in einen einzigen CE? Wenn du nach dem Move-Befehl ein "Proceed with Movement" platzierst, dann sorgt nämlich der Maker dafür, dass beide Events sich gleichzeitig bewegen.
...
Ich denke das Problem ist doch, dass das Spiegelbild an Wänden hängen bleiben kann (Die Figur geht nach oben, bei der Spiegelfigur ist da aber eine Wand und dann bleibt sie quasi auf der Stelle stehen).
Und das sollte - soweit ich es verstanden habe - nicht passieren.
Der Abstand der Figuren soll immer gleich bleiben: Kann A sich nicht hoch bewegen, dann kann B es auch nicht, selbst wenn da bei B frei wäre und umgekehrt.
Wenn das nicht so wäre, wäre es ja recht simpel umzusetzen.
Oder übersehe ich da gerade was?
Bin mit den englischen Maker-Begriffen nicht so ganz vertraut ^^
Jetzt bin ich erst recht verwirrt. Wenn es sein kann, dass beim Spiegelbild ein Hindernis ist und bei der Spielfigur nicht, dann passt sein ganzer Code nicht, weil dieser Umstand nicht berücksichtigt wird.