Mir ist aufgefallen, dass die Taste ständig getriggert wird, wenn man sie gedrückt hält.
Ich hätte jedoch gerne noch weitere Möglichkeiten.
1. So soll ein Branch nur in dem Augenblick getriggert werden, in dem ich die Taste drücke. Selbst wenn ich sie weiterhin gedrückt halten sollte, sollte der Trigger nicht mehr reagieren sondern erst dann, wenn ich die Taste loslasse und anschließend nochmal drücke.
2. Eine weitere Triggerart wäre, dass ein Zähler läuft während ich eine Taste gedrückt halte. Getriggert wird erst beim loslassen der Taste. Anschließend sollte der Wert der sich während dem drücken "gesammelt" hat irgendwo abgespeichert werden um in weiter verwenden zu können.

Ist die zweite Triggerart zu komplex würde ich mich auch schon darüber freuen, wenn beim loslassen getriggert wird. Also nicht beim drücken einer Taste, sondern wenn man sie wieder loslässt.

Vielleicht gibt es sowas auch schon, aber ich habe es nicht gefunden. Quick time events, kann ich schon vorwegnehmen, entspricht nicht meinen Vorstellungen (auch wenn das Script selbst sehr schick ist).

Danke schonmal im vorraus.

Könnte mir jemand helfen?
Letztendlich bräuchte ich nur ein Script das nur in dem Augenblick (mit paar ms toleranz) true zurück gibt in dem eine Taste gedrückt wird und ein weiteres das true zurück gibt wenn die Taste losgelassen wird.
Für Ideen oder Denkanstoße zum selber lösen bin ich auch dankbar.

Erstmal danke an beide.

@ Bex
Zu 1: So wird es leider nicht gehen. Mit einem Wait lähme ich die Funktion, was ich nicht will. Ein Beispiel:
Mit a schießt man einen Feuerball. Ich will aber nicht, dass man einfach a gedrückt hält und ein Feuerballgespawnt wird. Der nächste Feuerball soll erst dann abgefeuert werden wenn die Taste erneut gedrückt wird. Würde ich wait einbauen würde zwar der Feuerball nicht gespawnt werden, aber der Spieler könnte ihn auch nicht schnell hintereinander feuern.

Zu 2: Ich habe es noch nicht ausprobiert, aber diese Lösung scheint gut zu sein. Dennoch hätte ich genau diese Rechnung in einem Script, da ansonsten die Events sehr umständlich und unübersichtlich werden würden.

@Hindi
Das sieht interessant aus (auch wenn ich durch das Script nicht durchblicke... ). Könnte man bei Key.get_triggered(id) es so einstellen, dass er immer nach true false zurückgibt? (bis halt die Taste erneut gedrückt wird)
Im Anhang fand ich leider nur ein leeres Projekt. Konnte also nicht die ID´s damit ermitteln.


Wo steht eigentlich im RGSS des Makers die Tasterturabfrage? Ich finde da zwar sowas wie "Input.trigger", aber wo es definiert ist nicht.

Cool. Es funktioniert. Doch eins bleibt.
Ich will das Script, fast das ganze Spiel hindurch, als Parallel-Event laufen lassen (ohne wait, da ansonsten die Tastenabfrage ja nicht korrekt arbeitet...). Da kommen mir natürlich Bedenken, wenn es performencenlastig ist oder wie meintest du es? Wie wird es sich auswirken?
Sollte ich vielleicht doch wait in das Parallel-Event einbauen (dann sollte aber das Script die letzten zwei Frames abfragen...)?

Soweit jedoch ein dickes Danke. Das Script gefällt bis jetzt sehr gut!

Achja, das mit dem Anhang passt. Ich hatte es bloß nicht gecheckt, dass das schwarze Feld schon das Programm war.

Cool, dann ist es perfekt, genau das was ich wollte. Danke nochmal.

Aus diesem Grund habe ich mir überlegt beim jeden laden der Map die potenzielle Ziele abzuspeichern, damit bei der Abfrage der Collision nicht alle Events auf der Map berücksichtigt werden müssen. Der Rest würde über die normale passable-Abfrage laufen.
Wie effektiv das ist weiß ich nicht, aber wir werden es sehen.

Edit: Ich weiß nicht ob wir uns falsch verstanden haben, aber bei wird es auch eine kurze Pause geben zwischen den Feuerbällen...

Danke für die Links, doch ich besitze kein VX und kann sie daher nicht öffnen.

Zitat

Was ist eine Passable Abfrage und wie funktioniert diese?

Im RGSS gibt es jeweils unter game_map und game_charakter diese Methode. Diese habe ich etwas modifiziert, damit z.B. Pfeile über Abgründe und Wasser fliegen können, während diese für den Spieler nicht passable, also nicht passierbar bleiben. Damit spare ich mir eine Menge Arbeit mit through und Abfragen von "Kollision".
Ich hatte sogar die Idee die Feuerbälle erst dann die Kollision abfragen zu lassen, wenn sie vor etwas nicht passierbares stoßen. Das wäre sehr Resourcen freundlich und man könnte sicherlich 10 Feuerbälle bei 10 Gegner auf einer Map verwenden. Doch mir gefiel die Ungenauigkeit der Kollision hierbei nicht, daher habe ich diese Idee verworfen.

Ob mein KS 3 Feuerbälle bei 15 Gegner laggfrei verarbeiten kann, kann ich dir noch nicht sagen. Doch da mein Spiel eher darauf zielt Labyrinthe und Rätsel im Stille von Zelda als Schwerpunkt zu haben und der Kampf eher eine Nebenbeschäftigung ist, hat das KS auch nicht den Anspruch enorm komplex zu werden.
Wenn ich eine Lösung finde kann ich sie dir gerne mitteilen. Jedoch arbeite ich soviel meine Kenntnisse mir reichen im Script, um grade die erwähnten Lags zu vermeiden. Daher werde ich dir wahrscheinlich keine befriedigende Antwort geben können, selbst wenn ich ein laggfreies KS hinbekomme.

Edit: Noch ein kurzes Wort wie ich es bis jetzt handhabe mit den Feuerbällen (in meinem Fall ist es ein Enterhaken).
Ich erstelle mir ein Map auf der alle Attacken und Fähigkeiten als Event "gelagert" sind. Mit dem Clone-Script lasse ich diese dann nach einem Tastendruck auf die aktuelle Map kopieren. In dem kopierten Event sind alle Eigenschaften enthalten. Es fragt auch selber nach möglichen Kollisionen ab und was nach denen passiert. Soweit die Idee und bis jetzt funktioniert noch alles wie gewollt.