[2k3] Probleme mit einem Laufevent

Druckbare Version

09.02.2019, 21:54
Ich bin viele

Liste der Anhänge anzeigen (Anzahl: 2)

[2k3] Probleme mit einem Laufevent

Hey!

Ich habe ein Common Event eingebaut, in dem man per Tastendruck (Shift) laufen kann. In den Optionen kann man umstellen, ob man auf der Taste bleiben muss oder nur einmal drücken muss damit man läuft (also Toggle und Press). Nun habe ich aber folgendes Problem damit: Wenn mann das Laufen z. B. auf "Press" hat, also die Taste Shift loslassen muss um mit dem Laufen aufzuhören, und Shift genau auf einem Tile auf dem ein Switch sitzt loslässt wird der Switch nicht aktiviert.

Ein Beispiel: In einem Dorf ist ein Hügel, wenn man auf dem Hügel ist kann man über die Brücke dort gehen, ist man aber nicht auf dem Hügel kann man unter der Brücke hindurch gehen. Auf dem Aufgang zum Hügel ist ein Switch der bestimmt ob der Spieler auf dem Hügel ist (Switch On) oder nicht (Switch Off). Wenn ich nun aber nun von unten komme und auf den Hügel laufe und genau auf dem Tile wo der Switch aktiviert werden sollte die Shift Taste loslasse wird der Switch nicht aktiviert und die Brücke funktioniert nicht.

Ein anderes Beispiel wäre, dass ein Picture nicht angezeigt wird wenn man auf dem Tile, auf dem das Pic angezeigt werden sollte die Shift Taste loslässt. Das Pic sollte per "Player Touch" angezeigt werden.

Das selbe Problem habe ich allerdings auch im "Toggle" Modus, wenn man Shift genau auf den gewissen Tiles drückt.

Ich habe das Commen Event mal angehängt, ich hoffe jemand kann mir helfen!
10.02.2019, 12:59
Brei

Liste der Anhänge anzeigen (Anzahl: 1)

Ich habe dein Problem reproduzieren können. Tatsächlich sieht es so aus, als würde der Maker "Player Touch" nicht korrekt prüfen, wenn der Hero während der Dauer der Bewegung ein "Set Move Route" bekommt. Das hätte ich jetzt auch nicht erwartet.

Hier eine Reihe von möglichen Workarounds, lass mich wissen, ob einer davon für dich in Frage kommt:
- Du versuchst es mit der Trigger Condition "Collision with hero", musst aber aufpassen, dass es nicht immer wieder aktiviert wird.
- Du prüfst über ein neues Parallel Process Event, ob die Koordinaten des Helden genau das richtige Feld sind
- Du nimmst das bestehende Ebenen-Wechsel Event, ersetzt die Trigger Condition durch Parallel Process und schreibst etwa den Code drumrum den ich dir angehängt habe

Das ist leider alles nicht so richtig optimal, aber vielleicht tuts einer davon für dich.

Ganz unabhängig davon: In deinem Skript sind 3 "Wait 0.0" Befehle, ich denke nicht dass die nötig sind.
Bevor ein Parallel Process event neu beginnt, wartet es ohnehin einen Frame lang (das ist genau was "Wait 0.0" macht...).
10.02.2019, 13:40
Ich bin viele

Liste der Anhänge anzeigen (Anzahl: 1)

Erstmal Danke für die Hilfe!

Ich nehme an es handelt sich dabei um einen Bug, deshalb werde ich mal einen Bugreport zu den Entwicklern schicken und hoffen, dass sich das Problem damit fixen lässt (obwohl ich mir nicht genau sicher bin ob da noch mal ein Patch nachgereicht wird....).

Das mit der Koordinatenabfrage werde ich auf jeden Fall für das Hügelevent und verwandte Events benutzen, auch wenn der Aufwand damit nicht gerade kleiner wird. Zu meinem zweiten Beispiel wäre die Koordinatenabfrage aber suboptimal, da es sich um zu viele Tiles handelt die ein Event beherbergen (Ich füge mal eine Grafik mit ein damit du weißt was ich meine, es handelt sich um ein Picture welches an Transparenz abnimmt, je näher man an den Teleport kommt).

Die Felder ganz links löschen das Picture, rechts daneben wird das Pic angezeigt (auf 99% Transparenz) und je näher man zum Teleport kommt (die letzten Events ganz rechts bei der Statue) desto undurchsichtiger wird das Picture (per "Move Picture"). Wenn ich beim "Show Picture" Event die Shift Taste loslasse zeigt er das Bild nicht, genau so ist es auch beim "Erase Picture", somit bleibt das Picture im Bild. Wie ließe sich das am Besten fixen, hast du eine Idee?

Zitat:

Zitat von Brei

Ganz unabhängig davon: In deinem Skript sind 3 "Wait 0.0" Befehle, ich denke nicht dass die nötig sind.
Bevor ein Parallel Process event neu beginnt, wartet es ohnehin einen Frame lang (das ist genau was "Wait 0.0" macht...).

Ups, Danke Dir, das wusste ich nicht.

Edit:
Gibts vielleicht einen Weg die Geschwindigkeit des Helden anzupassen ohne das über "Move Event" zu machen? Hab jetzt nichts gesehen, aber vielleicht gibt es ja ein externes Programm mit dem sich das bewerkstelligen ließe.
12.02.2019, 19:05
Brei

Eventuell kannst du einfach in einem Parallel Process den Abstand zur Statue nehmen (Screenkoordinaten nutzen, für Genauigkeit), und die Transparanz in Abhängigkeit davon setzen.

Zitat:

Zitat von Ich bin viele

Edit:
Gibts vielleicht einen Weg die Geschwindigkeit des Helden anzupassen ohne das über "Move Event" zu machen? Hab jetzt nichts gesehen, aber vielleicht gibt es ja ein externes Programm mit dem sich das bewerkstelligen ließe.

Wäre kein Thema mit Dynrpg, aber ich nehme an du nutzt die Steamversion?
12.02.2019, 22:31
Ich bin viele

Ich nutze die Version von rpgmakerweb.com, also Standalone soweit ich das beurteilen kann.

Du meinst das ließe sich fixen mit diesem Dynrpg? Das wären großartige Neuigkeiten!
13.02.2019, 08:28
Brei

Also nach meinem Stand ist das leider dieselbe Version - und auch die zu neu. Ich hab mich damit aber nie im Detail auseinandergesetzt.

Hier trotzdem einfach mal ein Link:
https://www.multimediaxis.de/threads...2k3-Plugin-SDK

Aber ja, mit Dynrpg könnte ich dir fix ein Plugin zukommen lassen...
13.02.2019, 10:35
Ghabry

Zitat:

Ich nehme an es handelt sich dabei um einen Bug, deshalb werde ich mal einen Bugreport zu den Entwicklern schicken und hoffen, dass sich das Problem damit fixen lässt (obwohl ich mir nicht genau sicher bin ob da noch mal ein Patch nachgereicht wird....).

Sehr unwahrscheinilch, weil du damit Spiele kaputt machst, die auf die neue Engine aktualisieren, da Spiele von dem Verhalten abhängen (ob sich der Entwickler dessen bewusst ist sei dahin gestellt, in beiden Fällen kommt Mist raus wenn es behoben wird)

Du könntest mal versuchen das Move Event auf dem Hauptinterpreter auszuführen, indem du ein Auto Start Common Event verwendest, vllt. wirkt sich das auf die Eventausführung derart aus, dass Touch noch funktioniert.

Dazu lässt du einfach den existierenden Code, aber statt der Move Route-Befehle setzt du zwei Switche: "MACH_SCHNELLER" und "MACH_LANGSAMER" und das sind die Startbedingungen für zwei Autostart-Events und das einzige, was die Events machen ist, die entsprechende Move Route zu setzen und als letzten Befehl in der Move Route, machst du den entsprechenden Autostart-Switch aus, um zu signalisieren, dass die Bewegung fertig ist (da Autostart-Events die Bewegung des Spielers blockieren)

Aso und das Parallel Event sollte vllt. noch oben prüfen, ob MACH_SCHNELLER/LANGSAMER aktiv sind und dann die Ausführung abbrechen, da dies sonst komische Nebeneffekte haben könnte.

EDIT:
Eine garantierte Touch-Event-Auslösung auf dem Zielfeld am Ende einer Move Route bekommt man übrigens, meines Wissens nach, wenn der letzte Move Route-Befehl eine erfolgreiche (!, also nicht gescheitert weil etwas im Weg war) Bewegung war (also links, rechts, random, jump usw.). Aber für deinen Fall natürlich nicht praktikabel. Das einzige was auf der Stelle wäre, ist Jump/Land, aber sieht natürlich dämlich aus, wenn der Char springt. Eventuell kann man mit "Jump ohne Land" oder "Land ohne Jump" auch Touchevents auslösen, das hab ich aber noch nicht ausprobiert.
13.02.2019, 14:47
Ich bin viele

Zitat:

Zitat von Brei

Also nach meinem Stand ist das leider dieselbe Version - und auch die zu neu. Ich hab mich damit aber nie im Detail auseinandergesetzt.

Hier trotzdem einfach mal ein Link:
https://www.multimediaxis.de/threads...2k3-Plugin-SDK

Aber ja, mit Dynrpg könnte ich dir fix ein Plugin zukommen lassen...

Verzeih meine Unwissenheit, aber warum geht DynRPG nur mit älteren Versionen (ich konnte die Antwort im Thread von Cherry nicht finden) und bekomme ich irgendwie eine ältere Version (ohne das Ganze illegal zu machen), bzw. würde das dem bisherigen Spiel schaden?

Zitat:

Zitat von Ghabry

Du könntest mal versuchen das Move Event auf dem Hauptinterpreter auszuführen, indem du ein Auto Start Common Event verwendest, vllt. wirkt sich das auf die Eventausführung derart aus, dass Touch noch funktioniert.

Danke für die Idee, es funktioniert aber leider nicht. Ich hatte selbst schon eine ähnliche Idee, jedoch scheint es als ob das Durchführen des Move Events nicht zeitgleich mit dem Player Touch Trigger passieren darf, egal wodurch das geschieht. Das Problem ist ja, dass die Player Touch Trigger nicht aktiviert werden wenn zeitgleich die Shift Taste losgelassen wird und somit das Move Event getriggert wird.
Du hast vollkommen recht, sowas zu patchen wäre fatal für jedes Spiel, ausser meines natürlich, das wurde mir dann leider auch klar. Aber vielleicht kann man das Ganze mit DynRPG noch retten, ich will die Hoffnung nicht aufgeben :D
13.02.2019, 14:57
BDraw

Alternative, aber etwas (für Maker-Verhältnisse) unschöne Idee: Du bindest die Events anstatt sie auf "On Touch" zu stellen direkt in das Rennscript ein, bspw. indem du abfragst, ob der Held sich am auf einem Event befindet und, falls ja, dieses per Call Event aufrufst. Um keine "ungewollten" Events dabei zu aktivieren könntest du entweder mit einer Art Liste an zulässigen Event-IDs arbeiten oder allen Events eine zweite Seite zuweisen, wobei die erste dann speziell für Aufrufe durch das Renn-Event gedacht ist.
13.02.2019, 15:33
Ghabry

Theoretisch kannst du vielleicht mittels GetScreenX und GetScreenY ermitteln, ob dein Held gerade still steht oder sich bewegt und dann das setzen der Move Route um einen Frame verzögern, damit Touch events auslösen können.
Hab aber gerade keinen Maker zur Hand, um das auszuprobieren, glaub aber das ScreenX/Y ist auf Bildschirmkoordinaten transformiert, daher müsste der Wert für den Helden konstant sein, was abermals nicht hilfreich ist. :/

Ich probiers mal nachher aus.

EDIT:
Achja klar, der Trick ist natürlich ein Event z.B. oben links in die Map-Ecke zu legen und von diesem ScreenX/Y abzufragen (funktioniert in den Mapecken dann teilweise nicht zuverlässig, weil die Map nicht mehr scrollt wenn du dich bewegst, da müsste man dann Player ScreenX/Y stattdessen abfragen), dadurch kann man dann mittels Screen-Scrolling ermitteln, ob gerade eine Bewegung stattfindet und ob diese bald auf einem Tile endet. Ein Screen-Tile entspricht 256 wenn ich mich recht entsinne.
13.02.2019, 16:53
Brei

Zitat:

Zitat von Ich bin viele

Verzeih meine Unwissenheit, aber warum geht DynRPG nur mit älteren Versionen (ich konnte die Antwort im Thread von Cherry nicht finden) und bekomme ich irgendwie eine ältere Version (ohne das Ganze illegal zu machen), bzw. würde das dem bisherigen Spiel schaden?

Thread dazu: https://www.multimediaxis.de/threads...ionsf%C3%A4hig
Ich entnehme daraus:
Technische Folgen: Wenn du den Patch anwendest würde die Game Engine auf Version 1.08 zurück gehen. (wahrscheinlich wenig relevant für dich)
Rechtlich Folgen: unklar
13.02.2019, 21:18
Ich bin viele

Zitat:

Zitat von BDraw

Alternative, aber etwas (für Maker-Verhältnisse) unschöne Idee: Du bindest die Events anstatt sie auf "On Touch" zu stellen direkt in das Rennscript ein, bspw. indem du abfragst, ob der Held sich am auf einem Event befindet und, falls ja, dieses per Call Event aufrufst. Um keine "ungewollten" Events dabei zu aktivieren könntest du entweder mit einer Art Liste an zulässigen Event-IDs arbeiten oder allen Events eine zweite Seite zuweisen, wobei die erste dann speziell für Aufrufe durch das Renn-Event gedacht ist.

Da ein sehr großes und komplexes (zumindest vom Story- und Questumfang her) Spiel geplant ist denke ich nicht dass ich dieses Problem so lösen kann/will, da dies mit zu viel Aufwand verbunden ist (und darüber hinaus das Ganze sehr kompliziert und fehleranfällig ist). Jeder Teleport und jedes noch so kleine atmosphärische Detail wird per "Player Touch" getriggert (z. B. Raben die krächzen wenn man vorbeit geht etc,). Es sei denn ich verstehe das Ganze falsch, dann korrigiere mich bitte!

Zitat:

Zitat von Ghabry

EDIT:
Achja klar, der Trick ist natürlich ein Event z.B. oben links in die Map-Ecke zu legen und von diesem ScreenX/Y abzufragen (funktioniert in den Mapecken dann teilweise nicht zuverlässig, weil die Map nicht mehr scrollt wenn du dich bewegst, da müsste man dann Player ScreenX/Y stattdessen abfragen), dadurch kann man dann mittels Screen-Scrolling ermitteln, ob gerade eine Bewegung stattfindet und ob diese bald auf einem Tile endet. Ein Screen-Tile entspricht 256 wenn ich mich recht entsinne.

Ich glaube ich verstehe nicht ganz was du meinst (bzw. verstehe ich schon was du meinst, jedoch nicht wie sich das umsetzen ließe).
Brei hat schon vorgeschlagen den "Player Touch" Trigger durch einen Paralell Process, der die Helden X/Y Koord und die Event Koord abfragt zu tauschen, jedoch ist dies ein doch etwas komplizierter und aufwändiger Weg (im Gegensatz zum Standard "Player Touch" Trigger), also muss ich mir noch gut überlegen ob ich das wirklich so mache. Wenn ich deinen Vorschlag richtig verstehe wäre das scheinbar mit noch viel mehr Arbeit verbunden. Aber kläre mich bitte auf wenn du kannst, ich hab wie gesagt gerade keine Idee im Kopf wie du das umsetzen willst.

Zitat:

Zitat von Brei

Thread dazu: https://www.multimediaxis.de/threads...ionsf%C3%A4hig
Ich entnehme daraus:
Technische Folgen: Wenn du den Patch anwendest würde die Game Engine auf Version 1.08 zurück gehen. (wahrscheinlich wenig relevant für dich)
Rechtlich Folgen: unklar

Das entwickelt sich zu einem viel größerem Problem als es eigentlich sein sollte meiner Meinung nach, aber vielleicht setze ich mich wirklich mal mit einem Entwickler oder Beauftragten von Enterbrain in Verbindung und frag da mal genau nach.
Ich habe jedenfalls nicht vor das Spiel kommerziell zu verbreiten, das würde die rechtlichen Folgen doch schon mal um einiges schmälern (hoffe ich mal ;D)
13.02.2019, 22:43
Ghabry

Okay das ist jetzt bisschen tricky.
Also du brauchst auf jeder Map, wo rennen gehen soll, irgendein Paralleles event mit folgendem Code:

Code:

@> Control Variables: [0002:Bezug X] = [Bezugspunkt]'s Screen X @> Control Variables: [0002:Bezug X] %= 16 @> Control Variables: [0002:Bezug X] -= 8 @> Control Variables: [0003:Bezug Y] = [Bezugspunkt]'s Screen Y @> Control Variables: [0003:Bezug Y] %= 16

X bzw. Y sind null wenn der Spieler nicht läuft.
AUSNAHME: Wenn der Spieler in einer der vier Bildschirmecken ist, dann scrollt gar nichts und das funktioniert nicht. (hab ich nicht eingebaut)
Für den Fall müsstest du die Spielerkoordinaten abfragen, weil sich in den Ecken nicht der Bildschirm bewegt, sondern nur der Spieler.

Dann Common Event 1 (Rennen durch gedrückt halten hab ich umgesetzt)

Code:

@> Conditional Branch: Switch [0001:Wait for speed updat] is ON @> End Event Processing @> : Branch End @> Key Input Processing: [0001] @> Conditional Branch: Variable [0001] == 7 @> Conditional Branch: Switch [0002:Schnell] is ON @> : Else @> Control Switches: [0002:Schnell] = ON @> Control Switches: [0001:Wait for speed updat] = ON @> : Branch End @> : Else @> Conditional Branch: Switch [0002:Schnell] is ON @> Control Switches: [0001:Wait for speed updat] = ON @> Control Switches: [0002:Schnell] = OFF @> : Branch End @> : Branch End

Common Event 2 (Parallel, Switch 1 ist AN)

Das Event loopt, bis X und Y 0 sind (= Spieler bewegt sich nicht) und dann wartet es 2 Frames, dies ist genug, um Touch events zu triggern und dann wird die move route gesetzt.

Code:

@> Loop @> Conditional Branch: Variable [0002:Bezug X] == 0 @> Conditional Branch: Variable [0003:Bezug Y] == 0 @> Wait: 0.0 seconds @> Conditional Branch: Variable [0002:Bezug X] == 0 @> Conditional Branch: Variable [0003:Bezug Y] == 0 @> Wait: 0.0 seconds @> Break Loop @> : Branch End @> : Branch End @> : Branch End @> : Branch End @> Wait: 0.0 seconds @> : Repeat Above @> Set Move Route: Player, Speed Up, Speed Up @> : Else @> Set Move Route: Player, Speed Down, Speed Down @> : Branch End @> Control Switches: [0001:Wait for speed updat] = OFF
14.02.2019, 09:53
Liferipper

Mal eine ganz simple Lösung: Laufgeschwindigkeit hochsetzen und das ganze Zeug mit Tastendruck weglassen.
Wenn es eine Möglichkeit gibt, schneller zu laufen, werden die ohnehin 90% der Spieler permanent nutzen.
14.02.2019, 20:39
Ich bin viele

@Ghabry
Danke dir für die Mühe! Ich weiß zwar wie man die Player Koord speichert, jedoch habe ich keine Ahnung wie man die Screen Koord in Variablen speichert ^^
Aber so wie es aussieht könnte das tatsächlich klappen, ich versuchs sobald ich das herausgefunden hab ;D

Zitat:

Zitat von Liferipper

Mal eine ganz simple Lösung: Laufgeschwindigkeit hochsetzen und das ganze Zeug mit Tastendruck weglassen.
Wenn es eine Möglichkeit gibt, schneller zu laufen, werden die ohnehin 90% der Spieler permanent nutzen.

Ich weiß nicht ob du mich einfach ärgern willst oder einfach nicht ganz verstanden hast worum es in diesem Thread geht. Ich sag nur ein Wort: Immersion.
14.02.2019, 23:25
IndependentArt

Vielleicht noch eine andere Idee, um die Ebene umzuschalten:
Setze die Events, die den Hügel umschalten sollen auf "same level". Sobald der switch aktiviert wurde, können sie auf "below" umschalten.
Hab das grad mal getestet und müsste eigentlich noch flüssig laufen, der Spieler wird also nicht kurz blockiert oder dergleichen, muss aber auf jeden Fall den Switch auslösen, um da durch zu kommen.

Davon abgesehen muss ich Liferipper ein wenig Recht geben. Ich will dir da nicht reinreden, aber in so gut wie allen Spielen, wo man "gehen" kann benutze ich das nicht und sehe mich schnellstmöglichst nach eine Option um, wie ich das permanent umstellen kann. Spiele, die mich zum drücken einer Taste zum Rennen nötigen, sind da natürlich die schlimmsten. Und auch wenn man sich dran gewöhnt, finde ich es unnötig.
Aber mach es wie du denkst, wenn du es für deine Immersion für nötig empfindest. Ich weiß ja auch gar nicht, was es für ein Spiel wird.

Das mit dem Picture wurde auch noch nicht geklärt oder?
Ich bin nicht sicher, ob du das gelesen hast, was Brei geschrieben hat. Aber genau so würde ichs auch machen.
Könnte grob so aussehen:

Code:

@> Control Variables: [1319:Hero X] = Player's X Coordinate @> Control Variables: [1319:Hero X] -= Variable [1317] @> Conditional Branch: Variable [1319:Hero X] < 0 @> Control Variables: [1319:Hero X] *= -1 @> : Branch End - Bis hier hin ermittelst du quasi den Abstand des Helden zur Statue @> Conditional Branch: Variable [1319:Hero X] < 10 @> Control Variables: [1319:Hero X] *= 10 - Ist der Abstand kleiner als 10 tiles, wird die Variable mit 10 multipliziert und ist damit gleichzeitig deine Transparenzvariable - bei 9 tiles Abstand wäre die Transparenz dann also 90% @> : Branch End @> Move Picture: 1, (160,120), 100%, V[1319]%, @0.3s, Wait - dann vlt noch ein Move Picture Befehl, um das etwas smooth aussehen zu lassen
15.02.2019, 13:14
Ghabry

Also ich finde den Einwand von Liferipper eigentlich auch gerechtfertigt.

Bin ja einer der EasyRPG Entwickler (Also dieser 2k/2k3-Engine-Nachbau) und viele sind uns einfach nur dankbar dafür, dass wir eine "Fast Forward"-Funktion (Taste F) eingebaut haben, die das komplette Spiel um Faktor 3 beschleunigt. Insbesondere in Spielen mit viel Backtracking.

Also ja, wenn es eine Schneller-Taste gibt, werden viele sie wohl regelmäßig verwenden (außer wenn die Umstände erfordern, dass man präzisier laufen muss).

Ich bin da keine Ausnahme, viele Konsolenspiele kann ich nur noch im Emulator spielen, weil vor allem die Kampfsystem so unglaublich langsam laufen. Wenn man Arbeiten muss hat man halt nur noch ein geringes Kontingent für derartige Freizeitaktivitäten, daher ist dies halt einfach eine Optimierung, um in kürzerer Zeit mehr Spaß zu haben und diese nicht durch warten zu verschwenden.
15.02.2019, 17:59
Ich bin viele

Zum Thema "Laufen komplett aus dem Spiel nehmen":
Mir ist sehr wohl bewusst, dass die Möglichkeit besteht den Code komplett aus dem Spiel zu nehmen. Mir ist auch sehr wohl bewusst, dass dies natürlich die einfachste Variante wäre. Jedoch muss euch bewusst werden dass ich dieses Feature nur sehr ungern ausbaue, sonst hätte ich den Thread kaum eröffnet. Ich habe mir schon auch einige Gedanken vorm Einbauen gemacht und bin auf die selben Zweifel gestoßen, schließlich bin ich selbst ein leidenschaftlicher Konsolen- und PC-Spieler. Nun bin ich aber zu dem Entschluss gekommen das Laufscript im Spiel zu lassen und spätere Tester bestimmen zu lassen, ob das Feature als nervig erachtet wird oder nicht. Wie IndependentArt so schön angemerkt hat, weiß niemand wie das Spiel aussehen wird (bis auf einen kleinen Screen) und wie es sich spielt.
Und jemand, der das Spiel sowieso nur "Fast-Forwarden" würde, würde ohnehin keinen Spaß daran haben, Fast-Forward oder nicht ;) (Versteh mich nicht falsch Ghabry, ich selbst benutze die Speed Taste oft in Emulatoren o. ä., nur passt das nicht zu meinem Spiel das u. a. von Details und Environmental Storytelling lebt).

Zitat:

Zitat von IndependentArt

Vielleicht noch eine andere Idee, um die Ebene umzuschalten:
Setze die Events, die den Hügel umschalten sollen auf "same level". Sobald der switch aktiviert wurde, können sie auf "below" umschalten.
Hab das grad mal getestet und müsste eigentlich noch flüssig laufen, der Spieler wird also nicht kurz blockiert oder dergleichen, muss aber auf jeden Fall den Switch auslösen, um da durch zu kommen.

Hmm. Das könnte tatsächlich funktionieren, das werd ich gleich mal ausprobieren!

Zitat:

Zitat von IndependentArt

Das mit dem Picture wurde auch noch nicht geklärt oder?
Ich bin nicht sicher, ob du das gelesen hast, was Brei geschrieben hat. Aber genau so würde ichs auch machen.
Könnte grob so aussehen:

Oh ja, Danke dir für die Mühe! Das ist ungeachtet dessen, ob das Laufscript funktioniert oder nicht, ohnehin die bessere Methode meines Erachtens nach. Werd ich gleich einbauen!