| Autor |
Nachricht |
| < Problem bei Antwort auf "Was meinst du, den....." |
|
 Verfasst am:
Mo, 10 Jan 2005 - 13:03
|
|
|
Kompassleser
Anmeldungsdatum: 21.02.2004
Beiträge: 198
Wohnort: Rheinmain
|
|
Hallo,
ich habe ein Problem wenn ein Objekt nicht eindeutig gefiltert werden konnte und die Frage "Was meinst du, ...." erscheint. Allerdings nur dann, wenn es sich um eine parsename-Angelenheit handelt.
Hier mal der Code (gekürzt):
| Code: | Object Eingang11 "Eingang" Testlabor
with post "11",
parse_name [q;
q = wn;
if (nextword() == 'eingang' && nextword() ~= '11') return 1;
wn = q;
if (nextword() == '11') return 1;
wn = q;
if (nextword() == 'eingang' && nextword() == '11') return 2;
wn = q;
return -1;
],
description "Eingang 11 ist rund.",
...
Object Eingang22 "Eingang" Testlabor
with post "22",
parse_name [q;
q = wn;
if (nextword() == 'eingang' && nextword() ~= '22') return 1;
wn = q;
if (nextword() == '22') return 1;
wn = q;
if (nextword() == 'eingang' && nextword() == '22') return 2;
wn = q;
return -1;
],
description "Eingang 22 ist dreieckig.",
... |
Und das passiert:
>x eingang
Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: 11
Eingang 11 ist rund.
>x eingang
Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: 22
Du kannst nichts dergleichen sehen.
Das Problem scheint zu sein, dass er nur für das erste Objekt eine genaue Spezifikation zuläßt und das zweite schon gar nicht mehr erreicht bzw. die Variable wn auf das falsch Wort verweist?
Und es kommt noch mehr:
>x eingang
Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: eingang 11
Ich habe dich nur soweit verstanden: betrachte den Eingang 11.
Das macht nun gar kein Sinn mehr für mich.
Kann es sein, dass es Probleme mit dem return-Wert aus der parsename Routine bei dieser Frage gibt?
Gruß
Kris |
|
|
|
 |
|
| Verfasst am:
Mo, 10 Jan 2005 - 22:06
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
Ich hab mal versucht, in der Library herauszufinden, was genau mit den return-Werten passiert. Leider blicke ich nicht mal ansatzweise, was da tatsächlich intern abläuft.
Was mir aber aufgefallen ist: Die Befehle, die du oben angegeben hast, funktionieren sämtlichst einwandfrei, wenn du jeden return-Wert in deinem Beispielcode um 1 erhöhst.
Warum das so ist? Keine Ahnung. Da der return-Wert ja eigentlich die Anzahl der erkannten Worte zurückgeben soll, könnte ich mir vorstellen, dass meine vorgeschlagene Änderung bei komplizierteren Eingaben ungeahnte Nebenwirkungen haben kann. Das sollte also auf alle Fälle intensiv getestet werden. :)
_________________
"Ein Musiker! Was will der hier so spät?" Stolzing (Meistersinger v.N.) |
|
|
|
|
|
| Verfasst am:
Mo, 10 Jan 2005 - 22:25
|
|
|
Kompassleser
Anmeldungsdatum: 21.02.2004
Beiträge: 198
Wohnort: Rheinmain
|
|
| ChrisW hat folgendes geschrieben: | | Das sollte also auf alle Fälle intensiv getestet werden. :) |
Genau :-)
Danke erstmal für deine Versuche. Ich habe auch nicht wirklich durchgeblickt. Zuviele unkommentierte Variablen usw...
Ich werde als Workaround einfach ein Objekt (in diesem Fall wäre es "Eingang") implementieren, dass eben nur auf 'eingang' hört (bei den anderen Objekten *nur* Eingang *nicht* akzeptieren) und mit before darauf hinweisen, sich speziell auf den einen oder anderen zu beziehen. Nicht das feinste, aber von den Möglichkeiten die am wenigsten verwirrende für den Spieler.
Gruß
Kris |
|
|
|
|
|
| Verfasst am:
Mo, 10 Jan 2005 - 23:28
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
Naja, du erkennst in deiner parse_name die Möglichkeiten "Eingang x" und "x". Wenn der Spieler ein Objekt auf eine Frage hin präzisiert, wird diese Eingabe vor dem mehrdeutigen Objekt eingefügt und der ganze Sums wird nochmal geparst. Das funktioniert ganz gut, da die Wörter, die zur Disambiguisierung beitragen, eh meist Adjektive oder Attribute sind, die im Englischen (und 2017 wohl auch im Deutschen) als einzelnes Wort vorangestellt sind sind (und uns lustige Objekte wie "small/rusty/flat brass/aluminium/copper/pewter keys bescheren) und da Inform eigentlich nicht zwischen Adjektiven unterscheidet und auch "key brass brass brass small" als "small brass key" versteht und sich sogar damit brüstet.
Daher also die profane Lösung:
| Code: |
Object Eingang11 "Eingang" Testlabor
with post "11",
dekl 1,
name 'eingang' '11',
description "Eingang 11 ist rund.",
has door static male;
Object Eingang22 "Eingang" Testlabor
with post "22",
dekl 1,
name 'eingang' '22',
description "Eingang 22 ist dreieckig.",
has door static male;
|
Das funktioniert ganz gut. Bei einstelligen Zahlen bitte die Notation '1//', '2//' usw. verwenden. Selbst, wenn ich einen Eingang 2 habe und dann im selben Raum 'nimm 2 Streichhölzer' sage, funktioniert alles wie es soll.
Folgende Variante erzwingt die Angabe der Zimmernummer im parse_name und borgt sich nebenbei das Vokabular für die Eingänge bei einem Deko-Objekt, das nur dazu da ist, dem Spieler zu sagen, dass er konkrete Dinge mit immer nur genau einer Tür machen kann.
| Code: |
Class Eingang
with number,
dekl 1,
short_name "Eingang",
post [; print " ", self.number; ],
description [;
"Die Nummer ", self.number, " steht auf dem Eingang.";
],
parse_name [number_found n w;
w = NextWord();
while (true) {
if (number_found == false && self.number
&& Trynumber(wn - 1)==self.number)
number_found = true;
else if (WordInProperty(w, zu_vage, name)==false) {
if (number_found) return n;
return -1;
}
n++;
w = nextWord();
}
],
before [x;
Enter: if (self provides dest) {
x = self.dest();
if (x ofclass Object) playerTo(x);
return x;
}
"Der Eingang ist magisch versperrt!";
],
has static male door scenery;
Eingang e11 Testlabor with number 11, dest "Yuck!";
Eingang e12 Testlabor with number 12, dest Nebenan;
Eingang e13 Testlabor with number 13;
Object Zu_vage Testlabor
with dekl 1,
short_name "Eingang",
name 'eingang' 'tuer' 'nummer',
description "Die Eingänge sind nummeriert von 11 bis 13",
before [;
Examine:
default: "Bitte sage genau, welchen Eingang du meinst.";
],
initial "Hier sind verschiedene Eingänge, die von 11 bis 13
durchnummeriert sind.",
has male static;
|
Und es gibt noch die Schließfach-Variante, bei der fast 10000 Eingänge als ein Objekt implementiert werden:
| Code: |
Object Eingang "Eingang" Testlabor
with dekl 1,
number_found,
number_needed 2567,
post [;
if (self.number_found) print " Nummer ",
self.number_found;
],
name 'eingang' 'tuer' 'nummer',
description [;
if (self.number_found==0)
"Die Eingänge sind nummeriert von 1 bis 9999";
"An Eingang ", self.number_found, " prangt eine
goldene ", self.number_found, ".";
],
before [nf;
nf = self.number_found;
if (nf < 0 || nf > 9999)
"Die Türen haben Nummern von 1 (eins) bis 9999
(neuntausendneunhundertundneunundneunzig).";
Enter: if (nf==0) "Du gehst wahllos durch eine der
Türen, die in eine Mehrzweckhalle führt.";
if (nf ~= self.number_needed)
"Tür Nummer ", nf, " führt zu einer
Mehrzweckhalle.";
deadflag = 2;
"Hinter dieser Tür erwartet dich Fatima, die
Perle des Orients. (Lechz!)";
],
parse_name [nf n w;
self.number_found = 0;
w = NextWord();
while (true) {
nf = Trynumber(wn - 1);
if (nf && self.number_found == false && nf ~= -1000)
self.number_found = nf;
else if (WordInProperty(w, self, name)==false)
return n;
n++;
w = nextWord();
}
],
each_turn [; self.number_found = 0 ; ],
has male static scenery door;
|
Wenn dir parse_name gefällt, interessiert dich vielleicht dieser Link zu Zarfs Parse-Name-Variationen..
_________________
Every silver lining has a cloud. |
|
|
|
|
|
| Verfasst am:
Di, 11 Jan 2005 - 8:42
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
Wow. Wenn wir Martin nicht hätten.
Was mich persönlich jetzt verwirrt, ist der Quellcode der Standard-parse_name der Library von Andrew Plotkins Seite:
| Code: | parser_name [wd num;
wd = NextWord();
while (WordInProperty(wd, self, name)) {
num++;
wd = NextWord();
}
return num;] |
Eigentlich dürfte sie keine anderen return-Werte liefern als Kris' Version. Der einzige Unterschied ist, dass sie sämtliche Wortreihenfolgen zulässt, was Kris' Version nicht tut. Dass sich das derart auswirkt, dass selbst bei korrekt eingegebener Wortreihenfolge bei Kris' Version nichts mehr läuft wie es soll, find ich schon krass.
_________________
"Ein Musiker! Was will der hier so spät?" Stolzing (Meistersinger v.N.) |
|
|
|
|
|
| Verfasst am:
Di, 11 Jan 2005 - 9:55
|
|
|
Kompassleser
Anmeldungsdatum: 21.02.2004
Beiträge: 198
Wohnort: Rheinmain
|
|
Tja,
vielen Dank erstmal!
Beim nächsten mal werde ich das von Anfang an so angehen, ich möchte jetzt nur nicht die Objekte alle umbasteln und am Ende werde ich doch nicht bis April fertig ;-).
| Martin hat folgendes geschrieben: | | Wenn dir parse_name gefällt, interessiert dich vielleicht dieser Link zu Zarfs Parse-Name-Variationen.. |
Naja, "im richtigen Leben" geht es hierbei um Busse. Und ich wollte natürlich auch die Möglichkeit
>UNTERSUCHE BUS NACH BIEBRICH
zulassen. Damit es keine Probleme mit "NACH" gibt, war ich natürlich dazu gezwungen.
Meine jetzige Lösung:
Ich habe die Möglichkeit, nur 'bus' zu erkennen, aus den Objekten genommen und eine Hilfobjekt, das auf 'bus' und 'busse' reagiert implementiert (eben nur >UNTERSUCHE zuläßt und alles andere mit der Bitte um konkrete Auswahl des Busses unterbricht).
| ChrisW hat folgendes geschrieben: | | Wow. Wenn wir Martin nicht hätten. |
Das dachte ich auch, als ich den Code gesehen habe :-)
Vorm nächsten mal werde ich mir aber Zarfs Seiten dazu mal genauer anschauen.
Vielen Dank!
Kris |
|
|
|
|
|
| Verfasst am:
Di, 11 Jan 2005 - 16:29
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
| ChrisW hat folgendes geschrieben: | | Eigentlich dürfte sie keine anderen return-Werte liefern als Kris' Version. Der einzige Unterschied ist, dass sie sämtliche Wortreihenfolgen zulässt, was Kris' Version nicht tut. Dass sich das derart auswirkt, dass selbst bei korrekt eingegebener Wortreihenfolge bei Kris' Version nichts mehr läuft wie es soll, find ich schon krass. |
Naja, die normale Vorgehensweise der Inform-Lib ist halt, so lange Wörter aus der name-Property einzulesen, wie es geht. Das Objekt, das die meisten Wörter aus dem Input eingesaugt hat, gewinnt (longest match). (Ich nehme mal an, dass dies bei der deutschen Lib auch so ist.)
Das geht ja auch meistens gut, denn nach einem Objekt steht typischerweise das Satzende oder eine Präposition. Und selbst, wenn zwei Objekte direkt aufeinander folgen ("Gib grünem Papagei Keks") kann man trennen, da sich das Vokabular unterscheidet oder der Spieler einen Artikel vor das zweite Objekt gesetzt hat. (Obwohl ich mir hier nicht ganz sicher bin - benutzt die Inform-Lib die Artikel zur Analyse oder filtert sie sie einfach raus und überliest sie?) Natürlich können Sätze wie "gib altem Hund alten Knochen" Probleme machen, wenn es mehrere Knochen gibt, darunter einen alten: Die Phrase "altem Hund alten" wird einfach dem Hund zugesprochen, so dass für den Knochen nur "Knochen" übrigbleibt, was zum Disambiguisieren zuwenig ist. Ein anderes Problem ist das im Handbuch beschriebene "put fly in amber in hole".
Kris' parse_name lässt nur die beiden Möglichkeiten "Eingang 11" und "11" zu. Das ist normalerweise in Ordnung, denn so würde man ja die Eingänge ansprechen. Wenn der Parser nachfragt, sieht es aber anders aus:
| Erster Fall hat folgendes geschrieben: | >x eingang
Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: 22
Du kannst nichts dergleichen sehen. |
Hier lautet der zu analysierende Satz nach Einfügen der Antwort "x 22 eingang", und das passt auf kein Objekt, man kann also nichts dergleichen sehen. (Wieso das oben mit 11 geklappt hat, erklärt das aber nicht. Rätselhaft, das.)
| Zweiter Fall hat folgendes geschrieben: | >x eingang
Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: eingang 11
Ich habe dich nur soweit verstanden: betrachte den Eingang 11. |
Hier wird "x eingang 11 eingang" überprüft: "x" heißt "betrachte", "Eingang 11" (und nur diese beiden Wörter) sind der Eingang als noun, und dann kommt noch ein "eingang", mit dem der Parser nichts anfangen kann, was er auch in der uns unverständlichen, aber aus Sichtweise des Parsers einleuchtenden Fehlermeldung mitteilt.
Um Disambiguisierungsfragen vernünftig zu behandeln, sollte man also in Inform nicht strike Wortmuster wie "Eingang 11" oder "Bus nach Cochabamba" eingeben, sondern vielleicht eher die zweite Variante von Andrew Plotkins Seite verwenden, die ein Wort erzwingt, aber ansonsten genau wie der Inform-Parser arbeitet.
_________________
Every silver lining has a cloud. |
|
|
|
|
|
| Verfasst am:
Di, 11 Jan 2005 - 16:53
|
|
|
Kompassleser
Anmeldungsdatum: 21.02.2004
Beiträge: 198
Wohnort: Rheinmain
|
|
| Martin hat folgendes geschrieben: | | (Obwohl ich mir hier nicht ganz sicher bin - benutzt die Inform-Lib die Artikel zur Analyse oder filtert sie sie einfach raus und überliest sie?) |
In DM4 § 33 steht zur Disambiguation:
(3) Objects which don't fit "descriptors'' used by the player are removed:
if "my'', an object whose parent isn't the actor is discarded;
if "that'', an object whose parent isn't the actor's location is discarded;
if "lit'', an object which hasn't light is discarded;
if "unlit'', an object which has light is discarded;
if "his'' or some similar possessive pronoun, an object not owned by the
person implied is discarded.
Thus "his lit torches'' will invoke two of these rules at once.
Beim Prüfen, welches Objekt noch "im Topf bleibt", wird also der Artikel zu Rate gezogen. Ob es allerdings auch automatisch zur Erkennung diehnt, dass ein neues Objekt folgt, kann ich nicht sagen.
Gruß
Kris |
|
|
|
|
|
| Verfasst am:
Di, 11 Jan 2005 - 17:54
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
| Kris hat folgendes geschrieben: | | Beim Prüfen, welches Objekt noch "im Topf bleibt", wird also der Artikel zu Rate gezogen. Ob es allerdings auch automatisch zur Erkennung diehnt, dass ein neues Objekt folgt, kann ich nicht sagen. |
Das sind ja alles keine Artikel. Ich meinte, ob "the" eventuell vor der Analyse herausgefilter wird, also "Gib dem Mann das Brot" als "Gib Mann Brot" beim Parser ankommt. Ich glaube nicht, denn zumindest wird zwischen "the" und "a", also bestimmtem (für den definite mode) und unbestimmtem Artikel unterschieden.
Die descriptors dienen ganz klar der Abgrenzung von Objekten, da sie nur am Anfang der noun phrase stehen können. Abschnitt 34 des DM4 beschreibt die Artikel als mögliche descriptors, sie müssten also ebenso wie die von dir oben erwähnten Possesiv- und Demonstrativpronomen und vorangestellte Nummern (demanding numbers, "12 Lebkuchenherzchen") zur Trennung von Objekten beitragen. Es sei denn, sie gehören zum Vokabular des ersten Objekts.
Kurzer Test:
| Code: |
>u bogen
Dein Bogen aus Eibenholz, bespannt mit einer Sehne aus Flachs.
>u den das des dem bogen
Dein Bogen aus Eibenholz, bespannt mit einer Sehne aus Flachs.
>u den das des dem bogen den
Wahrscheinlich meinst du: ue den Bogen.
>u diesen jenen bogen
Dein Bogen aus Eibenholz, bespannt mit einer Sehne aus Flachs.
>u den bogen den bogen
Wahrscheinlich meinst du: ue den Bogen.
>u jenen einen den bogen
Dein Bogen aus Eibenholz, bespannt mit einer Sehne aus Flachs.
|
Die Artikel können also nicht zwischen die anderen Vokabeln eines Objekts gemischt werden, sondern müssen vorn stehen, wo sie hingehören. Ignoriert werden sie nicht.
_________________
Every silver lining has a cloud. |
|
|
|
|
|
| Verfasst am:
Di, 11 Jan 2005 - 20:35
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
| Martin hat folgendes geschrieben: | | (Wieso das oben mit 11 geklappt hat, erklärt das aber nicht. Rätselhaft, das.) |
Okay, hab mal beide parse_name-Varianten so erweitert, dass sie ausgeben, was sie weiterreichen und für welche erkannten Worte sie dies tun.
| WinFrotz hat folgendes geschrieben: | >u eingang
[Eingang11.parse_name - 'eingang' -> return 1]
[Eingang12.parse_name - 'eingang' -> return 1] |
Das stimmt immer überein. Weiter gehts mit der Inform-Standardvariante (von Andrews Seite):
| WinFrotz hat folgendes geschrieben: | Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: eingang 11
[Eingang11.parse_name - 'eingang' '11' 'eingang' -> return 3]
[Eingang12.parse_name - 'eingang' -> return 1]
Eingang 11 ist rund.
...
Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: 22
[Eingang11.parse_name - -> return 0]
[Eingang12.parse_name - '22' 'eingang' -> return 2]
Eingang 22 ist dreieckig.
|
Soweit alles klar.
Bei Kris' Variante hab ich ihn noch wn, also die Position des ersten weitergegebenen Wortes ausgeben lassen, in der Hoffnung, dass dann klarer wird, was der Parser da eigentlich tut.
| WinFrotz hat folgendes geschrieben: | Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: 11
[Eingang11.parse_name - wn 2 - '11' -> return 1]
[Eingang22.parse_name - wn 2 - -> return -1]
[Eingang11.parse_name - wn 3 - 'eingang' -> return 1]
[Eingang11.parse_name - wn 2 - '11' -> return 1]
[Eingang22.parse_name - wn 2 - -> return -1]
Eingang 11 ist rund. |
Hier eigentlich ein Wunder, dass das klappt. Er schafft es tatsächlich, aus "x 11 eingang" auf Eingang11 zu kommen, offenbar weil die Eingang22.parse_name hier wirklich überhaupt nichts erkennt.
| WinFrotz hat folgendes geschrieben: | Deine Antwort: eingang 11
[Eingang11.parse_name - wn 2 - 'eingang' '11' -> return 2]
[Eingang22.parse_name - wn 2 - 'eingang' -> return 1]
[Eingang11.parse_name - wn 2 - 'eingang' '11' -> return 2]
[Eingang22.parse_name - wn 2 - 'eingang' -> return 1]
Ich habe dich nur soweit verstanden: ue den Eingang 11.
...
Deine Antwort: 22
[Eingang11.parse_name - wn 2 - -> return -1]
[Eingang22.parse_name - wn 2 - '22' -> return 1]
[Eingang11.parse_name - wn 3 - 'eingang' -> return 1]
[Eingang11.parse_name - wn 2 - -> return -1]
[Eingang22.parse_name - wn 3 - 'eingang' -> return 1]
[Eingang22.parse_name - wn 2 - '22' -> return 1]
Du kannst nichts dergleichen sehen. |
Das lass ich jetzt mal unkommentiert so stehen....
_________________
"Ein Musiker! Was will der hier so spät?" Stolzing (Meistersinger v.N.) |
|
|
|
|
|
| Verfasst am:
Mi, 12 Jan 2005 - 10:46
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
| ChrisW hat folgendes geschrieben: | | Okay, hab mal beide parse_name-Varianten so erweitert, dass sie ausgeben, was sie weiterreichen und für welche erkannten Worte sie dies tun. |
Hehe, die Nachforschungen ziehen Kreise. Wir kriegen die Lib schon demontiert. (Ob wir sie verstehen, bleibt allerdings fraglich.)
Eigenartig. Wieso wird denn parse_name so oft aufgerufen? Vor allem, wo doch nach dem ersten Durchgang klar ist, ob ein Objekt und wenn ja welches gefunden wurde? (Ein Aufruf mit ##TheSame als action um herauszufinden, ob die gefundenen Objekte identisch sind, kann wohl ausgeschlossen werden, oder?)
Ein Verdacht beschleicht mich, schnell in germang.h nachgeschaut:
| Code: |
Verb 'untersuch' 'x//' 'b//' 'u//' 'betracht' 'beschreib' 'check' 'begutacht'
* -> Look
* noun -> Examine
* multiexcept -> Examine;
|
Dass 'untersuche' allein eine Raumbeschreibung auslöst, soll hier mal nicht weiter untersucht werden. Aber wieso gibt es zwei Satzmuster für 'u' bzw. 'x'? Selbst, wenn man mehrere Objekte beim Untersuchen zulassen möchte - die englische Original-Lib tut dies nicht, TADS 2 (in manchen Fällen zumindest, sofern ich mich recht erinnere) schon - sind die beiden Zeilen redundant, etwas wie
| Code: | Verb 'untersuch' 'x//' 'b//' 'u//' 'betracht'
* -> Look
* multi -> Examine;
|
reicht vollkommen aus. Und [multiexcept] ist sowieso falsch, da es nur ein Objekt-Token auf dieser Zeile gibt, das zweite Objekt, das ausgeschlossen werden soll, also fehlt.
Probe aufs Exempel:
| Zitat: | "Bleib in der Nähe, Sohn", sagst du, "sonst wirst du dich in diesem Gewühl noch verlaufen."
>i
Du trägst:
einen Köcher (angezogen)
drei Pfeile
einen Bogen
>u bogen und köcher
Bogen: Dein Bogen aus Eibenholz, bespannt mit einer Sehne aus Flachs.
Köcher: Der Köcher aus Ziegenhaut hängt gewöhnlich über deiner linken Schulter.
>u alles
Bogen: Dein Bogen aus Eibenholz, bespannt mit einer Sehne aus Flachs.
>u köcher, pfeile, bogen und meinen sohn
Köcher: Der Köcher aus Ziegenhaut hängt gewöhnlich über deiner linken Schulter.
Pfeil: Wie alle deine Pfeile - spitz und zuverlässig.
Bogen: Dein Bogen aus Eibenholz, bespannt mit einer Sehne aus Flachs.
Walter: Ein ruhiger blonder Junge, der in acht Sommern schon viel gelernt hat, was man für ein Leben in den Bergen benötigt.
|
Ich nehme mal an, dass der magere Output von 'alles' hier auf [multiexcept] zurückzuführen ist und dass [multi] hier alles nicht concealte untersuchen würde.
Gegenprobe auf Englisch:
| Zitat: | >x book, door and me
You can't use multiple objects with that verb.
|
Naja, ich denke mal, dass wir bei unseren Tests oben 'untersuche' statt 'nimm' benutzt haben, um das Problem des Mehrfachparsens auszuschließen. Wie sähe der Fall den bei, hmm, 'betritt' aus?
_________________
Every silver lining has a cloud. |
|
|
|
|
|
| Verfasst am:
Mi, 12 Jan 2005 - 12:32
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
Schnell mal zusammengebaut. Ohne die parse_name funktioniert alles, wie es soll. Mit Kris' parse_name:
| Zitat: | >betritt eingang 11
[Eingang11.parse_name - wn 2 - 'eingang' '11' -> return 2]
[Eingang22.parse_name - wn 2 - 'eingang' -> return 1]
Du betrittst Doktor Kleiners geheimes unterirdisches Labor durch den runden Eingang. |
| Zitat: | >betritt eingang
[Eingang11.parse_name - wn 2 - 'eingang' -> return 1]
[Eingang22.parse_name - wn 2 - 'eingang' -> return 1]
Was meinst du, den Eingang 11 oder den Eingang 22?
Deine Antwort: 22
[Eingang11.parse_name - wn 2 - -> return -1]
[Eingang22.parse_name - wn 2 - '22' -> return 1]
Ich habe dich nur soweit verstanden: betritte den Eingang 22.
...
Deine Antwort: eingang 11
[Eingang11.parse_name - wn 2 - 'eingang' '11' -> return 2]
[Eingang22.parse_name - wn 2 - 'eingang' -> return 1]
Ich habe dich nur soweit verstanden: betritte den Eingang 11.
...
Deine Antwort: eingang 22
[Eingang11.parse_name - wn 2 - 'eingang' -> return 1]
[Eingang22.parse_name - wn 2 - 'eingang' '22' -> return 2]
Ich habe dich nur soweit verstanden: betritte den Eingang 22. |
Hier klappte zwar nichts, aber die Library verhält sich korrekt. Schließlich erkennt keine der parse-names den kompletten Rest des Satzes, es bleibt immer ein Wort übrig. Das darf laut...
| Code: | Verb 'durchquer' 'betret' 'betritt'
* -> GoIn
* noun -> Enter; |
...aber nicht passieren.
edit: Auch die Variante...
| Zitat: | Deine Antwort: 11
[Eingang11.parse_name - wn 2 - '11' -> return 1]
[Eingang22.parse_name - wn 2 - -> return -1]
Ich habe dich nur soweit verstanden: betritte den Eingang 11. |
...funktioniert hier erwartungsgemäß nicht.
Ein gutes Beispiel auch dafür, dass man das weggekürzte End-E vielleicht nicht auf Teufel-komm-raus wieder anhängen sollte. Mit "betret", "untersuch" usw. ohne das End-E kann man zur Not leben, aber was ist denn "betritte".
_________________
"Ein Musiker! Was will der hier so spät?" Stolzing (Meistersinger v.N.) |
|
|
|
|
|
| Verfasst am:
Mi, 12 Jan 2005 - 15:59
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
Aha, es ist also wie wir vermutet hatten. Nicht schön, aber zumindest erklärlich. Danke fürs schnelle Nachprüfen.
| ChrisW hat folgendes geschrieben: | | Ein gutes Beispiel auch dafür, dass man das weggekürzte End-E vielleicht nicht auf Teufel-komm-raus wieder anhängen sollte. Mit "betret", "untersuch" usw. ohne das End-E kann man zur Not leben, aber was ist denn "betritte". |
Oder 'ue' (ich ue, du ust, er ut). Naja, das 'e' passt schon in den meisten Fällen, wenn man mal von einigen Nicht-Verben wie 'ausführlich', 'Inventar', den Schimpfwörtern und den Abkürzungen absieht, bleiben nur wenige Fälle: (be)tritt, nimm, wirf, iss, gib und zerbrich.
Das müsste man eigentlich durch Anpassen von LanguageVerb geradeziehen können. Im Moment heißt die noch:
| Code: |
[ LanguageVerb i;
if (i==#n$l) { print "schau"; rtrue; }
if (i==#n$z) { print "warte"; rtrue; }
if (i==#n$x) { print "betrachte"; rtrue; }
if (i==#n$i or 'inv' or 'inventory' or 'inventar')
{ print "inventar"; rtrue; }
rfalse;
];
|
Die ist wohl ewig nicht mehr angefasst worden, denn die Notation #n$l (von David Baggett einmal als "burst of line noise" bezeichnet) stammt ja noch aus dem Inform-Pleistozän. Hier müsste etwas stehen wie:
| Code: |
[ LanguageVerb i;
if (i=='l//') { print "schaue"; rtrue; }
if (i=='z//') { print "warte"; rtrue; }
if (i=='j//') { print "ja"; rtrue; }
if (i=='x//' or 'u//' or 'b//')
{ print "betrachte"; rtrue; }
if (i=='i//' or 'inv' or 'inventory')
{ print "Inventar"; rtrue; }
if (i=='betritt' or 'tritt' or 'nimm' or 'gib') {
print (address) i ; rtrue;
}
if (i=='wirf' or 'brich' or 'zerbrich'
or 'iss' or i=='friss') {
print (address) i ; rtrue;
}
rfalse;
];
|
Wenn der Autor eigene unregelmäßige Verben einfügen will, sollte er analog dazu den Einhänger PrintVerb verwenden:
| Code: |
[ PrintVerb v;
if (v=='befiehl') { print (address) v; rtrue; }
rfalse;
];
|
Edit: Es sollten in LanguageVerb und PrintVerb auch alle Verben mit Umlauten und Eszett (öffne, schließe) umschrieben werden sowie Verben, die länger sind als neun Buchstaben und daher abgeschnitten werden (zerschneide, konsultiere, zerquetsche).
_________________
Every silver lining has a cloud. |
|
|
|
|
|
| Verfasst am:
Mi, 12 Jan 2005 - 18:21
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
Mmh. Hast recht, in den allermeisten Fällen ist das "e" wohl sinnvoll, allerdings wird es ausgerechnet in der parserm.h wieder angehängt. Meines Erachtens gehört so etwas nicht in die sprachunabhängigen Dateien, wenn man es wie in diesem Fall vermeiden kann. Dann wäre auch eine Umstellung der deutschen Library auf 6/11 weniger ein Problem als es offensichtlich ist.
Deine neue LanguageVerb sieht klasse aus. Ich werd sie mal ausprobieren und wo nötig noch ergänzen. Danke für den ganzen Aufwand, den du dir im Grunde ja fürs Konkurrenzsystem machst. :)
_________________
"Ein Musiker! Was will der hier so spät?" Stolzing (Meistersinger v.N.) |
|
|
|
|
|
| Verfasst am:
Mi, 12 Jan 2005 - 18:40
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
| ChrisW hat folgendes geschrieben: | | Meines Erachtens gehört so etwas nicht in die sprachunabhängigen Dateien, wenn man es wie in diesem Fall vermeiden kann. Dann wäre auch eine Umstellung der deutschen Library auf 6/11 weniger ein Problem als es offensichtlich ist. |
Das 'e' könnte man ja auch in LanguageVerb anhängen, anstatt dort nur rtrue zu sagen.
| ChrisW hat folgendes geschrieben: | | Deine neue LanguageVerb sieht klasse aus. Ich werd sie mal ausprobieren und wo nötig noch ergänzen. Danke für den ganzen Aufwand, den du dir im Grunde ja fürs Konkurrenzsystem machst. :) |
Bei der jetzigen Version gibt es gewiss noch einiges zu verbessern. Und LanguageVerb sähe gewiss mit einem switch-Statement anstelle der vielen ifs wesentlich besser aus.
Inform ist doch keine Konkurrenz. (Keine enstzunehmende jedenfalls. Ende 2006, wenn die Lizenzeinnahmen durch T.A.G. weiterhin stabil eintrudeln, werde ich Inform kaufen. Bis dahin wird noch eine friedliche Koexistenz vorgegaukelt. Hehe :-)
Naja, ein bisschen besser zu verstehen, wie die Lib funktioniert, kann ja nicht schaden. T.A.G. hat ja auch viel von Inform gelernt. Und ein im Code herumzustöbern macht mir auch Spaß.
Und darüber, dass meine Posts hier so zügig mit Forscherdrang und Begeisterung beantwortet werden, freue ich mich natürlich auch.
_________________
Every silver lining has a cloud. |
|
|
|
|
|
|
Alle Zeiten sind GMT + 1 Stunde (MEZ) |
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|
