Bei allem Respekt für Neueinsteiger, bei Sachen wie dem Starterpack sollte die explizite Lösung eines Problems immer vor einer impliziten stehen. Wenn ich will, dass eine Tür undurchquerbar ist, dann löse ich sowas doch besser explizit mit Globalints und Konsorten, anstatt implizit eine Walkable Area auszuschalten, was wie man hier sieht, schnell zu Fehlern führt.
Mit diesem (still eingeführten) Feature schleppen wir uns eigentlich nur Inkonsistenzen ein. Bei Türen muss ich keinen expliziten Erreichbarkeits-Check machen, bei allen anderen Hotspots aber schon? Dass MovePlayer(x,y)==2 geht, wusste ich nicht einmal, das ist nirgendwo dokumentiert, wie das meiste des Starterpacks.
Hier mal ein Vorschlag, um das ganze konsistenter und einleuchtender zu machen:
Wie wäre es mit optionalen Parameter für sowohl MovePlayer als auch die Tür-Funktionen, die dafür sorgen, dass die Funktionen false zurück liefern, falls der Punkt nicht erreicht wird und den Fall "nicht erreicht" in Unhandled abfängt? In den 99% der Fälle, wo man diese Abfrage nicht braucht, ignoriert man den Parameter schlicht und einfach, in allen anderen hängt man ihn an. Durch die Autovervollständigung sieht man ihn dann und weiß, dass es ihn gibt (geht mit Rückgabewert ==2 nicht, wenn man nicht die Kommentare im GS liest). Bei dieser Methode muss man explizit dazu sagen, was man gerade braucht und hat das Ganze zudem etwas ausdrucksstärker verpackt, so dass man dem Code anlesen kann, was er Besonderes tut.
Das Ganze könnte dann so aussehen:
[ags]if(MovePlayer(123,456,eCheckReached)) { ... }[/ags]
Analog mit den Türen.
Stelle das einfach mal als Alternative zur Diskussion.
Gruß
JackLD
