Ich bin draufgekommen, dass in der neuen Library NIMM ALLES VON

und AUS DING nicht funktioniert.

Das liegt offenbar zunächst daran, dass 'von' und 'aus' als

OF?__WD definiert sind, und irgendwo in parserm.h eine Zeile Code

ist, die den Parser dazu bringt, OF?__WD 1-4 zu ignorieren, was

dazu führt, dass z.B.

NIMM ALLES VON PULT

als "nimm pult" verstanden wird.

Wenn man diesen Code auskommentiert (ich weiß nicht, wozu er

eigentlich gut ist, irgendwas mit NPCs, nehm ich an, aber da hab

ich noch keine), funktioniert NIMM ALLES AUS XXX, aber mit 'von'

geht's immer noch nicht, da bekommt man dann die Antwort:

"Keiner der Gegenstände hier will diesem Befehl Folge leisten!"

(Soll heißen, es ist nichts da, das man nehmen kann, was aber

nicht stimmt. Finde ich übrigens eine furchtbare Formulierung.)

Ich hab Stunden damit verbracht, in den Innereinen des Parsers

herumzuwühlen, aber ich hab nicht herausgefunden, warum 'von'

hier anders behandelt wird als 'aus'.

Zum Testen reicht es mir natürlich, dass ich 'nimm alles aus...'

schreiben kann, wäre aber trotzdem nett, wenn's auch so

funktionieren würde. Irgendeine Idee?

Sophie:

Wenn man diesen Code auskommentiert (ich weiß nicht, wozu er eigentlich gut ist, irgendwas mit NPCs, nehm ich an, aber da hab ich noch keine), ...

Der Code wird im Original dazu verwendet, um das "of" in Sätzen wie "get all of the pebbles" oder "drop three of the cubes" zu parsen - nach einem Descriptor (wenn die lokale Variable flag wahr ist) wird es einfach ignoriert.

Auf Deutsch sollte man das wohl etwas anders behandeln. In deinem ursprünglichen Satz ist "alles" der Descriptor, und das nachfolgende "von" wird überlesen. Pas "Pult" ist dann einfach der Name eines Objekts und das Satzmuster

    * noun -> Take

ist damit erfüllt.

Um diesen Satz eindeutig zu machen, könnte man mehrere Dinge versuchen:

• "alle"/"allen" und "alles" unterscheiden, so dass "alle" nur in Verbindung mit Substantiven ("alle Knöpfe"), "alles" aber nur allein stehend verwendet werden kann. Nach "alles" wäre das Token dann zu Ende.
• Die OF?WDs komplett ignorieren. Dann würde "nimm drei von den Steinen" nicht verstanden, "drei der Steine" und "drei Steine" aber schon (hoffe ich). Das Problem tritt bei "of" auf Englisch ja nicht auf, weil "es nur als OF?WD verwendet wird und nie als Präposition in Satzmustern auftritt.

Das erklärt dein Problem, dass 'aus' und 'von' unterschiedlich behandelt werden, allerdings noch nicht. Was sagt der Parser denn, wenn man das Tracing im Debug-Modus einschaltet? Werden "Nimm alles aus Pult" und "... von Pult" als verschiedene Sätze verstanden?

Okay, ich habe deinen Fall noch einmal mit meinem Jade-Beispiel nachgeprüft, und die Zeile in parserm.h, in der dir OF__WDs geskippt werden, auskommentiert. Dann funktioniert's mit 'aus' und mit 'von':

>nimm alles aus säule

Jadestatue: Entfernt.

>undo

Im Schrein

[Letzten Zug ungeschehen gemacht.]

>nimm alles von säule

Jadestatue: Entfernt.

>nimm alles von säule

Keiner der Gegenstände hier will diesem Befehl Folge leisten!

Ich dachte zunächst, dass es nicht funktioniert, aber nachdem ich die Säule abgeräumt hatte, war sie ja auch leer, und keiner der Gegenstände wollte meinem Befehl Folge leisten. Wenn etwas auf der Säule ist, greift der Befehl und macht das, was er soll, sowohl mit 'von' als auch mit 'aus'.

Sophie:

Finde ich übrigens eine furchtbare Formulierung.

Ich finde, dass der Satz nicht nur furchtbar klingt, sondern auch irreführend und wenig hilfreich ist.

Die *WDs könnte man auch einmal überarbeiten, denn obwohl 'but' 'aber' heißt, ist 'aber' kein BUTWD. Die Geschichte mit 'dann' und 'sodann' (!) finde ich auch unglücklich, denn man sagt auf Deutsch ja nicht "nimm die Lampe dann zünde sie an", sondern "nimm die Lampe und zünde sie dann an". Das ist natürlich schwer zu parsen, deshalb sollte man sich hier vielleicht auf den Punkt als THEN__WD beschränken.

Martin:

Okay, ich habe deinen Fall noch einmal mit meinem Jade-Beispiel nachgeprüft, und die Zeile in parserm.h, in der dir OF__WDs geskippt werden, auskommentiert. Dann funktioniert's mit 'aus' und mit 'von':

Ah, ich glaub ich hab eine Spur! Ich hab mir dein Jadebeispiel angeschaut, und mich zunächst sehr gewundert, weil es zu funktionieren scheint, aber:

In dem kleinen Schrein ist es dunkel, nur wenig Licht fällt durch das halb verfallene Dach. Ein großer Lichtstrahl fällt auf eine Steinsäule in der Mitte des Schreins.

Die Lichtung liegt im Süden.

>lass stein

Fallengelassen.

>nimm alles von podest

Keiner der Gegenstände hier will diesem Befehl Folge leisten!

>nimm alles aus podest

Entfernt.```

Es liegt also wohl daran, dass noch andere Dinge in scope sind, die man meinen könnte. Ich hab aber keine Ahnung, woher der Parser die Information nimmt, dass 'von' was Besonderes sein könnte. Ich glaub ich hab mir alle Stellen angeschaut, wo das Wort vorkommt.

Die Spur ist gut! Das Token schlägt auch nicht dort fehl, wo wir es vermuten. Hier deine Situation mit Trace-Level zwei. (Alle Tokens außer)

  * multiinside 'von'/'aus' noun        -> Remove    ! line 3

  * multiinside 'von'/'aus' noun heraus -> Remove    ! line 4

herausgeschnitten.)

>nimm alles von podest

[ "nimm" nimm / "alles" alles / "von" von / "podest" podest ]

[Parsing for the verb 'nimm' (8 lines)]

[...]

[line 3 * multiinside 'von' / 'aus' noun -> Remove]

 [Trying look-ahead]

 [line 3 token 1 word 2 : multiinside]

 [line 3 token 2 word 3 : 'von']

 [line 3 token 3 word 4 : 'aus']

 [line 3 token 4 word 4 : noun]

 [line 3 token 5 word 5 : END]

[line 4 * multiinside 'von' / 'aus' noun Routine(21629) -> Remove]

 [Trying look-ahead]

 [line 4 token 1 word 2 : multiinside]

 [line 4 token 2 word 3 : 'von']

 [line 4 token 3 word 4 : 'aus']

 [line 4 token 4 word 4 : noun]

 [line 4 token 5 word 5 : Routine(21629)]

 [line 4 token 6 word 6 : END]

[...]

Keiner der Gegenstände hier will diesem Befehl Folge leisten!

>nimm alles aus podest

[...]

[line 3 * multiinside 'von' / 'aus' noun -> Remove]

 [Trying look-ahead]

 [Advanced to "noun" token: error 1]

 [line 3 token 1 word 2 : multiinside]

 [line 3 token 2 word 3 : 'von']

 [line 3 token 3 word 4 : 'aus']

 [line 3 token 4 word 4 : noun]

 [line 3 token 5 word 5 : END]

[line 4 * multiinside 'von' / 'aus' noun Routine(21629) -> Remove]

 [Trying look-ahead]

 [Advanced to "noun" token: die Steinsäule]

 [line 4 token 1 word 2 : multiinside]

 [line 4 token 2 word 3 : 'von']

 [line 4 token 3 word 4 : 'aus']

 [line 4 token 4 word 4 : noun]

 [line 4 token 5 word 5 : Routine(21629)]

 [line 4 token 6 word 6 : END]

[Line successfully parsed]

Entfernt.

Das Satzmuster aus der Zeile 3 ist gar nicht das, was herangezogen wird, sondern das aus Zeile vier.

Komplett verstanden habe ich noch nicht, was der Parser macht, aber nach einigen Durchgängen mit Trace Level sechs habe ich einige Erkenntnisse gewonnen. (Nicht, dass mich das in unserem Problem weitergebracht hätte.)

Wenn der Parser als erstes Ergebnistoken, also ein Token, das einen Wert in noun oder second ablegt, eines der Tokens [multiinside] oder [multiexcept] findet, macht er einen so genannten Look-Ahead: Er versucht, das zweite Ergebnistoken zuerst zu parsen, da die gültigen Objekte des ersten Tokens vom zweiten abhängen, und da der Inform-Parser nie eine rein grammatische Analyse macht, sondern die Gültigkeit der Objekte bereits mit überprüft. (So werden bei einem [noun]-Token nur die names und parse_names der sichtbaren Objekte betrachtet.)

Damit er das zweite Token finden kann, muss dessen Anfang klar sein. Es kann nur nach einer Präposition stehen, alles nach dieser Präposition wird dann geprüft und für second in Betracht gezogen. Das geht in unserem Fall, da 'von' oder 'aus' vor den zweiten Token stehen. Bei Sätzen wie "gib Hund alten Knochen" ginge das nicht, da der Parser nicht wissen kann, wo das erste Token aufhört und das zweite anfängt, ohne das erste Token zu parsen.

Dann kehrt die Analyse an den ursprünglichen Punkt zurück. Wenn second erfolgreich und eindeutig bestimmt wurde, werden nur Sachen die Kinder von second sind für noun in Betracht gezogen. Ansonsten wird einfach so geparst, als ob es ein [multi]-Token wäre. Welche Objekte für [multiinside] gültig sind, wird dann im Nachhinein bestimmt.

Beide Male, also bei 'von' und 'auf', wird ein Look-Ahead ab Wort vier durchgeführt. Aber nur bei 'auf' wird die Steinsäule gefunden. Bei 'von' schlägt der Look-Ahead fehl. Das Parsen von 'alles' resultiert in einer Liste von vier Objekten. Diese Objekte werden bewertet, und aufgrund der Best-Guess-Strategie, die ja ohne die Zusatzinformation der Steinsäule auskommen muss, wird nur der Stein, der am Boden liegt, behalten. Wenn nach der Satzanalyse aus dieser Liste die Objekte herausgesucht werden sollen, die auf [multiinside] für die (dann bekannte) Säule passen, findet der Parser nichts, da der Stein nicht in der Säule ist.

Bei 'aus' wird die Säule im Look-Ahead gefunden, aber im Token aus der Zeile 3 wird es herausgefiltert, weil sie das Attribut 26 (worn? workflag?) nicht hat. Wieso hier nach worn gefiltert wird, ist mir schleierhaft, das sieht mir nach einem Fehler aus. Die vierte Zeile findet das Satzmuster dann aber. Die Routine heraus verlangt nach einem 'heraus'-Wort und ist im Gegensatz zu xheraus kein Ergebnistoken. Eigenartigerweise wird aber auch ein leeres Wort an Satzende als GPR_PREPOSITION gewertet, und so wird, wenn auch nicht so wie gewollt, der Satz verstanden.

Wieso schlägt der Look-Ahead nach 'von' fehl, nach 'aus' aber nicht, obwohl er dieselbe Wortkette ('podest') unter denselben Bedingungen prüft? Ich weiß es nicht, aber ich habe eine Vermutung: Wenn man die Reihenfolge der Präpositionen umdreht, also statt 'von'/'aus' 'aus'/'von' angibt, dreht sich das Verhalten um. Dann geht es mit 'von', aber nicht mehr mit 'auf'. (Ein Aufteilen der Satzmuster in zwei, um die Alternative mit Schrägstrich zu umgehen, bringt übrigens nichts.) Das lässt mich vermuten, dass irgendwelche Variablen, die der Parser für seine Überprüfung braucht nicht richtig initialisiert oder zurückgesetzt werden und so das, was eigentlich unter gleichen Bedingungen laufen soll, unter verschiedenen Voraussetzungen abläuft.

Wieso wird hier überhaupt nach Attributen gefiltert und wieso wird die Liste für [multiinside] schon im Voraus beschnitten, ohne dass der Parser weiß, was second ist? Das Token würde ja auch ohne Look-Ahead funktionieren, wenn nicht schon sofort die Best-Guess-Methode angewandt würde. Dann würden alle sichtbaren Objekte auf ein temporäres Feld geschrieben, und aus dem konnte sich der Parser dann hinterher die gesuchten Objekte hgerauspicken.

Tja, einiges verstanden, mehr Sachen aufgedeckt, die ich nicht verstehe. Und immer noch keine Lösung für das Problem. :-(

Okay, also Erklärung hab ich keine, aber es sieht so aus, als würde

es funktionieren, wenn man bei allen Zeilen, wo multiinside vorkommt, die Präpositionen auf einzelne Zeilen schreibt, und bei 'nimm' die

Zeile worn 'ab' -> Disrobe nach die multiinside*-Zeilen stellt.

Sophie:

Okay, also Erklärung hab ich keine, aber es sieht so aus, als würde es funktionieren, wenn man bei allen Zeilen, wo multiinside vorkommt, die Präpositionen auf einzelne Zeilen schreibt, ...

In der englischen Lib wird das für 'take' auch gemacht (für andere [multiinside]-Tokens aber nicht). Das sollte man vielleicht in der Standard-Lib abändern.

Sophie:

... und bei 'nimm' die Zeile * worn 'ab' -> Disrobe nach die multiinside-Zeilen stellt.

Aha, da kam also das 'worn' her, das herausgefiltert wurde. Die [worn]-Zeile hinter die [multiinside]-Zeilen zu stellen ist ein guter Workaround. Damit die Lib auch mit 'extend first' erweiterbar ist, kann man stattdessen in parserm.h in Zeile 1556 token_filter = 0; einfügen:

    if ((line_ttype-->pcount == ELEMENTARY_TT)

        && (line_tdata-->pcount == NOUN_TOKEN))

    {

        !  Advance past the last preposition

        token_filter = 0; !*neu*

        while (wn <= num_words) ...

Ich verstehe nicht ganz, warum der Filter nicht zurückgesetzt wird, aber da der Look-Ahead nur für das Schema * [multiinside] 'prep' [noun] funktioniert, und der Filter für [noun] und [multiinside] immer null ist, kann man den Filter wohl hier zurücksetzen ohne Schaden anzurichten.

Allerdings wird hier nicht der Name des Objekts angezeigt:

Entfernt.

Das sollte bei 'alles' schon gemacht werden, auch wenn es nur ein Objekt gibt, oder? Naja, nicht so wichtig. Viel Schlimmer ist, dass mein Jade-Beispiel zwar ##Take, aber nicht ##Remove abfängt. Typischer Inform-Anfänger-Fehler, das.

Martin:

Sophie:

Okay, also Erklärung hab ich keine, aber es sieht so aus, als würde es funktionieren, wenn man bei allen Zeilen, wo multiinside vorkommt, die Präpositionen auf einzelne Zeilen schreibt, ...

In der englischen Lib wird das für 'take' auch gemacht (für andere [multiinside]-Tokens aber nicht).

In der englischen Lib kommt multiinside nur 4 mal vor, und nie mit 'bla'/'bla'. Bei anderen multi... tokens scheint es kein Problem zu geben, jedenfalls nicht, wenn man nicht genau schaut.

Martin:

[...] Damit die Lib auch mit 'extend first' erweiterbar ist, kann man stattdessen in parserm.h in Zeile 1556 token_filter = 0; einfügen [...]

Ich verstehe nicht ganz, warum der Filter nicht zurückgesetzt wird...

Das ist interessant. Ich werd es mir bei Gelegenheit noch einmal anschauen, aber jetzt hab ich gerade gar keine Zeit.

Martin:

Allerdings wird hier nicht der Name des Objekts angezeigt:

Entfernt.

Das sollte bei 'alles' schon gemacht werden, auch wenn es nur ein Objekt gibt, oder?

Naja, normalerweise müsste ich wissen, was dort ist. Ich glaub, dass die einzelnen Dinge genannt werden, ist eher dann sinnvoll, wenn das Nehmen nicht klappt, oder irgendwas Besonderes passiert. Wenn nur ein Ding da ist, weißt du ja, um welches es geht.

Danke jedenfalls für die Mühe und die ausführlichen Erklärungen.