@schenki: Nachteil dabei ist aber, dass du den Platz für das Schalterrätsel definitiv markiert hast. Wenn man versteckte Schalter machen wöllte, ist das also schwierig und man müsste es irgendwie überdecken. Wenn man jetzt für sowas ne Markierungsgrafik im upper Layer (oder als Event) hat, kann man jedenfalls schlecht die Terrain-ID dafür setzen, weil es im upper Layer keine Terrains gibt.
Dann hat man mindestens vier Touch-Events, die man auch weglassen kann, wenn man dafür Sorge trägt, dass die X und Y IDs abgefragt werden. Finde da ein PP-Event sinnvoller.
Vereinfacht dargestellt wäre der Code etwa so:
Start Condition: Parallel Process
(wait 0.0)
Fork Condition: Varbiable Hero X [gleich] Variable Schalter X
[-] Fork C.: Variable Hero Y [gleich] Variable Schalter Y
[-] Change Switch: Schalter Tür = ON
[-] ELSE CASE:
[-] Fork Condition: Varbiable Stein X [gleich] Variable Schalter X
[-][-] Fork C.: Variable Stein Y [gleich] Variable Schalter Y
[-][-] Change Switch: Schalter Tür = ON
ELSE CASE:
Change Switch: Schalter Tür = OFF
END CASE
<>
Das Event der Tür bekommt ebenfalls eine Bedingung rein.
Bedingung: Schalter Tür = ON
Teleport, was du so willst wenn der Schalter aktiviert ist.
Ansonsten
Geht die Tür eben nicht auf.
So braucht man nicht mehrere Seiten in ein Event packen. (Es sei denn man will, dass die Tür dann anders aussieht, zB offen steht, wenn der Schalter an ist. Dann wäre ne Seite zwei Sinnvoll und man kann die Bedinungsabfrage weglassen sondern gleich auf Seite zwei als Eventbedingung angeben.)
Ich hoffe, ich hab das so richtig aufgeschrieben. Hab's nicht getestet und es ist garantiert 3 Jahre her dass ich mal nen Schieberätsel gemacht habe... Und ich habe einfach verdammt wenig Ahnung von Technik, ich fuchs mich erst jetzt ins Technikverständnis rein. Ich probier's eventuell später aus. ^^
Edit: ach ja, genau, man sollte das wait nicht vergessen.![]()