Urwigo : MessageBox nach Input - aber wie?

Hallo,

ich bin gerade dabei, mich mit der Erstellung von WhereIGo zu beschäftigen. Einige Online-Quellen (bpw. wherIBlog.de von krolock) sind sehr hilfreich, aber zu folgenden Problem - ist es überhaupt eins ? - bin ich nicht fündig geworden: MessageBox nach Input

Szenario : Im Inventar des Spielers befindet sich ein Geldbeutel mit bspw 10 Münzen. Ich habe eine Aktion definiert "entnehme Münzen", die es erlaubt, eine beliebige Anzahl Münzen aus dem Beute zu entnehmen.
Diese Aktion soll von verschiedenen Stellen aus - besp. Bestechung eines Wächters, Einkauf auf dem Markt, - aufgerufen werden. Die Behandlung (Bestchungssumme zu niedrig,...) soll dann wieder im entsprechenden Prozeß (beim Waechter und nicht im Input !!) erfolgen.

Also: Dialog -> Input -> Reaktion

Allerdings überdeckten die letzten Messageboxen (rot makiert in Aktion Bestechung) den Input-Dialog.





Habt ihr eine Idee, wie ich es lösen könnte?

Danke schon mal im vorraus

Der Input hat ein "OnInput"-Event, da musst du den Code rein machen.

Hallo denistreysa,

dort habe ich die obige 4-fach Fallunterscheidung (Input_removeCoins) drin, um Fehlerfälle wie zuviele Münzen entnommen. Meines Verstaendnis nach würde die Behandlung, ob die Bestechung "hoch genug ist" an dieser Stelle bedeuten, dass dieser Input speziel für die Bestechungsszene "geprägt" wird- eine Wieder-Vewendung auf dem Markt wäre nicht mehr möglich, so dass ein weiterer Input notwendig wäre. Alternativ könnte ich mit einer Variablen den weiteren Workflow steuern - aber vom Gefühl her wäre es die falsche Stelle.

Naja, von logischem Workflow bei Wherigos zu sprechen ist sowieso Wunschdenken
Fankt ist aber, dass Messages und Dialoge nicht aufeinander warten, sondern schön sequentiell ohne Zutun des Nutzers abgearbeitet werden und so immer die letzte Nachricht gewinnt. In deinem Fall würde also erst die Nachricht innerhalb "Input_removeCoins" angezeigt werden und sofort danach die Nachricht in "Bestechen". Zumindest vermute ich, dass das der Fehler ist.
Eine Lösung habe ich auf die Schnelle nicht parat, aber wie wäre es, wenn du die Logik ein wenig umkehrst und in den 4. Fall, also den Else-Zweig eine Art Dispatcher baust, also im Prinzip wieder eine Mehrfachverzweigung (der Übersicht zu liebe kannst du das ja in eine Funktion packen). In dieser Verzweigung prüfst du dann, in welcher Zone du bist, bzw. von wo du die Funktion aufgerufen hast (per Boolscher variable oder so etwas) und erst da reagierst du dann auf Zonen-spezifische Dinge.

Keine schöne Lösung, aber mehr fällt mir so spontan nicht ein.

Nun gut, fangen wir vorne an: Wherigo ist eigentlich ein eventbasiertes System. Das soll heissen, dass immer die letzte Meldung den Bildschirm belegt. Man stelle sich vor, dass man gerade zu einer Eingabe aufgefordert wird und dabei weiter läuft. Wenn man lange denkt, kann es passieren, dass man in die nächste Zone kommt. Aber was hat nun Vorrang? Die Eingabe aus der letzten Zone oder die Meldungen der neuen Zone? Oder soll es einen Stapel von Meldungen geben, bei dem eine neue Meldung nur die vorhergehende verdeckt und nach der Bestätigung wieder freilegt. Aber ist die alte Meldung dann überhaupt noch relevant? Alles sehr tricky. Bei beiden Ansätzen muss man mitdenken.

Um dieses Problem nun zu lösen, gibt es verschiedene Möglichkeiten.
1. Für jeden Ort, bei dem die Geldbörse benutzt werden kann, wird ein eigener Input angelegt. Die Abfragen für <0, =0 und >max werden mit Copy&Paste von Eingabe-Behandlung zu Eingabe-Behandlung kopiert. Der Vorteil ist, dass man Urwigo nicht verlassen muss. Der Nachteil ist etwas mehr Verwaltungsaufwand.
2. Man erzeugt eine Funktion (z.B. AfterInput), die die Nachbearbeitung der Eingabe übernimmt (in Urwigo möglich). Diese wird vor dem Aufruf der Eingabe in einer Variablen abgelegt. Nach der Eingabe erfolgt die Abarbeitung der Standardsachen (Überprüfung der Geldbörse). Ist alles durch, wird die Funktion, die in der Variablen hinterlegt ist, falls vorhanden, aufgerufen. Dort wird dann die Variale gelöscht und der Nachbearbeitungsteil (genug Geld gehabt) ausgeführt. Der Vorteil ist, dass es vermutlich die am schnellsten umzusetzende Lösung ist.
3. Es gibt eine Lösung von Jan im englischen Forum, bei der die ereignisgesteuerte Arbeitsweise ersetzt wird (http://forums.groundspeak.com/GC/index.php?showtopic=309933). Der Vorteil ist, dass man sich nicht mehr mit den Ereignissen rumschlagen muss und es etwas einfacher für Anfänger macht. Der Nachteil ist, dass es sich um eine Alpha-Version handelt.

Es gibt sicher noch die eine oder andere Lösung, aber das sollte für den Anfang reichen. Ich persönlich würde dir zu Nummer 2 raten. Geht am einfachsten. Bei Problemen einfach die Urwigo-Datei zuschicken, dann kann ich mir es mal anschauen.

So, hier ein Beispiel wie es aussehen könnte (Nummer 2). Ich habe versucht, deine Namen zu verwenden, damit es nicht zu verwirrend wird. Den Rest habe ich dazu erfunden. Es gibt zwei Personen (Wächter und Kaufmann), denen man das Geld geben kann. Beide verwenden die gleiche Eingabe (Auszahlung), aber unterschiedliche Auswertungen (checkWaechter und checkKaufmann). Ich habe versucht, so wenig wie möglich außrhalb (direkt in Lua) von Urwigo zu machen.

Hoffe, es hilft

Hallo Charlenni,

wow, gleich mit einen kurzen Einführungskurs.

Lösung 2 hört sich gut an - ich werde mir Dein Beispiel mal anschauen, ob ich es verstehe. Wenn ich also eine Funktion in einer Variablen speichern kann, dann müßte es doch auch möglich sein, diese als Parameter einer Funktion zu übergeben?
Lösung 3 werde ich mir mal zu Gemüte führen, sobald ich etwas tiefer in die Materie eingestiegen bin.

Vielen vielen Dank für Deine Hilfe

Klar kannst du auch eine Funktion als Parameter an eine Funktion übergeben. Das gibt es dann aber nur in benutzerdefinierten Skripten, da Urwigo leider keine Funktionen mit Parametern kann.

Bei Fragen einfach melden.