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):
! 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:**
> 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:**
> 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:
```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?
