Moin Leute,

ich hab schon wieder ne Frage, wo ich nicht weiter komme.

ich häng die hier einfach mal dran, weil sie zum Thema dazu passt, würd ich sagen.

Folgendes Prob: ich möchte gern SÄMTLICHE automatische Meldungen in Klammern aus dem Spiel schmeißen - samt der daran hängenden Aktionen.

Oder anders: ich will KEINE automatische Türöffnung, kein automatisches nehmen und vor allem: keine automatische Objektauswahl, wenn mehrere unter dem Synonym zur Auswahl stehen.

Implicite Sachen kann ich sicher mit dem Hinweis auf Kapitel 17 regeln, wenn ich mich da durchkaue, aber grad beim letzten: - automatische Objektauswahl - ich habe keine Ahnung, welche Rule oder Activitie das regelt. (Und es nervt tierisch g).

Gruß

Bushin

Bushin:

... und vor allem: keine automatische Objektauswahl, wenn mehrere unter dem Synonym zur Auswahl stehen.

Bei gleichberechtigten Objekten wird standardmäßig nachgefragt:

Mein Testspiel:

Hundesalon

Du siehst hier einen Pudel, eine Pudelfigur und einen Kamm.

u pudel

Was meinst du, den Pudel oder die Pudelfigur?

Die Disambiguierung in Inform ist weitegehend hard-coded. Mit "Does the player mean ..." und "Rule for deciding whether all includes ..." kann man da für bestimmte Aktionen und Objekte eingreifen, aber wie man den Vorgang komplett aushebeln kann, weiß ich nicht. (In der I6-Routine Adjudicate(), die dem Parser als Entscheidunghilfe dient, passiert eine ganze Menge; Adjudicate durch einen Dummy, der immer false zurückgibt, zu ersetzen führt zu Fehlern.)

Vielleicht könntest Du ja mal ein konkretes Beispiel angeben, wo in Deinem Spiel nicht disambiguiert werden soll.

Grüße,

Christian

Grüß Dich.

Die Nachfrage seitens des Parsers ist ja in Ordnung. Könnte mir auch nicht vorstellen im Augenblick, dass man bei einem größerem Spiel ohne Nachfragen auskommt.

Ich beschreib mal das konkrete Problem, wo mir das aufgefallen ist: Meine Vorstellung war, ein "Knowledgesystem" zu entwickeln. Der Spieler hat dabei die Möglichkeit, seine Spielfigur über einige Themen auszufragen.

Beim ersten Rumspielen kam dabei das raus:

Zitat:

darkred

Sodale. Man wirds nicht glauben, aber das hat ziemlich gut funktioniert: Die Nachfrage auf Mathe ("Erzähl mir über Mathe") ergab zum Beispiel 1 a Auskunft.

Problem waren allerdings die Symbole. Weil: es gibt in einigen Räumen des Spiels andere Objekte, die auch "symbole" als Synonym hinterlegt hatten.

Was macht der Parser? Statt in diesem Fall den Spieler vor die Wahl zu stellen - a) Zitat:

"Was meinst Du, die Symbole oder die Wand mit den Symbolen"

• passiert b):

Zitat:

Erklär mir symbole

(die Symbole an der Wand)

Dazu weiß ich im Augenblick nichts zu sagen, was Dir weiterhelfen kann.

Und das ist einfach mies :-)

Verantwortlich dafür scheint die Activity "clarifying the parser´s choice of something" zu sein. Soviel hab ich schon mal rausbekommen. Aus irgend einem Grund springt diese Regel offensichtlich an Stelle der "Does the player mean" - Activity ein.

Warum ist mir schleiherhaft, aber scheinbar haut das nicht richtig mit der "any thing" Lösung aus obigem Probier - Code hin.

Eine wirkliche Lösung wäre für mich:

• entweder die Clarifying - Regel ausknipsen (die braucht eh kein Mensch g zumindest ich nicht) oder

• es hinbekommen, dass der parser eben NICHT selbst wählt, was gemeint ist sondern stattdessen nachfragt

(als dritte Möglichkeit wäre für mich vorstellbar: die Claryfyingregel so modifizieren, dass der Text - "(die Symbole an der Wand)" - wenigstens in einem anderem (nämlich meinem eigenen) Schriftbild ausgegeben wird. So als grundsätzliche Möglichkeit. Hat aber jetzt nichts mit dem speziellen Problem hier zu tun sondern eher allgemein.)

Die "one visible thing / [any thing]" - methode hab ich inzwischen wieder gestrichen und eine einfachere Lösung geschrieben. Diese bedingt, dass das Objekt im Raum ist, aber damit ist natürlich das Erzählen über Objekte, die eigentlich nichtphysisch sind - mathe oder Physik zum Beispiel - erst mal vom Tisch. Und insgesamt ist das nur eine Halblösung.

Naja, mal sehen ob damit was anzufangen ist.

Gruß

Frank

Bushin:

Die Nachfrage seitens des Parsers ist ja in Ordnung. Könnte mir auch nicht vorstellen im Augenblick, dass man bei einem größerem Spiel ohne Nachfragen auskommt.

Schöner wär's natürlich, wenn der Autor von vornherein versucht, Mehrdeutigkeiten zu vermeiden. Das ist bei der Verwendung von [any thing] natürlich schwierig, lässt sich für Dinge, die "in scope" sind, aber mittels der "Does the player mean ..."-Regeln ganz gut in den Griff bekommen: In vielen Zusammenhängen ist durch Weltwissen dem Spieler klar, was gemeint ist (dem Spiel muss man da etwas auf die Sprünge helfen). Dass an einem Souvenirstand vor dem Eiffelturm der Spieler den kleinen Messing-Eiffelturm und nicht das Riesending hinter dem Stand kaufen will, ist klar; da käme eine Nachfrage à la "Was willst du kaufen, den kleinen Eiffelturm aus Messing oder den riesigen Eiffelturm?" ziemlich seltsam (es sei denn, der Spieler ist ein Multimilliardär mit einer Sammelleidenschaft für Original-Wahrzeichen aus aller Welt).

Vielleicht ist ja die folgende Erweiterung für Deine Zwecke geeignet:

http://inform7.com/extensions/Jon%20Ingold/Disambiguation%20Control/index.html

Damit bekommt der Autor etwas mehr Kontrolle über die Disambiguierung. Es soll weniger geraten und mehr nachgefragt werden.

Edit: Die Erweiterung "Disambiguation Control" ist leider noch nicht kompatibel mit der deutschen Übersetzung, da Teile des Parsers, die in GerX verändert werden, von DC erneut verändert werden. Da müsste eine komplette Anpassung an GerX erfolgen.

Es gibt übrigens auch eine Erweiterung fürs Wetter:

http://inform7.com/extensions/Ish%20McGravin/Weather/index.html

(die ist möglicherweise nicht mehr ganz aktuell)

Servus Christian,

g mit dem Eifelturm hast Du natürlich recht.

Das mit "Any Thing" hab ich inzwischen erst mal gestrichen, weil es doch mehr Probleme macht als sinnvolles zu bewirken. Vielleicht ne gute Lösung für speziellere Knackpunkte aber so als Allgemeinlösung empfind ich das inzwischen als doch recht ungünstig.

"Mein" Wetter läuft inzwischen übrigens hervorragend Komplett mit Zufallsberechnung, Anpassung der Backdrop Descriptions, Textausgaben etc.

(Nicht dass das nen alten Hasen vom Hocker reißen wird mich als Anfänger stolzt das schon a bißerle )

Gruß und schönen Tag

Frank

Der Riese I7 steht leider auf den tönernen Füßen des I6-Parsers. Das Token [any thing] wird in I6 nach dem Schema scope=Routine abgebildet:

    switch (scope_stage) {

        1:  rfalse;

        2:  objectloop (x has explicable) PlaceInScope(x);

            rtrue;

        3:  "Dafür gibt es keine Erklärung.";

    }

];

[ mir;

    if (NextWord() ~= 'mir') wn--;

    return GPR_PREPOSITION;

];

Extend 'erzaehl' 'erklaer'

    * mir scope=ExplainScope                -> Explain

    * mir 'ueber' scope=ExplainScope        -> Explain

    ;

In Stufe 2 der Routine werden Objekte "in Scope" gebracht. Nur diese Objekte werden untersucht. Durch den Rückgabewert wird festgelegt, ob ausschließlich die dort in den Scope verschobenen Objekte berücksichtigt werden (true) oder ob diese Objekte zusätzlich zum regulären Scope, d.h. zu den im Moment sichtbare Objekten, untersucht werden sollen (false).

In Stufe 3 wird eine maßgeschneiderte Fehlermeldung ausgegeben, wenn kein Objekt gefunden wurde. Diese Meldung ist analog zur vagen Fehlermeldung "Du siehst so etwas hier nicht", die bei Standardaktionen ausgegeben wird. Diese Meldung muss vage sein, weil ja kein Objekt gefunden wurde, also auch kein Objektname ausgegeben werden kann. (Das stört manchen, ist aber mit dem Inform-Parser ohne größere Eingriffe nicht anders möglich.)

Wenn die Eingabe auf mehrere Dinge im Scope passt, wird wie üblich nachgefragt.

Ich habe einmal versucht, das Ganze in I7 abzubilden: (Das heißt, der I6-Code oben ist eigentlich nach dem I7-Code unten entstanden)

003399

Weil ich keinen Weg gefunden habe, die Fehlermeldung zu beeinflussen, habe ich eine zusätzliche Aktion 'ignoring' eingeführt, die mit einem Topic-Token nicht verstandene Eingaben für 'explaining' abfängt. (Wenn ich diese Pseudo-Aktion herausnehme kommt beim Erklären von nicht erklärbaren Objekten die Meldung "Dieses Hauptwort macht in diesem Zusammenhang keinen Sinn", was tatsächlich etwas verwirrend ist - welches Hauptwort denn?)

Das System funktioniert ganz gut. Man kann mit einem Attribut steuern, wozu es eine Erklärung geben soll und wozu nicht. Mit "Does the player mean" kann man auch Objekte bevorzugen. Wenn sich allerdings die Eingabe auf mehrere erklärbare Objekte bezieht, von denen eins sichtbar ist und die anderen nicht, wird automatisch das sichtbare Objekt bevorzugt, selbst wenn man alle erklärbaren Objekte mit "Does the player mean" gleich bevorzugt. (Ich nehme an, dass die normalen Regeln den besonderen nachgeschaltet werden, wenn diese nicht eindeutig ein Objekt finden können. Wenn ich aber in der Definition von explaining "applying to one visible thing" in "applying to one thing" abändere, bekomme ich Probleme.)

Mein Testbeispiel:

003399

Wie cool is das denn ^^ danke!

Ich werd als nächstes mal ausprobieren, Tabellen zu benutzen für die "Erklär mir" - Nachfragen. Ich stell mir das etwa so vor, dass damit einfach Text-Strings (ala "Physik") angelegt werden.

Bei darkred wird dann der entsprechende zugeordnete Text in der Tabelle ausgeschrieben. Das wird ja irgendwie machbar sein. Zumindest hab ich dergleichen bei Emily Short gesehen.

Noch geschickter wär natürlich, statt "Physik" ein Token green zu schreiben und das mit green zu definieren. Die Texte für das Token sollten dann über eine Tabelle abrufbar sein (hoffe ich doch). Aber das sind nur theoretische Ansätze, da muss ich erst mit rumspielen, hoffe aber, dass das funktioniert.

Schönen Tag

Frank

Sehr schönes Beispiel von Martin.

Martin:

Weil ich keinen Weg gefunden habe, die Fehlermeldung zu beeinflussen, habe ich eine zusätzliche Aktion 'ignoring' eingeführt, die mit einem Topic-Token nicht verstandene Eingaben für 'explaining' abfängt.

Wenn man sich die Hilfsaktion Ignoring sparen möchte, die lediglich eine Fehlermeldung ausgibt, kann man auch Folgendes schreiben:

blue

CristianB:

Wenn man sich die Hilfsaktion Ignoring sparen möchte, die lediglich eine Fehlermeldung ausgibt, kann man auch Folgendes schreiben: ...

Das ist ja elegant! Und wenn man unter Zeitdruck etwas nicht Erklärbares erklärt haben will, spart es auch noch einen Spielzug.

Bushin:

Ich werd als nächstes mal ausprobieren, Tabellen zu benutzen für die "Erklär mir" - Nachfragen. Ich stell mir das etwa so vor, dass damit einfach Text-Strings (ala "Physik") angelegt werden.

Grundsätzlich kann man die Erklärungen als Texte von Objekten oder in einer Tabelle, in der dann Objekten Texte zugeordnet werden, definieren, je nachdem ob man die Texte lieber kompakt auf einen Blick gebündelt oder beim jeweiligen Objekt stehen haben will.

Tabellen werden in I7 auch oft zur Konversation verwendet: Einem NPC wird eine Tabelle zugeordnet, in der dann zu jedem Thema eine Antwort steht. Bei zwei Objekten (Gesprächsparter und -thema) ist das gewiss praktisch. Man spart sich viele "Instead of asking the Oracle about the temple, say ..."-Phrasen.

Allerdings wird in I7 statt Objekten eher ein "Topic", also ein beliebiger [text] verwendet. Das hat den Vorteil, dass man sich nicht um den Scope kümmern muss. Außerdem kann man so beliebige Themen zulassen, auch extrem unisinnige. Ein Nachteil, den ich in Deinem Fall sehe, ist, dass die Vokabeln redundant sind. Wenn sagen wir mal die Understand-Phrasen der Sonne nicht mit den Topics der Sonne in der Tabelle exakt übereinstimmen, kann es zu inkonsistentem Parserverhalten kommen. Wenn beim Erklären "Sonne" nicht verstanden wird, weil in der Tabelle nur "Sonnensymbol" steht, denkt der Spieler, dass es dazu keine Erklärung gibt. Natürlich kann man beides abgleichen, aber man denkt man daran, die Tabelle zu aktualisieren, wenn man im Betatest schell ein Synonym fü das Objekt Sonne nachzieht?

Nicht umsonst heißt ein guter Grundsatz beim Programmieren DRY - Don't Repeat Yourself. Deshalb habe ich im Beispiel oben Objekte, keine "Topics" gewählt. Damit nicht alle Objekte als Thema taugen, habe ich die möglichen Objekte über das Attribut explicable eingeschränkt. Man könnte vermutlich auch nur die Objekte aus einer bestimmten Tabelle hernehmen.

Einige entnervte Tage später g:

die Lösung Topics über Tabellen zu definieren und die Texte auf diese Art übersichtlich zu ordnen hat mir extrem gefallen.

ggg nur....

Für "Erklär mir..." hat das super funktioniert. Den selben Spaß wollte ich mir gönnen für die Texte von Buchkapiteln: Ein Kapitel als Token definieren und den entsprechenden Text dazu schreiben. Ist ja auch explizit so vorgesehen: Short und auch Aikin beschreiben die Technik.

Die Tabelle und der gesamte Code wurden ordentlich compiliert. Nach Start und dem befehl ">lies Kapitel"

produzierte Inform mir dazu "Run Time Errors", die mit Tokens zusammenhingen. Ich hab stundenlang daran rum gebastelt, alles mögliche ausprobiert - keine Änderung.

Ich hab das aufgegeben und die Buchkapitel als Objekte hinterlegt. Damit klappt es super. Aber ärgerlich ist das schon grmpf

Gruß aus München

Frank

Der Murks kann sich überall verbergen. Hast Du ein Beispiel zum Reproduzieren der Runtime-Fehler, das Du hier posten magst?

Es könnte sein, dass Du die Grammatik für "lies/les" erst komplett löschen musst, da das Verb schon in anderen (komplexen) Satzmustern benutzt wird (z.B. für consulting it about). Und da wir dem Parser noch nicht sagen können, welche Satzmuster er bevorzugen soll, könnte das zu Problemen führen.

blue

Und dann Deine neuen Definitionen für die Verben "lies" und "les".

Hallo Christian,

also ich hab das jetz noch mal zamgebaut:

Zitat:

green

Das hier ergibt der Testdurchlauf:

Zitat:

darkred

Das ist Informs Komentar zu dem Fehler:

Zitat:

darkblue

Ich musste da jetzt erst mal ne Zeit lang rumprobieren, bis der Fehler überhaupt wieder aufgetreten ist, dachte schon ich hab Hallus kopfschüttel, weil erst mal alles tadellos funktioniert hat.

Inzwischen glaub ich hab ichs: die Crux scheint in der Formulierung darkred zu liegen. Alles andere funktioniert ja scheinbar.

Ein weiteres Prob mit Tokens in dem Zusammenhang scheint zu sein:

Zitat:

darkred

Das kann ich natürlich auch nicht so lassen. Aber da examining nicht mit Tokens zusammenpaßt, bleibt da wahrscheinlich nur, die lesbaren Einträge als "Thing" zu markieren, vielleicht in einer weiteren Column, die dann mit dem jeweiligen Eintrag korrespondieren. Mal sehen.

Viele Grüße

Frank

P.s. hm...je nach dem wie die Gepflogenheiten hier sind, aber aus Gründen der Übersichtlichkeit rechtfertigt das fast ein separates Thema, ne? Mea Culpa, fürcht ich...

Der Tracer mit Level 2:

[line 8 * Routine(23495) 'in' Routine(23501) noun 'ueber' topic Routine(23444) -> Consult]

[line 8 token 1 word 2 : Routine(23495)]

[line 8 token 2 word 2 : 'in']

[line 8 token 3 word 3 : Routine(23501)]

[line 8 token 4 word 3 : noun]

[line 8 token 5 word 5 : 'ueber']

[line 8 token 6 word 6 : topic]

Library error 13 (0,0)

A 'topic' token can only be followed by a preposition

*** Run-time problem P37: Low level error.

[line 8 token 7 word 9 : Routine(23444)]

[line 8 token 8 word 9 : END]

[Line successfully parsed]

In dem Buch findest du nichts Interessantes darüber.

Das könnte ein Fehler in GerX sein. Wir haben Definitionen von Satzmustern in denen auf ein [topic]-Token ein [nach]-Token folgt, was eine GPR ist, die ein optionales 'nach' ermöglicht. Offenbar darf nach einem Topic aber nur 'nach' stehen und keine GPR, was mir nicht bekannt war. Muss ich aber erstmal genauer testen, ob die Standarddefinitionen mit [text] [nach] geändert werden müssen.

Edit: Probier doch mal bitte folgende Testversion aus, in der ich die betreffenden zwei Zeilen geändert habe. Danke!

http://dl.dropbox.com/u/2691966/German_3-111015--TEST.i7x.zip

Mit der geänderten Version schaut das jetzt so aus:

Zitat:

darkred

Also ich nehme an, das war es tatsächlich! Den letzten Befehl interpretiert der Parser anders, aber Run Time Error gibts keinen mehr.

Ein Satzmuster für "schau ueber ..." gibt es nicht in GerX. Deshalb wird das Topic als "ueber element 2" verstanden und nicht als "element 2"

Wir haben das Satzmuster nicht definiert, weil "schau über etwas nach" eigentlich kein korrekter Imperativ ist. Wenn Du dieses Satzmuster dennoch verwenden möchtest, kannst du es natürlich nachträglich definieren:

blue

Ich werde noch weiter testen und so schnell wie möglich ein GerX-Update veröffentlichen. Schonmal vorab vielen Dank für das Aufspüren des Fehlers "GPR nach [text]-Token".

Grüße,

Christian

So. Ich habe jetzt mal alle in GerX vordefinierten Satzmuster, die die Aktion consulting it about triggern, getestet:

blue

Diese Tests haben noch ein paar murksige Konstruktionen zutage gefördert, die ich schon geändert habe.

Wer mag, kann die neuen Definitionen bis zum nächsten Update noch ein wenig auf die Probe stellen und uns mögliche Fehler bitte melden:

http://dl.dropbox.com/u/2691966/German_3-111016--TEST2.zip

Danke an Bushin fürs Aufspüren der Fehler!