[RM2K3] Brauche Hilfe: Sprung-Script a la Golden Sun

Hey Leute!

Sicher kennen viele das berühmte GBA-Spiel Golden Sun.
Für mein eigenes RPG würde ich gerne ein Sprung-Script im gleichen Stil im RM2K3 scripten.

Kurze Erläuterung:
Befindet sich der Held an einer Stelle die er überspringen kann (Loch, schmales Flüsschen etc.), und der Spieler drückt über einen kurzen Zeitraum in die jeweilige Richtung, macht der Held einen kurzen Satz um darüber hinweg zu springen.

Klingt erstmal nicht soo wahnsinnig spektakulär, aber ich befürchte dass das nicht ganz so einfach ist wie es sich zunächst anhört..

"Haste schon mal rumprobiert oder willste nur Skripts vorgekaut kriegen?"
Neeeeiiin.. Ich will natürlich lernen. Ich muss ja verstehen was ich da tue :D
Folgende Gedanken hab ich mir schon dazu gemacht und das sind die Major Problems:

- Wie überprüfe ich ob der Held an einer Stelle steht, die er überspringen kann?
-- per Map-Event, das ein Common Event aufruft
-- Terrain-ID für solche Felder anlegen und abfragen?
(Habt ihr noch andere Ideen oder Anstöße?)

- Wie überprüfe ich die Dauer des Tastendrucks? (Zum Beispiel eine Sekunde lang die Richtungstaste gedrückt halten)
-- diese Abfrage bereitet mir ehrlich gesagt ziemlich Probleme..

Ich glaube ich müsste nur wissen, wie ich die Abfrage der Tasten-Druck-Dauer gestalten kann, das würde mir beim Scripten schon krass voll viel weiterhelfen. :D
Ansonsten bin ich natürlich für jede Meinung, jeden Anstoß und Gedanken offen.
Ich benutze Ineluki's Key-Patch NICHT - versuche so viel wie möglich aus den bestehenden Möglichkeiten rauszuholen. :)
Kein pixelgenaues Movement.

"Dude, wofür der Aufriss?"
Wenn es so funktioniert wie ich es mir vorstelle, dann könnte man damit ähnlich wie in der Spielvorlage Sprung-Rästel bauen, die Maps weitläufiger gestalten, besondere Items und Belohnungen besser "verstecken" und die Maps dynamischer gestalten.
Ich bin kein Technik-God like Lachsen (krasser Typ.. einfach ein krasser Typ..) aber ich behaupte dass mir auch komplizierte Abfragen und tiefergehende Verwendung von Variablen und Switches mit genügend Zeit keine Probleme bereiten. Ich bin gewillt immer mehr zu lernen
und offen für jede Art von Hilfe und Kritik.
Ich hoffe nicht zu viel Text.. Ich freue mich auf eure Gedanken, lasst alles raus! :D

Beste Grüße! Exas

Ich verstehe nich warum du das so komplex machen willst? o.O
Mach doch einfach ein Event an der Stelle wo gesprungen werden soll, das bei OnTouch abfragt, in welche Richtung der Held guckt, und wenn der Held in Sprung Richtung
schaut machste nen Move event für den Jump ...

Bitte um genauere Erläuterung warum du das so künstlich aufbauschen willst, danke ^^

Danke erstmal für die Antwort, hatte schon Angst dass das Thema schon x-mal durchgekaut wurde und keiner mehr reagiert :D
Ich möchte vermeiden, dass just in dem Moment gesprungen wird, sobald der Held sich auf dem Event befindet. Deswegen möchte ich die Länge des Tastendrucks messen.
Oder denke ich jetzt falsch und dein Vorschlag lässt dieses Problem gar nicht erst auftreten?

Nachtrag:
Ich teste es mal fix durch

Ohne ein paar Zusätze, von denen aber die wichtigsten in RPG2003 nicht funktionieren, könnte das
verdammt kompliziert werden.

Überall Events an den Stellen anzubringen, die das abfragen, sorgt schonmal für eine mächtige
Unordnung beim Aufbau, aber kümmern wir uns erstmal um was anderes, das dir im Moment
wichtiger ist:

Zitat:

---

- Wie überprüfe ich die Dauer des Tastendrucks? (Zum Beispiel eine Sekunde lang die Richtungstaste gedrückt halten)
-- diese Abfrage bereitet mir ehrlich gesagt ziemlich Probleme..

---

Folgenden Code hab ich nicht getestet, es sollte allerdings gehen.

Code:

---

<>Set Variable: [0003] = 0 (※ Dauer-Counter-Reset)
<>Get Key Input: Down, Left, Right, Up | Store: v[0001] | NoWait (※ Richtung abfangen)
<>If v[0001] > 0 (※ Wird denn überhaupt gedrückt?)
 <>Loop Start
  <>Get Key Input: Down, Left, Right, Up | Store: v[0002] | NoWait (※ Weiterspeichern in anderer Var)
  <>If v[0002] == v[0001] (※ Richtung mit der vom Anfang vergleichen)
  <>Set Variable: [0003] += 1 (※ Dauer-Counter hoch)
  <>
  : Else
  <>Break Loop (※ Druckausübung wurde unterbrochen)
  <>
  : EndIf
  <>If v[0003] == 30 (※ Entspricht einer halben Sekunde)
  <>※ Sprung hier ausführen, also wahrscheinlich sowas wie <>Move: Player | ThroughOn, JumpStart, Forward, Forward, JumpStop, ThroughOff
  <>Break Loop (※ Fertig)
  <>
  : EndIf
  <>Wait: 0.0s
  <>
 : Loop End
 <>
: EndIf
<>

---

Ungefähr so funktioniert eine Abfrage für Drücken mit fester Wunschdauer, bis etwas passiert.
Das muss jetzt "nur noch" irgendwo passend reinverpackt werden.

Es gibt da allerdings eine kleine ärgerliche Sache bei, denn die Tastenabfrage vom Makerchen ist
wirklich sehr unzuverlässig, heißt es kann vorkommen, dass sie mal in einem Frame kurz aussetzen
kann und dann den Spielern den Dauer-Counter für das Gedrückthalten zurücksetzt. Damit muss man
leider rechnen. Falls du 2003-1.10 von diesem Jahr verwendest, könnte das aber auch bereits besser
laufen, so ganz im Bilde bin ich darüber noch nicht, ob sich das da verbessert hatte oder nicht.

Zitat:

---

Ich benutze Ineluki's Key-Patch NICHT

---

Gut so, das Ding ist ja auch ein echter Krampf in der Verwendung und längst überaltet.

Ihr habt mir bestens weitergeholfen!
Ich hab mir beide Posts zu Herzen genommen und -erstmal- ein Map-Event erstellt das wie folgt aussieht

--- EVENT ---
Type: Map event
Name: EV0026
Coordinates: (25, 9)
Number of Pages: 1

-- PAGE 1 --
Start conditions:
<None>
Sprite: <Tileset> #0
Facing direction: Down
Animation frame: Center
Transparent: No
Trigger condition: Collision with hero
Event level: Same level as hero
Forbid event overlap: No
Animation type: Non-continuous
Movement type: Stationary
Movement frequency: 3
Movement speed: 3
- SCRIPT -

*Comment: Tastendruck Dauer überprüfen
<> Change Variable: [21] = 0
<> Key Input Processing: Var. [22], Keys: Down, Left, Right, Up
<> Fork Condition: If Variable [22] > 0 then ...
<> Loop
<> Key Input Processing: Var. [23], Keys: Down, Left, Right, Up
<> Fork Condition: If Variable [22] == V[23] then ...
<> Change Variable: [21] += 1
<> Wait: 0,1 sec.
<>
: Else ...
<> Break Loop
<>
: End of fork

*Comment: Hier die Taste abfragen die gedrückt wurde, um Sprunrichtung zu ermitteln.
<> Fork Condition: If Variable [21] == 3 then ...
<> Fork Condition: If Variable [23] == 1 then ...
<> Change Switch: [6] = OFF
<> Move Event:
*Move-Befehle entfernt weil's ein bisschen lang geworden wäre..
<> Change Switch: [6] = ON
<> Wait: 0,2 sec.
<>
: Else ...
<> Fork Condition: If Variable [23] == 2 then ...
<> Change Switch: [6] = OFF
<> Move Event:
<> Change Switch: [6] = ON
<> Wait: 0,2 sec.
<>
: Else ...
<> Fork Condition: If Variable [23] == 3 then ...
<> Change Switch: [6] = OFF
<> Move Event:
<> Change Switch: [6] = ON
<> Wait: 0,2 sec.
<>
: Else ...
<> Fork Condition: If Variable [23] == 4 then ...
<> Change Switch: [6] = OFF
<> Move Event:
<> Change Switch: [6] = ON
<> Wait: 0,2 sec.
<>
: End of fork
<>
: End of fork
<>
: End of fork
<>
: End of fork
<> Break Loop
<>
: End of fork
<>
: End of loop
<>
: End of fork
<>

Dieses Event platziere ich jetzt überall dort, wo der Held drüber springen kann. Ich denke ich werde das Ganze aber noch zu einem CE machen.
MagicMaker's Skript zum Zählen des Tastendrucks funktioniert perfekt, und Linksawakening's Idee hat nen wichtigen Anstoß geliefert. Tausend Dank Leute! :)

Möchtet ihr bei Zeiten einen kleinen Einblick in das Projekt haben, zur Veranschaulichung? Es enthält außerdem noch ein Lauf-Script.

Also ich habe etwas Ähnliches für Altered Royalty vor, allerdings soll das erst mit einem Item möglich sein. Da soll das zwar auf Tastendruck der Shifttaste geschehen (die für die Items ist), wenn das Item ausgerüstet ist, aber im Prinzip muss ich mir auch was überlegen.

An jede Stelle dann ein Event zu platzieren, wo man umherspringen kann, würde den Rahmen sprengen, gerade bei meinem Projekt, da man auch (mit dem Item) dann wie bei Zelda (2D Teile) von nicht allzu hohen Bergen runterspringen kann.

Bei mir wird es aber Parallax Mapping geben und Terrain IDs als Ebenen, einfach damit ich eine künstliche 3D Kollisionsberechnung machen kann, aber dein Skript dürfte nicht allzu kompliziert sein.

Pass auf, ganz einfach: Du bestimmt per Terrain ID, ob du an einer Kante stehst. Per Terrain ID wird bestimmt, ob das eine nach Norden, Süden, Westen, Osten, NO, NW, SW oder SO gerichtete Kante ist. Bei den Diagonalen Richtungen, kann man z.B nach oben und unten springen. Je nach Chispet hast du auch eine Platform die 1x1 groß ist, in dem Fall kann man theoretisch in jede Richtung springen. Dann bestimmst du, ob zwei Felder weiter in der Richtung eine Kante liegt, auf die man draufspringen kann. Ich gehe mal davon aus, dass man keine Abgründe, die breiter als ein Feld sind, überspringen kann :) Ist das so, leitest du die Abfrage mit dem Tastendruck ein :)

Zitat:

---

Zitat von Drakee

Also ich habe etwas Ähnliches für Altered Royalty vor, allerdings soll das erst mit einem Item möglich sein. Da soll das zwar auf Tastendruck der Shifttaste geschehen (die für die Items ist), wenn das Item ausgerüstet ist, aber im Prinzip muss ich mir auch was überlegen.

An jede Stelle dann ein Event zu platzieren, wo man umherspringen kann, würde den Rahmen sprengen, gerade bei meinem Projekt, da man auch (mit dem Item) dann wie bei Zelda (2D Teile) von nicht allzu hohen Bergen runterspringen kann.

Bei mir wird es aber Parallax Mapping geben und Terrain IDs als Ebenen, einfach damit ich eine künstliche 3D Kollisionsberechnung machen kann, aber dein Skript dürfte nicht allzu kompliziert sein.

Pass auf, ganz einfach: Du bestimmt per Terrain ID, ob du an einer Kante stehst. Per Terrain ID wird bestimmt, ob das eine nach Norden, Süden, Westen, Osten, NO, NW, SW oder SO gerichtete Kante ist. Bei den Diagonalen Richtungen, kann man z.B nach oben und unten springen. Je nach Chispet hast du auch eine Platform die 1x1 groß ist, in dem Fall kann man theoretisch in jede Richtung springen. Dann bestimmst du, ob zwei Felder weiter in der Richtung eine Kante liegt, auf die man draufspringen kann. Ich gehe mal davon aus, dass man keine Abgründe, die breiter als ein Feld sind, überspringen kann :) Ist das so, leitest du die Abfrage mit dem Tastendruck ein :)

---

Du kommst genau zum richtigen Zeitpunkt Drakee :)
Mir ist auch aufgefallen, dass ich mit der Map-Event Methode viel zu viel Chaos auf der Map auslöse..
Das Prinzip hab ich soweit verstanden - nur weiß ich leider nicht wie ich bestimmen kann ob zwei Felder ein weiter "bespringbares" Feld ist. Kurzer Tipp?
Könnte an der Uhrzeit liegen aber ich komm gerade nicht klar :D
Danke im Voraus!

PS: Ich hatte ebenfalls angedacht, den Helden auf kleine Erhöhungen springen zu lassen bzw. von dort runter. Muss mir noch überlegen wie ich das umsetze. Wahrscheinlich auch über Terrain ID's, dann nur mit einem anderen Move-Set?

Zitat:

---

Zitat von Exas

Das Prinzip hab ich soweit verstanden - nur weiß ich leider nicht wie ich bestimmen kann ob zwei Felder ein weiter "bespringbares" Feld ist. Kurzer Tipp?

---

In etwa so (Pseudocode):
Speichere die Position des Actors in Variablen.
Speichere die TerrainID anhand der Position des Helden in eine weitere Variable.

Wenn die TerrainID der "Kante Oben" entspricht & der Actor nach oben schaut
Rechne Actor Y Pos - 2 (+ für unten)
Überprüfe nun, ob die Terrain ID einer Kante entspricht, auf die man springen kann, indem die Terrain ID anhand der Position des Actors erneut gesetzt wird.
Wird die Pfeiltaste oben eine Zeit lang gedrückt, so lasse den Helden zwei Felder nach oben springen, sofern die vorherige Bedingung erfüllt.

Analog für Unten.

Wenn die TerrainID der "Kante Rechts" entspricht & der Actor nach rechts schaut
Rechne Actor X Pos + 2 (- für links)
Überprüfe nun, ob die Terrain ID einer Kante entspricht, auf die man springen kann, indem die Terrain ID anhand der Position des Actors erneut gesetzt wird.
Wird die Pfeiltaste oben eine Zeit lang gedrückt, so lasse den Helden zwei Felder nach links springen, sofern die vorherige Bedingung erfüllt.

Analog für Links

Bei einer Kante mit zwei oder bei einer Platform mit vier möglichen Richtungen setzt du innerhalb der Bedingung für die Terrain ID noch die entprechenden einzelnen Bedingungen für die FaceDir des Helden.

Zitat:

---

Zitat von Exas

PS: Ich hatte ebenfalls angedacht, den Helden auf kleine Erhöhungen springen zu lassen bzw. von dort runter. Muss mir noch überlegen wie ich das umsetze. Wahrscheinlich auch über Terrain ID's, dann nur mit einem anderen Move-Set?

---

Im Prinzip ähnlich. Nur muss der Maker wissen, ob du vor einer Wand stehst. Dann musst du halt eine Abfrage machen, bei der die Terrain ID des Feldes vor dem Helden bestimmt wird.
Also noch eine Terrain ID für "Wand" bestimmen. Dann müsstest du nur abfragen, wenn du vor einer Wand stehst, ob ein Feld darüber direkt ein begehbares Feld ist, das musst du leider auch per Terrain ID bestimmen.
Also nicht passierbare Tiles sollte man dann noch per Terrain ID extra bestimmen :D


Ich kann mich ja selbst mal an das Problem heransetzen, dürfte nicht so extrem lange dauern.

Zitat:

---

Zitat von Drakee

In etwa so (Pseudocode):
Speichere die Position des Actors in Variablen.
Speichere die TerrainID anhand der Position des Helden in eine weitere Variable.

Wenn die TerrainID der "Kante Oben" entspricht & der Actor nach oben schaut
Rechne Actor Y Pos - 2 (+ für unten)
Überprüfe nun, ob die Terrain ID einer Kante entspricht, auf die man springen kann, indem die Terrain ID anhand der Position des Actors erneut gesetzt wird.
Wird die Pfeiltaste oben eine Zeit lang gedrückt, so lasse den Helden zwei Felder nach oben springen, sofern die vorherige Bedingung erfüllt.

Analog für Unten.

Wenn die TerrainID der "Kante Rechts" entspricht & der Actor nach rechts schaut
Rechne Actor X Pos + 2 (- für links)
Überprüfe nun, ob die Terrain ID einer Kante entspricht, auf die man springen kann, indem die Terrain ID anhand der Position des Actors erneut gesetzt wird.
Wird die Pfeiltaste oben eine Zeit lang gedrückt, so lasse den Helden zwei Felder nach links springen, sofern die vorherige Bedingung erfüllt.

Analog für Links

Bei einer Kante mit zwei oder bei einer Platform mit vier möglichen Richtungen setzt du innerhalb der Bedingung für die Terrain ID noch die entprechenden einzelnen Bedingungen für die FaceDir des Helden.



Im Prinzip ähnlich. Nur muss der Maker wissen, ob du vor einer Wand stehst. Dann musst du halt eine Abfrage machen, bei der die Terrain ID des Feldes vor dem Helden bestimmt wird.
Also noch eine Terrain ID für "Wand" bestimmen. Dann müsstest du nur abfragen, wenn du vor einer Wand stehst, ob ein Feld darüber direkt ein begehbares Feld ist, das musst du leider auch per Terrain ID bestimmen.
Also nicht passierbare Tiles sollte man dann noch per Terrain ID extra bestimmen :D


Ich kann mich ja selbst mal an das Problem heransetzen, dürfte nicht so extrem lange dauern.

---

Ahhhh Erleuchtung at its best! :) Danke! Ich probiers aus, sobald ich wieder genügend Schlaf intus hab und melde mich dann wieder mit Ergebnissen/Problemen ^^
Wäre cool wenn du Zeit findest um es zu testen, bin mega gespannt :)

Also ich bin grad fleißig am Skripten ^^ Funktioniert sogar, wenn man auf der Kante die Taste gedrückt hält ;)

Zitat:

---

Zitat von Drakee

Also ich bin grad fleißig am Skripten ^^ Funktioniert sogar, wenn man auf der Kante die Taste gedrückt hält ;)

---

Bei mir funktioniert's auch einwandfrei :)
War erst 'n bisschen viel Arbeit die einzelnen Terrain-ID's abzufragen, aber jetzt klappt's tadellos.
Dazu kam ja noch die Wie-lange-halte-ich-welche-Richtungstaste-Abfrage von MagicMaker, die sich ebenfalls bestens integrieren lässt.

Ich hab vorher noch ein Renn-Script gebaut, welches 1. die Position des Actors und 2. die Terrain ID abfragt
(1. um zu checken ob der Held sich nicht mehr bewegen kann weil Wand, und dadurch in seine Standard-Pose wechselt und 2. für Laufgeräusche bei Gras, Schnee usw.)
und sowohl das Renn- als auch das Sprung-Skript kommen sich bei den Abfragen nicht in die Quere.

Bin gerade dabei das ganze jetzt für einen Sprung auf eine höher gelegene Ebene zu scripten, hoffe das klappt auch so gut :D

Nochmal für alle: die Vorschläge von MagicMaker und Drakee sind genial *Credit gib*
Ist anfangs ein bisschen Arbeit aber es erspart den Maps ne Menge unnötige Events. :)

Naja, bei mir habe ich gerade einen Bug produziert gekriegt. Aber ich hab das Skript für das überspringen von Lücken und das Skript für das Hochspringen/Runterspringen an Kanten gesondert. Die kommen sich in die Quere, denk ich mal :D

Bei dem Hochspringen an eine Kante ist es wie gesagt ähnlich, nur dass im Vornhinein die X/Y Coordinate des Felds um eins in die Blickrichtung des Helden abgefragt wird. Das muss man nicht in ein extra Skript tun, aber in eine extra Variable. Dann kann man bei einer Wand eine weitere Abfrage starten, ob ein weiteres Feld weiter ein begehbares Tile liegt :)

Ich bin so glücklich dass es funktioniert :D Das hat mir echt Kopfschmerzen, ja, fast schlaflose Nächte bereitet :D
Gut, dann achte ich darauf die beiden Dinge voneinander zu trennen.
Muss ins Bett, aber ich melde mich sobald wie möglich mit weiteren Ergebnissen :)

Also, so schwer war das doch jetzt nicht, oder? xD

Ist auf jeden Fall besser, als jedes Mal Map Events zu benutzen. Auf diese Weise ist es halt einfach alles automatisiert und wenn man das wirklich so wie in Golden Sun haben will, dann will man ja überall, wo es möglich ist, Lücken überwinden und auf höhergelegene Kanten springen können. So braucht man nur zu mappen und das entsprechende Common Event regelt alles von alleine :) Man muss halt beim Mappen nur ein bisschen drauf achten, dass man das nicht so designt, dass man auf einmal dann doch irgendwo hinspringt wo es von der aktuellen Position aus nicht geht.

Und von welchen Zusätzen da MagicMaker geredet hat, versteh ich auch nicht :D

Im Endeffekt war's jetzt nicht so schwer, das stimmt :) Ich hatte zwar eine ungefähre Vorstellung davon, wie es umsetzbar wäre, aber mir fehlte der nötige Anstoß in den Details, da ich jetzt wirklich nicht so krass technisch begabt bin.^^
Die Automatisierung macht das System für mich so attraktiv. Ich könnte mir vorstellen das es dem Spieler auch etwas mehr Freiheit bietet und in ihm vielleicht sogar eine Entdecker-Ader geweckt wird. Zu oft hatte ich schon Spiele gespielt (auch "professionelle") bei denen ich einfach nur durch gehechtet bin, weil die Maps, auch wenn sie vielleicht optisch ganz nett gestaltet waren, keine Tiefe geboten haben. Dazu dann noch die technische Einschränkung dass man sich eh kaum bewegen kann.

Zitat:

---

Zitat von Drakee

Man muss halt beim Mappen nur ein bisschen drauf achten, dass man das nicht so designt, dass man auf einmal dann doch irgendwo hinspringt wo es von der aktuellen Position aus nicht geht.

---

Das sollte glaube ich ganz gut funktionieren, sicher gehen die ersten 5 Maps daneben und man irgendwo solche Stellen, aber das sollte mit etwas Ordnung in den Tilesets gut gehen :)

Wo wir vorher von Bugs gesprochen haben:
Ich hab jetzt komischerweise Weise den Fehler, wenn der Actor sich noch im Move-Befehl befindet
(Slip Through ON, Start Jump, Move Up, Move Up, End Jump, End Slip Through usw.)
und ich währenddessen schon eine andere Richtungstaste drücke, dann geht zwar alles ganz gut aber der Slip Through ist dann für einen kurzen Moment aktiv und ich gerate in Tiles rein, aus denen kein Entkommen mehr ist. :D Hast du eine Idee woran das liegen könnte?

Die Bewegung lässt den Rest vom Event nicht warten und wenn es vorbei ist, kann man wieder Eingaben tätigen.

Könnte man auf einige Arten lösen. Die Gummihammermethode wäre z.B., das Event am Schluss so lange in einer
kleinen Warteschleife einzufangen, bis am Ende der Kette an Bewegungsanweisungen ein Switch umgelegt wird,
was man zum Glück direkt mit in Move einbauen kann.

Code:

---

<>Loop Start
 <>If s[0001] == ON
  <>Set Switch: [0001] = OFF
  <>Break Loop
  <>
 : EndIf
 <>Wait: 0.0s
 <>
: Loop End
<>

---

Danke MagicMaker! Ich probiers gleich aus :)
EDIT: Frage vergessen: Was bewirkt dieses kleine lustige Wait?

Das ist, damit das Spiel diese Schleife nicht in einem ungeheuerlich kurzen Moment so oft wiederholt,
bis die Engine schlapp macht und laggt. Mit 0 wird auf den nächsten Frame gewartet (x60=1s).

Eine andere Frage:
Ist der Slip Through eigentlich nötig? Bei nem Jump kann man einige zuvor unpassierbare Tiles bereits passieren. Würde das bei dir schon reichen, oder gibt es da Konflikte? Ich könnte mir z.B. vorstellen, dass der Jump nur bei Lower Layer Tiles funktioniert. Kenne mich mit Move Events und Maps (lustig, oder?) nicht so gut aus.

Zitat:

---

Zitat von MagicMaker

Das ist, damit das Spiel diese Schleife nicht in einem ungeheuerlich kurzen Moment so oft wiederholt,
bis die Engine schlapp macht und laggt. Mit 0 wird auf den nächsten Frame gewartet (x60=1s).

---

Aaahhh verstehe! Dass es manchmal auf solche vermeintlichen Kleinigkeiten ankommt ^^

Zitat:

---

Zitat von Nagasaki

Eine andere Frage:
Ist der Slip Through eigentlich nötig? Bei nem Jump kann man einige zuvor unpassierbare Tiles bereits passieren. Würde das bei dir schon reichen, oder gibt es da Konflikte? Ich könnte mir z.B. vorstellen, dass der Jump nur bei Lower Layer Tiles funktioniert. Kenne mich mit Move Events und Maps (lustig, oder?) nicht so gut aus.

---

Hab's gerade mal kurz an nem einfachen Map-Event getestet und der Slip Through war nicht nötig, hab auch direkt getestet ob es nur bei Lower Tiles möglich ist.
Dabei ist auffällig, dass es keine Rolle spielte welches Tile da übersprungen werden sollte, sowohl Lower als Upper Layer sind kein Problem, sowie Map-Events
die die Priority "Same as Players" haben.
Großes Aber: wie es aussieht, muss das Tile das sich hinter dem zu überspringenden Tile/Event befindet ein Lower Layer bzw. kein Event, das die gleiche Priority wie der Actor hat, sein. Ansonsten funktionierte der Sprung nicht.
Kurzes Fazit: Nice to know und hilft bestimmt auch bei der Lösung meines aktuellen Problems :)

Zitat:

---

Zitat von Exas

Großes Aber: wie es aussieht, muss das Tile das sich hinter dem zu überspringenden Tile/Event befindet ein Lower Layer bzw. kein Event, das die gleiche Priority wie der Actor hat, sein. Ansonsten funktionierte der Sprung nicht.

---

Wenn das Feld auf dem man landen will nicht passierbar ist, sollte man dann nicht grundsätzlich ebenso wenig dort hinspringen können? Es gibt sicher Momente, in denen man das doch so handhaben will, aber ist das von dir beabsichtigt?

Hat dir der Lösungsweg von MagicMaker eigentlich weitergeholfen? Ich habe deinen Code mal nachgebaut und kann den Fehler beim besten Willen nicht reproduzieren. Also das (Slip Through ON, Start Jump, Move Up, Move Up, End Jump, End Slip Through). Selbst ohne MagicMakers Switch passiert bei mir nichts dergleichen.

Achja, und statt Move Up/Left etc. zu verwenden, wäre Move Forward einfacher. Dann kannst du das gleiche Move Event für alle Richtungen beibehalten.

Der Sprung kann solange ausgeführt werden, solange wie das angesteuerte Tile passierbar ist. Somit ist es nicht nötig Slip Through zu benutzen. Tiles sind dann nicht passierbar, wenn sich Events mit "same layer as hero" darauf befinden. Da muss man halt entweder Designtechnisch aufpassen und doch Slip Through benutzen oder der Spieler kann halt da nicht hinspringen, wenn ein NPC da nicht steht. :)

Ach, btw, so sieht das dann ungefähr in Aktion aus:
https://www.youtube.com/watch?v=pb3PRtWnsQ8

Zitat:

---

Zitat von Nagasaki

Achja, und statt Move Up/Left etc. zu verwenden, wäre Move Forward einfacher. Dann kannst du das gleiche Move Event für alle Richtungen beibehalten.

---

This.

Entschuldigt meine späte Rückmeldung, war zwischendrin mit den Soundtracks fürs Spiel beschäftigt und sowas nimmt leider ja doch etwas Zeit in Anspruch^^

Zitat:

---

Zitat von Nagasaki

Wenn das Feld auf dem man landen will nicht passierbar ist, sollte man dann nicht grundsätzlich ebenso wenig dort hinspringen können? Es gibt sicher Momente, in denen man das doch so handhaben will, aber ist das von dir beabsichtigt?

---

Nein, versteh mich nicht falsch, das ist auf jeden Fall nicht beabsichtigt. Ich wollte lediglich mal testen, wann das passieren grundsätzlich möglich ist und wann nicht. Aber es ist so wie du schon sagst, in einigen seltenen Fällen wird es durchaus mal nötig sein auch an unpassierbaren Stellen springen zu können.

Zitat:

---

Zitat von Nagasaki

Hat dir der Lösungsweg von MagicMaker eigentlich weitergeholfen? Ich habe deinen Code mal nachgebaut und kann den Fehler beim besten Willen nicht reproduzieren. Also das (Slip Through ON, Start Jump, Move Up, Move Up, End Jump, End Slip Through). Selbst ohne MagicMakers Switch passiert bei mir nichts dergleichen.

Achja, und statt Move Up/Left etc. zu verwenden, wäre Move Forward einfacher. Dann kannst du das gleiche Move Event für alle Richtungen beibehalten.

---

Leider konnte ich das Problem bis jetzt immer noch nicht beheben. Bin jetzt auch an dem Punkt wo sämtliche Slip Through's entfernt sind. Der Lösungsweg von MagicMaker funktioniert grundsätzlich super. Aber ich befürchte, dass das Problem doch woanders liegt, nämlich im vorangehenden Script für die Messung der Tastendruck-Dauer. Ich glaube dass es zu Komplikationen kommt, wenn ich eine andere Taste drücke, in dem Moment, wenn die Variable den Schwellenwert erreicht um das Move Event auszulösen. Leider sind's zu gegebenem Zeitpunkt nur Vermutungen weil ich's bis jetzt noch nicht zu 100% eingrenzen kann. Ich denke auch dass der Code von MagicMaker einwandfrei funktionieren müsste, wahrscheinlich hab ich einfach nur schlecht gecoded :D Ich werde heute weitere Tests durchführen und schau mal was ich noch so reißen kann.

@Drakee So hab ich mir das vorgestellt! Sieht super aus :) Ich hoffe ich krieg's auch so hin xD

Das Problem bei mir war, dass ich wärend des MoveBefehels noch die Richtung ändern konnte, durch Tastendruck. Da habe ich gegen gewirkt, indem ich die Movementroute in ein Auto-Start CE gepackt habe, das per Switch aktiviert wird.

Ahhhhhh das könnte das Problem schon beheben. Leider funktionierte (aus irgendeinem Grund den ich vermutlich niemals erfahren werde) der "Proceed with Movement"-Befehl nicht.. Ich meld mich nochmal mit handfesten Ergebnissen :)

Wie meinst du "funktionierte nicht"?

Der Befehl wartet darauf bis alle Move Events die momentan laufen, abgeschlossen sind. Eigentlich sollte der Befehl "Wait until moved" oder so heißen. Achtung, das bezieht sich auch auf solche, die von anderen Events ausgelöst wurden.

Zitat:

---

Zitat von Cherry

Wie meinst du "funktionierte nicht"?

Der Befehl wartet darauf bis alle Move Events die momentan laufen, abgeschlossen sind. Eigentlich sollte der Befehl "Wait until moved" oder so heißen. Achtung, das bezieht sich auch auf solche, die von anderen Events ausgelöst wurden.

---

Jep, dieser Befehl wartet mit der Ausführung des nächsten Befehls, bis alle aktuell laufenden (durch CE und Map Events) Move Befehle beendet sind.

Ganz abgesehen davon habe ich bemerkt, dass ohne diesen Befehl meist im Movement so Sachen wie "Slip Through", "Increase Speed", "Decrease Speed" nicht richtig funktionieren oder die Movement Route abgebrochen wird. Das hatte ich bei Altered Royalty, wenn man den Bogen gespannt hat, dass die Heldin beim Spannen die Richtung fixiert hat und eine Stufe langsamer werden soll, aber unter Umständen der "Increase Speed"-Befehl gar nicht erst ausgeführt wurde. Mit einem "Wait Until Movement"-Befehl dahinter hat das dann funktioniert.

Der Befehl "Stop Movement" stoppt übrigens die Movementrouten ;) Den kann man u.U. an einigen Stellen auch gut gebrauchen.

Zitat:

---

Zitat von Cherry

Wie meinst du "funktionierte nicht"?

Der Befehl wartet darauf bis alle Move Events die momentan laufen, abgeschlossen sind. Eigentlich sollte der Befehl "Wait until moved" oder so heißen. Achtung, das bezieht sich auch auf solche, die von anderen Events ausgelöst wurden.

---

Irgendwie schien der Befehl keine wahrnehmbaren Auswirkungen zu haben.. War alles irgendwie recht komisch..
Ich konnte das Problem bis jetzt leider noch nicht lösen. Ich denke ich werde das Script einmal neu schreiben, da er doch ziemlich unübersichtlich geworden ist und auffällt, das viele Sachen im Code redundant sind. Wie gesagt, ich bin echt nicht der beste Techniker und muss noch viel lernen, vorallem wenn's darum geht "saubere" und ordentliche Scripts zu erstellen.

Aber jetzt verstehe ich wenigstens, was ich zu tun habe um das Ganze nach meiner Vorstellung zu gestalten und dafür bin ich schon sehr dankbar :)
Ich melde mich mit neuen Ergebnissen :)

@Drakee: was hast du eigentlich alles in separaten CE's ausgelagert? Hast du eventuell ein paar Tipps?

Ich habe das komplette Skript in Common Events gepackt. Wäre anders auch irgendwie wieder Copy-Paste Gedöns, das ich mir nicht antun wöllte o.O

Naja, aber es lohnt sich auf jeden Fall Code, den man öfters in seinem Skript aufruft, in ein CE zu packen und das auf Trigger "None" stehen zu lassen und dann halt, statt jedes Mal diesen Code in die entsprechenden Bedingungen reinzukopieren nur den einen Befehl reinkopieren muss, nämlich der Call-Befehl, der den Code dann aufruft. Somit muss man bei einem Bug in besagtem Code nicht jedes Mal im Skript den Code löschen und erneut einfügen, sondern braucht ihn nur in dem entsprechenden CE zu bearbeiten.

Also prinzipiell gilt: Globale Funktionen in CEs und auch Code, den man immer wieder nur kopieren und einfügen würde, sofern er mehrere Zeilen besitzt, per Call-Event-Befehl integrieren. Damit hat man zwar mehr Common Events in der Liste, aber man hat es leichter zu debuggen.

CE sind eine tolle sache zumal du auch hier codes unterbringen kannst die du vlt. Später nochmal gebrauchst dich aber nicht durch 1000 events wühlen willst.

Das hier werd ich mal weiter beobachten hat schon seine Vorteile so ein Sprungsystem ;-)

Lg
Sf88

Hey Leute! Jap, ich lebe noch =D
Ich musste mich kurze Zeit nach unserem letzten Austausch für eine Weile zurück ziehen - hatte ne Menge um die Ohren..
Aber jetzt bin ich wieder aktiv dabei und wollte eine kurze Rückmeldung zu dem Sprungsystem hinterlassen uuuuund:
Es funktioniert! =D
Ich hab wie im letzten Beitrag das Skript nochmal komplett neu aufgesetzt, da ich ja mittels eurer Hilfe nun genau wusste was zu tun ist.
Es funktioniert auf jeden Fall makellos :)

Kurze Zeit später ergab sich allerdings ein völlig anderes Problem - das korrekte Mapping.
Da man im Chipset die entsprechende Terrain-Zuweisung nicht sehen kann und man teilweise ein bisschen mit den Chips tricksen muss um komplexere Maps zu gestalten,
hatte ich die Idee die Chipsets im Vorfeld zu markieren, der Screenshot sollte von selbst erklären was ich meine:

Anhang 23124

Die roten Markierungen entsprechen der Terrain-Zuweisung in der Database.
Das Chipset hat nun somit zwei Versionen. Eine mit Markierungen um die Map zu gestalten, und die andere Version ohne Markierungen, zu der per Autostart-Event gewechselt wird wenn der Spieler die Map betritt. Somit kann man leichter komplexe Maps bauen ohne 5 Millionen mal in die Database zu gehen und zu schauen welches Chip denn jetzt welches Terrain zugewiesen bekommen hat.
Ist letztendlich nichts besonderes und hat kaum was mit der Technik Geschichte zu tun, aber ich dachte mir, falls es andere gibt die dieses System übernehmen wollen dann könnte das einiges erleichtern.

Auf jeden Fall möchte ich mich noch mal bei allen bedanken die hier geholfen und mitgewirkt haben :)