Druckbare Version
Hallo miteinander!
Ich habe mal wieder ein kurze Frage, die ich stellen möchte bevor ich es tatsächlich ausprobiere und dann evtl. scheitere:
Wieviele Events kann man auf einer Map im Rpg2k3 setzen? Soviele wie es Platz gibt? Oder ist da eine Obergrenze?
Alle Events wären ohne Charset und Auf Hero-Touch gestellt. Habe mal irgendwo gelsen, dass bei 9999 das Ende erreicht ist, stimmt das?
lg Räbbit!
Ja.Zitat:
Habe mal irgendwo gelsen, dass bei 9999 das Ende erreicht ist, stimmt das?
Anders gesagt: Eins weniger als auf 100x100 Feldern Platz finden können.
Aber wozu brauchst du so extrem viele Events mit Touch?
Danke für die schnelle Antwort MM.
Ein kleiner Dämpfer. Allerdings stellt sich nun eine zusätzliche Frage, gibt es da Einbußen bei der Performance bei 9999 Events die auf Touch reagieren?
Wofür ich das benötige wird nicht verraten, das ist ein kleines Geheimprojekt an dem ich gerade arbeite, das erfahrt Ihr erst, wenn es fertig ist.
Da hatte ich mir auch schon sorgen gemacht... aber ich denke es funzt! Die sind ja nich aktiv solang man sie nich berührt Oo
Ich hab nur den Verdacht, dass du dir damit etwas verüberkomplizierst, das sich
auch mit einer oder ein paar parallel laufenden Koordinatenfragen lösen lässt.
Gut, dann eine kleine Erklärung:
Bei jedem Schritt wird je nach Terrain ein Zufallsevent gestartet, die wiederum andere Zufallsevents auslösen, wenn die richtigen Bedingungen erfolgen.
Ich hatte geplant für jedes Terrain Zufalls-Starter auf die Map, also jeden einzelnen Sektor zu legen. (Auf Wälder,Berge usw)
Wie sähe da eine elegantere Lösung aus? Koordinaten-Abfrage beherrsche ich, aber ich müsste dennoch erstmal genau bestimmen, welche genauen Koordinaten zu welchem Terrainfeld gehören. Bei 2-3 Maps von 100x100 ist das denke ich ein noch größerer Aufwand als die (6 unterschiedlichen) Terrain-Events per Hand zu verteilen. Oder kann man irgendwie das Terrain abfragen über das man sich gerade bewegt? In der Datenbank kann man leider bei Terrain keine Switches aktivieren, was die ganze Sache natürlich erheblich vereinfachen würde.
lg Räbbit
Terrain von einer Position einfangen kannst du, Seite 2, linke Spalte, viertletzter Befehl.
Du musst dann den restlichen Prozess wissen lassen, dass du dich grade bewegt hast,
damit der Kram auch nur genau dann neu gemacht wird.
Und wie stelle ich es genau an, dass das Event weiß das der Held sich bewegt hat, oh großer magischer Pfuhl des Wissens?
Da scheint bei mir noch eine Lücke zu sein. Über Hero-x-Coordinate + / - ? Oder doch anders?
Ich würde die X/Y Koordinaten zwischenspeichern lassen, in zwei weitere Variablen (z.B. Check X, Check Y).
Dann vergleichst du die aktuellen Koordinaten mit den zwischengespeicherten Variablen, mithilfe der Fork Condition.
Sollten die X ODER die Y Koordinaten NICHT GLEICH sein, muss der Held sich ja bewegt haben.
Das ganze dann als Vorraussetzung nehmen, um den Zufallswert generieren zu lassen.
Ich würde da vielleicht ein 0.0 wait dazwischen lassen (vielleicht auch mehr)
Edit:
Nochmal zur eigentlichen Frage "Wieviele Events pro Map?"
Also meiner Erfahrung nach ist bei maximal 100 Events ist Schluss - performance-technisch gesehen.
Egal, ob die Events genutzt werden oder durch einen Switch deaktiviert sind, spielt keine Rolle.
Die werden ja trotzdem gelesen, einfach nur weil sie auf der Map sind.
Bei einer Karte von 100*100 sollte man sowieso SEHR wenig Events nutzen.
Vor allem wenn's um Pictures geht, oder ziemlich komplexe Skripte.
Ja, genau so. Nur bei "wait" kannst du ruhig etwas mehr Zeit lassen, dann muss das Programm nicht beinahe ständig rechnen, sondern macht das leistungsschonender in Etappen.
Bei normaler Geschwindigkeit benötigt der Held für einen Schritt ~ 0,13 Sekunden. In "waits" sind das: 0,1s + 2x 0,0s (oder 8x 0,0s).
In der üblichen Horrospielschleichgeschwindigkeit ("2x slower") dauert ein Schritt ~ 0,27s. In waits: 0,2s + 4x 0,0s (oder 16x 0,0s)
Und ganz schrill ist man, wenn man sich für diesen Kram eine Exceltabelle mit den entsprechenden Formeln anlegt und künftig rechnen lässt.
Nachtrag:
Im bekannten und langerprobten Schrittgeräusche-Script hast du das übrigens alles fertig frei Haus. Dann musst du nicht mal selbst basteln und kannst die gesparte Zeit für anderes nutzen.
Danke für Eure Antworten!
Ich habe mal alles getestet, bin aber auf ein Problem gestoßen, dazu eine kleine Erläuterung des Event-Zwecks in seiner Ursprungsform als "HeroTouch":
Terrain/Sektor wird betreten=
(+1 zum Zeitzähler vom Tag&Nacht System)
(Hero Speed verringern/erhöhen/gleibleibend)
(Zufallswurf)
Etwas passiert / nichts passiert
Das Problem besteht jetzt in der PP Variante darin, das die Events nicht über einen Touch, sondern über eine Terrain-ID Variablen-Abfrage aktiviert werden. Also das Event wird auch aktiviert, wenn man einfach still dasteht. Ich finde nun irgendwie keine Möglichkeit, das Event nach einer Aktivierung stoppen zu lassen. Habe schon probiert, nach einer AKtivierung die Terrain-ID auf ein Leerlauf-Terrain setzen zu lassen. (Welches nichts aktiviert)
Klappt alles nicht! :P
Wie schaffe ich es also, dass sich die Terrain / Heldenbewegungsabfrage nicht immer und immer wieder looped?
Danke im Vorraus, Räbbit!
Ich würde es mit einem Tab/Schalter versuchen oder noch besser mit einer Variabel um so das Event kurzzeitig oder auch dauerhaft so wie du es benötigst auszuschalten...Zitat:
Wie schaffe ich es also, dass sich die Terrain / Heldenbewegungsabfrage nicht immer und immer wieder looped?
Lg
Multi-Master1988
@Multi-Master1988: Nein, das funktioniert in dem Fall nicht, da der Zweck des Events ja gerade ist zu verhindern, dass ich Tausende Events setzen muss. Würde ich jetzt aber das PP mit der Abfrage deaktivieren, müsste ich es auf irgendeinen Weg wieder aktivieren. Also eine Aktivierung des PPs wenn der Held weiterreist. Tja und dann bräuchte ich wieder das Hero-touch-Event, was ich ja eigentlich durch den PP ersetzen wollte.
Ich denke ich bleibe nun dabei, auf jeden Sektor ein Her-Touch-Event zu legen, das funktioniert wenigstens einwandfrei.
(Es gab noch einige andere kleine Fehler mit der PP Version)
Also wenn jetzt nicht jemand eine perfekte Lösung für ein Reiseskript hat, gehe ich den uneleganteren Weg.
mfG Räbbit
Mal aus dem Stehgreif.
(Entfernt, da jetzt unten das tatsächliche Maker-Event ist~)
Wie gesagt, nicht getestet. Aber da die Terrain-ID nur abgefragt wird, wenn der Held sich bewegt hat, solltest du nichteinmal einen Switch brauchen.
Was du jetzt genau machst, wenn das Terrain den und den Wert hat ist dabei egal.
EDIT:
So klappt's im Maker.
Allerdings wird nicht berücksichtigt, ob du das Terrain verlässt, sprich, wenn du einen Schritt von Terrain 1 zu Terrain 1 machst, legt das Event trotzdem los.
Wenn du das unterbinden willst sähe es so aus:
Beides gerade getestet, die Message-Befehle waren der Dummy sozusagen. Wenn das auch nicht das richtige ist, musst du mir dein Problem noch mal erklären. xD
Ansonsten: Warum wolltest du im Zweifelsfall lieber unzählige Events machen, als EINES, was den PP auslöst? oO
Fast hätte ich geschrieben: Du bist ein Gott, BDraw!!!! Genau das habe ich gesucht!
Denn es funktioniert bereits sehr gut, habe den Code 1 zu 1 übernommen...
Aber!
Aus irgendeinem Grund, muss man erst 2-5 Sektoren ablaufen, bis die Terrain-ID verändert wird, wenn man bspw. zwischen Grasland und Wald wechselt. Das merke ich vor allem daran, das sich die Heldengeschwindigkeit verändert (und natürlich auch an der Variable) Komme ich also aus dem Wald heraus und stelle ich den Helden auf Grasland, wird die ID nicht gewechselt. Man muss erst ein paar Felder ablaufen bevor das Event die ID ändert.
Kann sich das jemand erklären? Der Code sieht meines wissens nach richtig aus und eigentlich müsste das Event die ID doch sofort erkennen, wenn man ein Feld betritt!?
Wäre auch in diesem Fall über eine hilfreiche Antwort sehr dankbar!
Edit: Wegen Ansonsten: Weil das schon einwandfrei funktioniert und keine Bugs am Event genagt haben. Die neue Version ist zwar elegant und erspart einen Haufen Arbeit, ist aber immer noch von Bugs, wie der hinterher hinkenden Terrain-ID Speicherung betroffen :/
o_ô
Das ist allerdings interessant. Magst du mir mal deinen Code oder das Projekt (bzw einen Auszug) schicken? Also, inklusive der Tempoveränderung und dem Zeugs? Denn bei mir lief alles glatt... Auf Anhieb könnte ich mir gerade nur vorstellen, dass da was bei den Terraineinstellungen hakt oder ein anderes Event da mit reinlangt. Oder ich hab nen blöden Fehler gemacht, den ich gerade nicht finde.
Denn das wurmt mich jetzt doch ein kleines bisschen. xDD
Der Terrain-Heldenbewegungscode, ist exakt der gleiche wie von dir angegeben:
Edit: Von dem 2. Event, gibt es pro Terrain eines (mit 2 Seiten). Vllt ist da ja der Wurm vergraben. Aber wenn diese Events als Hero-Touch gelegt werden, funktionieren sie einwandfrei oO =verwirrt.
EDIT2: den 2. Code nochmal neu in den Spoiler reinkopiert, mit Erklärung versehen
Uff... auf Anhieb find' ich da nichts, allerdings hab ich auch keine Ahnung, was da was bewirkt bzw. bewirken soll.
Und die Variable mit der Terrain-ID ändert sich tatsächlich nicht, sprich, wenn du im Testgame in dieses Switch/Variablen-Menü gehst, ist die unverändert, auch wenn du auf nem neuen Terrain bist?
Ansonsten würde ich raten, dass dein zweites Event da irgendwas extrem verzögert. Ist etwas schwierig da jetzt bei dir durchzublicken, zumal die Formatierung kaputt ist. Wähl beim EventExporter mal dden Style für vBulletin mit hellem Hintergrund aus, dann wird's hier richtig angezeigt.
Aber wenn man die auf Touch stellt funktionieren sie doch prima!?
Es liegt also an der Verbindung mit dem PP-Terrain-ID-Event. Irgendwie wird die Terrain-ID erst nach mehreren Schritten ausgelöst, aber das ergibt bei diesem Aufbau doch eigentlich gar keinen Sinn...
Zudem ist mir aufgefallen, dass wenn man ohne zu stoppen von der Ebene durch ein Waldstück/Gebirge "durchrennt" die ID-überhaupt gar nicht erst verändert wird. Sehr merkwürdig.
Okay, 1. Sache die ich gefunden habe:
Du prüfst die falschen Koordinaten. Die Terrain-ID wird aus den 2. X- und Y-Koordinaten bezogen, da die ja aktueller sind. Aber das hilft gerade trotzdem nicht, stelle ich fest. xD
Edit:
Ich könnte dich erwürgen... xD
Du hast nen Fehler beim einbauen meines Codes gemacht. So, wie du es gescriptet hast, wird der y-Unterschied niemals abgefragt werden. Du hast das nicht verschachtelt, sondern einfach untereinander gebaut. Bewegt der Held sich nun bei dir nach oben oder unten, wird immer noch zuerst die X-Koordinate verglichen - die ist aber identisch, und bei dir springt der Maker nun wieder zum Anfang.
EDIT: Hier stand ganz viel murks! ^^
BDraw, jetzt aber: Du bist ein Gott!!! :D
Du hast mir arthritische Finger erspart! Man ey, das mit der Fork hab ich in meiner Hektik einfach übersehen :/
Es funktioniert jetzt wunderbar! Und für alle die den Code auch nochmal in seiner Reinform brauchen hier im Spoiler verpackt:
Ne, ich hab's mal eben getestet. Die Terrain-ID gilt für alle Elemente vom Autotile. Sonst würde es auch wenig sinnvoll sein, dem überhaupt eine ID zuzuweisen.
Irgendwie bin ich beim Script skeptisch. Du fragst die Heldenposition ab und nach einem Wait 0,0 nochmal. Eigentlich müsstest du die Heldenposition aber nur nach jeder Bewegung abfragen. Vielleicht wäre es so besser:
Pseudo-Code:
Problematisch könnte nur sein, dass die Tastenabfrage vor der Bewegung stattfindet und man deswegen ein Wait bräuchte, das an die Bewegungsgeschwindigkeit angepasst ist.Code:x1 = Held-X
y1 = Held-Y
Key Input Processing (nur Cursortasten)
x2 = Held-X
y2 = Held-Y
if x1 = x2
if y1 = y2
Reaktion
Jump: Label 1
end
end
Label 1
@Kelven: Also für meine Zwecke funktioniert es zumindest Bestens, es ist ja eigentlich auch eher ein Weltkarten-Reiseskript, um verschiedenste Events zu aktivieren, das Terrain abzufragen und anzufragen, ob der Held sich gerade gerührt hat oder nicht.
Ich Danke Euch allen für Eure Antworten, Ihr habt mir alle seeeehr viel Arbeit erspart :]
@Kelven:
Worauf du mit dem Autotile hinauswillst, ist mir noch nicht ganz klar...
Aber mit der Abfrage, das stimmt schon, 100% vertraue ich dem 0,0-Wait auch nicht. Aber solange der Held nicht so schnell ist, dass er kürzer als 0,0 braucht um von Feld zu Feld zu kommen, dürfte da eigtl. nichts passieren. Einzig bei der Performance bin ich skeptisch, andererseits dürfte es relativ egal sein, ob man ne Taste abfragt oder Koordinaten vergleicht. Weswegen ich das mit der Tastenabfrage ungerne mache, ist, dass man das Script bei Sequenzen oder allgemein Bewegungen, die per Move Event getätigt werden, dann vergessen kann.
Danke für den Tipp aber mit der Abfrage, das ist echt einfacher. ^^
@BDraw: Das stand in meinem editierten Text, ich hatte ein paar wilde Verschwörungstheorien zur Fehlerquelle geäußert ^^
Und zur Performance, das Event ist das einzige PP auf der Map in sofern mache ich mir da jetzt keine großen Sorgen.
@BDraw
Mit der Tastenabfrage müsste die Performance besser sein (falls es mit der überhaupt Probleme gibt), weil der Prozess ja immer auf die Tastenabfrage wartet und wenn der Spieler gerade nichts drückt, passiert auch nichts. Nur bei gedrückter Taste könnte es problematisch werden, vermutlich bräuchte man noch ein Wait hinter der Abfrage. Ich weiß aber auch gar nicht, ob eine gedrückte Taste überhaupt Key Input Processing mehrmals auslöst.
Edit:
Nur so aus wissenschaftlicher Neugier hab ich überlegt, ob man die Methode noch vereinfachen könnte. Ich hab das nicht ausgetestet, aber müsste es so nicht auch gehen? Falls ich nicht missverstanden habe was die alte Methode machen soll. Man würde dann sogar eine Variable sparen. Allerdings müsste man die Variable für das alte Terrain wohl vorher initialisieren.
Code:x1 = Held-X
y1 = Held-Y
t_neu = Set Terrain ID (x1, y1)
if t_neu != t_alt
Reaktion abhängig vom Terrain
t_alt = t_neu
end
Wait 0,1 (falls die Geschwindigkeit nie unter "Normal" fällt, sollte das kein Problem sein)
@ Kelven:
Prinzipiell würde das auf jeden Fall funktionieren, allerdings ging es bei dem Skript ja gerade darum (oder unter anderem), dass sich die Heldengeschwindigkeit je nach Terrain verändert. Lässt man diesen Punkt aber außer acht, ist es eine gute,schlankere Version des Codes!