| Autor |
Nachricht |
| < 'mein' nicht immer gleich 'meinen' |
|
 Verfasst am:
Di, 29 März 2005 - 10:12
|
|
|
Kompassleser
Anmeldungsdatum: 21.02.2004
Beiträge: 198
Wohnort: Rheinmain
|
|
Hallo zusammen,
ich habe hier ein Problem mit dem Abschneiden einer Endung:
folgendes Objekt (bitte nicht an "einen eigenen Ball" stören, es ist nur zur Vereinfachung so demonstriert):
| Code: | Object Ball2 "Ball" Testlabor
with name 'ball' 'dein' 'mein' 'eigen',
description "Es ist dein eigener Ball.",
adj "eigen",
dekl 1,
has male; |
Das sieht dann so aus:
| Code: |
Du siehst hier einen eigenen Ball.
>x meinen ball
Es ist dein eigener Ball.
> |
"en" wird von ProcessGermanSuffixes entfernt. So ist alles noch in Ordnung.
Kommt aber ein zweites Objekt hinzu:
| Code: | Object Ball1 "Ball" Testlabor
with name 'ball' 'fremd',
description "Es ist ein Ball von anderen Kindern.",
dekl 1,
adj "fremd",
has male; |
... passiert folgendes:
| Code: | Du siehst hier einen fremden Ball und einen eigenen Ball.
>x meinen ball
Du kannst nichts dergleichen sehen.
>x mein ball
Es ist dein eigener Ball.
>x deinen ball
Es ist dein eigener Ball.
> |
Das bedeuted, bei 'deinen' wird abgeschnitten, bei 'meinen' nicht!?
Das Problem tritt nur auf, wenn ein dictword auf zwei Objekte passt, wenn man aus dem fremden Ball einen Ballon macht, ist das Problem behoben.
Es ist definitiv nichts weiter implementiert oder eine Extension die zum Einsatz kommen könnte ;-)
Man könnte zusätzlich 'meinen' 'meinem' aufnehmen, damit habe ich aber an anderer stelle schon Überaschungen erlebt, was die Zurodnung zu Objekten bei der Eingabe angeht.
Hat sich jemand damit schon beschäftigt?
Dank und Gruß
Christof |
|
|
|
 |
|
| Verfasst am:
Di, 29 März 2005 - 14:20
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
| Kris hat folgendes geschrieben: | | Das bedeuted, bei 'deinen' wird abgeschnitten, bei 'meinen' nicht!? |
Das passiert dir nur mit 'dein' und 'mein', oder? Und nicht etwa mit 'fein' und 'klein'?
Wenn ja: Volle Deckung. Dann kommt nämlich wieder ein Schnellschuss, der ohne Überprüfung der Tatsachen abgefeuert wird: 'Mein' und alle gebeugten Formen werden in german.h als Possessivpronomina definiert, 'dein' hat keine Bedeutung in der Lib. Die Formen von 'mein' werden dann innerhalb einer noun phrase als descriptor verstanden, der nur auf Dinge zutrifft, die der Spieler bei sich hat. Da die beiden Bälle am Boden liegen, trifft das auf keine Ball zu, und es kommt die abschlägige Antwort.
Du kannst ja einmal die Definition der 'mein's aus german.h auskommentieren und sehen, was dann passiert. Außerdem müsstest du in deinem bereits kompilierten Spiel auch ohne Probleme "meinen fremden Ball" sagen können und dich damit eindeutig auf den ersten Ball (mit der Nummer 2) beziehen.
TADS3 hat, galube ich, eine Property owner, mit der man einen Eigentümer eines Objekts angeben kann, so dass hier 'mein' als Objekt mit dem Spieler als Eigentümer (und nicht als momentanen Besitzer wie in Inform) betrachet würde. Clever.
_________________
Every silver lining has a cloud. |
|
|
|
|
|
| Verfasst am:
Di, 29 März 2005 - 14:43
|
|
|
Kompassleser
Anmeldungsdatum: 21.02.2004
Beiträge: 198
Wohnort: Rheinmain
|
|
Hallo,
ich war gerade dabei meine neuesten Erkenntnisse zu posten, da kam auch schon die Info, dass jemand (=Martin) geantwortet hat :-)
Die Sache mit Descriptor ist mir dann auch eingefallen und ich bin auf die Suche gegangen und genau dort (german.h) fündig geworden.
Hähä, dachte ich, schnell mal alle 'mein's und 'dein's entfernt und losgelegt:
| Code: | Object Ball3 "Ball" Testlabor
with name 'ball' 'fremd',
description "Es ist ein Ball von anderen Kindern.",
dekl 1,
adj "fremd",
has male;
Object Ball2 "Ball" Testlabor
with name 'ball' 'eigen',
description "Es ist dein eigener Ball.",
adj "eigen",
dekl 1,
has male; |
Mit interessantem Ergebnis:
| Code: | Du siehst hier einen fremden Ball und einen eigenen Ball.
>nimm meinen ball
Du kannst nichts dergleichen sehen. |
Ändere ich das Obkjekt in einen Ballon:
| Code: | Object Ball3 "Ballon" Testlabor
with name 'ballon' 'fremd',
description "Es ist ein Ball von anderen Kindern.",
dekl 1,
adj "fremd",
has male;
Object Ball2 "Ball" Testlabor
with name 'ball' 'eigen',
description "Es ist dein eigener Ball.",
adj "eigen",
dekl 1,
has male; |
... passiert nun das hier:
| Code: | Du siehst hier einen fremden Ballon und einen eigenen Ball.
>nimm meinen ball
Du trägst den eigenen Ball jetzt bei dir.
>nimm meinen ballon
Du trägst den fremden Ballon jetzt bei dir.
> |
Es scheint, als würde bei der Disambiguisierung anstelle der Nachfrage, welchen Ball ich meine, CANTSEE_PE zurückgegeben.
EDIT:
Trage ich den "eigenen Ball" übrigens bei mir, kann ich mich auf "meinen" Ball beziehen (dann greift der Descriptor), bzw. auf das, was ich bei mir trage. Also unterstützt "mein" bei der Disambiguisierung solange es dem Parser hilft sich zu entscheiden, wenn nicht, wird nicht nachgefragt, sondern CANTSEE_PE ausgegeben.
Entweder widmet man sich dieser Sache näher (was Sinn macht, da die Descriptors sicher Ihre Daseinsberechtigung haben) oder nimmt den Workaround der bei mir (aus Zeitmangel :-) erstmal zum Einsatz kommen wird:
Possesivpronomen-Variationen von 'mein' auskommentieren und "Meinem Ball" den Name 'mein' hinzufügen. Dann läuft es am Schnürchen.
Allerdings ist noch völlig ungetestet, welche unerwünschten Nebenwirkungen und Risiken das mit sich bringt, und mein Apotheker konnte mir da leider auch keine Antwort drauf geben.
Diese Woche habe ich dafür defintiv keine Zeit, werde mich aber gerne mal, wenns bis dahin keiner gemacht hat, ab nächste Woche darum kümmern.
Gruß
Christof |
|
|
|
|
|
| Verfasst am:
Di, 29 März 2005 - 15:50
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
| Kris hat folgendes geschrieben: | | Es scheint, als würde bei der Disambiguisierung anstelle der Nachfrage, welchen Ball ich meine, CANTSEE_PE zurückgegeben. |
Ja, offensichtlich weil der descriptor auf kein Objekt zutrifft, obwohl ja beide im Sinne des Parsers gültig wären. Wenn man nicht disambiguisieren muss, kann man jeden beliebigen descriptor verwenden, egal, ob er unsinnig ist. Deshalb sollte man im Fall der Disambiguisierung vielleicht auch denselben Unsinn zulassen - immerhin brüstet sich der Inform-Parse ja damit, möglichst viel, auch wenig Sinnvolles durchgehen zu lassen - und die normale Nachfrage zu stellen. (Was das aber in Bezug auf Inform-Variablen bedeutet, weiß ich nicht. Als Fehler wird das wohl nicht gewertet. Die englische Lib zeigt hier genau dasselbe Verhalten: Wenn man keines der möglichen Objekte hat und 'my' benutzt, kommt CANTSEE_PE.)
| Kris hat folgendes geschrieben: | | Diese Woche habe ich dafür defintiv keine Zeit, werde mich aber gerne mal, wenns bis dahin keiner gemacht hat, ab nächste Woche darum kümmern. |
Sehr löblich! :-)
Da möchte ich dir einmal die Lektüre der Zusammenfassung von Platypus 4 ans Herz legen. Platypus, eine alternative Library für Inform, benutzt sehr viele descriptors. (Vielleicht zu viele. 'lit' und 'unlit' aus der Standard-Lib, die wohl eher selten oder für akademische Beispiele wie gefrotzte weiße Würfel, die noch dazu eigene Namen haben können, verwendet werden hat Platypus aber zugunsten von 'open'/'opened' und 'closed' aufgegeben.)
Interessant ist dort die Routine ParseDescriptor, mit der man eigene descriptors definieren kann:
| Code: |
[ ParseDescriptor obj wd fl;
switch (wd) {
'mein', 'dein': if (obj has mine) rtrue;
default: return -1;
}
rfalse;
];
|
(Sehr elegant auch die Platypus-Property disambiguate für Objekte.)
_________________
Every silver lining has a cloud. |
|
|
|
|
|
| Verfasst am:
Mo, 4 Apr 2005 - 13:56
|
|
|
Kompassleser
Anmeldungsdatum: 21.02.2004
Beiträge: 198
Wohnort: Rheinmain
|
|
Hallo,
wie angekündigt, habe ich mich mal mit dem Problem beschäftigt.
Einen Ansatz für eine generelle Lösung kann ich nicht bieten, da die Descriptors ohne Informisierung geprüft werden müssen um genderspezifische Eigenschaften zu prüfen (also 'meine' ist nicht gleich 'meinen') aus diesem Grund werden Descriptors auch nicht Imformisiert, muß man also auch z.B. 'meinen' und 'meinem' zur Nameproperty hinzufügen.
Die derzeitige "Lösung" ist, bei meinen Ball 'meinen' als name aufzunehmen, dann gibt es aber ein Problem. Durch die Reihenfolge des Parsens wird zuerst nach Descritporen gesucht (C), danach der Objectname geparst (D):
| Code: | ! (A) Analyse the token; handle all tokens not involving
! object lists and break down others into elementary tokens
! (B) Begin parsing an object list
! (C) Parse descriptors (articles, pronouns, etc.) in the list
! (D) Parse an object name
! (E) Parse connectives ("and", "but", etc.) and go back to (C)
! (F) Return the conclusion of parsing an object list
! ---------------------------------------------------------------------------- |
(Übrigens frage ich mich, ob man die doch hier schon gelgliederte "Endlos"-Funktion nicht hätte aufteilen können, schätze aber aufgrund der vielen Sprungmarken nicht ganz einfach)
'Mein' soll als descriptor darauf hinweisen, dass es sich um ein Objekt in meinem Inventar handelt, d.h. alle Objekte außerhalb meines Inventares fliegen raus.
Gibt es keinen Treffer, wird nach Objektnamen weitergeparst.
Was also nie zustande kommen kann ist, dass beide gleichzeitig disambiguisiert werden, weil einmal der Descriptor und einmal der Name zum Tragen kommt. Das hört sich jetzt umständlich an, aber folgendes Beispiel demonstriert das: Mein Ball liegt auf dem Boden, den fremden habe ich im Inventar.
| Frotz hat folgendes geschrieben: | Du siehst hier einen fremden Ball und einen eigenen Ball.
>x meinen ball
Es ist dein eigener Ball.
>nimm fremden ball
Du trägst den fremden Ball jetzt bei dir.
>x meinen ball
Es ist ein Ball von anderen Kindern.
>nimm meinen ball
Du hast diesen schon.
>nimm eigenen ball
Du trägst den eigenen Ball jetzt bei dir.
|
Am Besten müßte ">X MEINEN BALL" die Frage welchen ich denn meine aufrufen, da "Mein Ball" so heißt und der "fremde Ball" in meinem Inventar ist. Passiert aber nicht, da sie nicht gemeinsam Adjudicate() zum Disambiguisieren durchlaufen.
Wenn sich Inform schon entscheidet, dann sollte es eigentlich für meinen Ball sein, da in meinen Augen der Name Vorrang haben sollte. Das geht aber nicht, da Descriptors zuerst geprüft werden.
Man sollte sich also überlegen, ob man entweder mit der standartisierten Form des Descriptors arbeiten möchte (dann muß man gar nichts tun), oder aber ein Spiel hat, in dem der Besitz generell festgelegt ist wie z.B. mein Haus, mein Auto, mein Schiff. In diesem Fall in german.h den "Mein-Block" als Descriptor auskommentieren und meine Objekte mit dem Namen 'mein' versehen.
Den Weg über ChooseObjects zu gehen und mit Attributen zu arbeiten habe ich verworfen, da die Descriptors in jedem Fall auskommentiert werden müssen da sie immer VOR dem Objekt geparst werden.
Tja, eigentlich nicht viel erreicht, habe aber dafür wieder ein bisschen mehr dazugelernt :-)
Grüße
Christof
EDIT:
| Martin hat folgendes geschrieben: | | Interessant ist dort die Routine ParseDescriptor, mit der man eigene descriptors definieren kann: |
@Martin:
Das scheint eine praktische Funktion zu sein, ich kenne mich nur mit Platypus überhaupt gar nicht aus.
Müßte für z-Code in der Routine dann nicht den Variablen (
indef_possambig
indef_owner
indef_cases usw...) Werte zugewiesen werden? Dann würde es nämlich genügen, am Anfang von Descriptors() folgendes einzufügen:
| Code: | switch (ParseDescriptors(wd)){
1: return true; ! Objekt akzeptiert
-1: return false; ! Objekt abgelehnt
} ! keine entscheidung getroffen (=0), Descriptors wird weiter ausgeführt |
ParseDescriptors müßte die Variablen mit Leben füllen und einen entsprechenden Wert zurückliefern - oder ist es nicht ganz so einfach? |
|
|
|
|
|
| Verfasst am:
Mi, 11 Mai 2005 - 16:03
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
| Kris hat folgendes geschrieben: | | Hähä, dachte ich, schnell mal alle 'mein's und 'dein's entfernt und losgelegt: |
Zum Thema 'mein' und 'dein' noch ein Nachtrag: Im Infor FAQ wird eine Möglchkeit beschrieben, 'mein' nicht als descriptor, sondern als Anzeige des Eigentümers zu interpretieren. Ich denke mal, das müsste auch auf Deutsch gehen.
_________________
Every silver lining has a cloud. |
|
|
|
|
|
| Verfasst am:
Do, 12 Mai 2005 - 10:06
|
|
|
Kompassleser
Anmeldungsdatum: 21.02.2004
Beiträge: 198
Wohnort: Rheinmain
|
|
Ha!
Vielen Dank!
Ich habe das mal ausprobiert und es funktioniert:
| Code: | Object Ball "Gummiball" raum
with name 'ball' 'gummiball' 'bunten',
adj "bunt",
description "Es ist ein stinkmnormaler bunter Gummiball.",
dekl 1,
has male;
Object Ball1 "Gummiball" raum
with name 'ball' 'gummiball' 'blau' 'mein' 'meinen',
adj "blau",
parse_name [;
if (parser_action == ##TheSame) return -2;
if (indef_type & MY_BIT) wn--;
return -1;],
description "Es ist dein blauer Gummiball.",
dekl 1,
has male; |
Man muß allerdings 'mein' und 'meinen' als name bennen, da es nicht informisiert wird - Endungen werden nicht auf MEIN reduziert.
Es ist zwar fraglich, ob ich ">X DIE BLÄTTER MEINER BLUME" ebenso eingebe wie ">X MEINE BLUME", dennoch müssen alle möglichen Formen als name vorkommen die ein Spieler eingeben kann (wenn sie erkannt werden sollen) . Ich konnte keine Probleme feststellen, weiß aber, dass es schwerwiegende Identifikationsprobleme geben kann wenn man bei einem Objekt die Endungen, die eigentlich abgeschnitten werden, mitbenannt werden. (siehe dieses Thread )
Wer damit arbeitet, sollte deshalb mal ein genaues Auge darauf werfen.
Grüße
Christof |
|
|
|
|
|
|
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.
|
|
