Hallo Mario!

Bei der Ausgabe des Objektnamens (hier: “die Eingang”) wird immer der angegebene Genus des Objekts und der Text des printed name verwendet. PostEntryDoor in deinem Beispiel ist female, der printed name ist “Eingang”, also wird erwartungsgemäß “die Eingang” ausgegeben. Deshalb sollte der Objektgenus mit dem angezeigten Namen übereinstimmen.

Vokabeln werden grundsätzlich nicht für die Ausgabe des Objektnamens herangezogen. Sie dienen dazu, die Eingabe des Spielers zu verstehen. Die Genus-Kennzeichnungen bei den Vokabeln, z.B. “Eingang [m]” werden ausschließlich vom Canging-Gender-Mechanismus (CG) verwendet, der die Pronomen für Synonyme mit vom Objektgenus abweichendem Genus korrekt setzt. Also z.B.:

u tür

Diese Tür ist der Eingang.

öffne eingang

Der Weg ist jetzt frei.

schließe ihn

Du schließt die Tür.

In deinem Beispiel bräuchtest du also nur female durch male bei der Definition von PostEntryDoor zu ersetzen und den abweichenden Genus der Vokabel “Glastuer” mit “[f]” zu kennzeichnen. Die Vokabel Eingang benötigt keine CG-Markierung, weil der Genus von “Eingang” dann mit dem Objektgenus (male) übereinstimmt.

Viele Grüße,

Christian

Mario Donick:

Mein Problem ist vielleicht nur meiner Blödheit geschuldet, aber folgender Code produziert “die Eingang”

Na, Deiner Blödheit gewiss nicht, vielleicht eher der Unübersichtlichkeit von I7. Du schreibst:

003399

Und damit heißt es dann “die Eingang”; der Eingang ist weiblich. Das [m] in #003366 bezieht sich nur auf die Eingabe. Wenn Du den Eingang #003399 machst, sollte es richtig “der Eingang” heißen und Du kannst Dir das dann redundante [m] in der Vokabel sparen. (Dort muss man den Genus nur angeben, wenn er vom Genus des Objekts verschieden ist.)

Mario:

Liegt das Problem darin, dass sowohl der printed name als auch das Synonym beide “Eingang” heißen, aber der printed name für ein weibliches Objekt “door” steht?

Ja. Die lange Beschreibung “Eine gläserne Eingangstür”, die die weibliche “Tür” erwähnt, benötigt keinen Genus, weil sie immer ungebeugt als Block ausgegeben wird.

Die Tür selbst hat den #003399 “Eingang”. Das ist der Name, der in allen automatisch generierten Ausgabetexten, also zum Beispiel mit #003399, verwendet wird, und der braucht halt den passenden Genus #003399.

(Du denkst dort vielleicht auch ohne es zu wollen an die Tür, da Dein Objekt PostEntryDoor heißt.)

Danke für die Hinweise. Jetzt geht es, mit

“`

The PostEntryDoor is a scenery door, south of the PostMainHall and north of the GentryStreet. “Eine gläserne Eingangstür.”

The printed name of the PostEntryDoor is “Eingang”. The PostEntryDoor is closed and male.

Understand “Glastuer [f]”, “Tuer [f]”, “Eingangstuer [f]” and “Eingang” as the PostEntryDoor.

“`

In der Tat verwirrt mich Inform 7 ziemlich oft, vor allem, wenn ich nach einem halben Jahr Pause wiederkomme.

Und erneut habe ich eine Frage zu Türen (wahrscheinlich kommen die Tage noch diverse, denn ich habe gerade Urlaub …)

Folgender Code:

“`

The SchoolYardNorthernDoor is a scenery door, south of the SchoolHall and north of the SchoolYard. “Eine hölzerne Tür zum Hof.”

The printed name of the SchoolYardNorthernDoor is “Tür zum Hof”. The SchoolYardNorthernDoor is closed and female.

Understand “Hoftuer”, “Tuer” and “Tuer zum Hof” as the SchoolYardNorthernDoor.

“`

produziert u.a. folgendes Ergebnis:

Zitat:

s

Die Tür zum Hof ist verschlossen. Da komme ich nicht durch.

öffne tür

Was meinst du, den Eingang oder die Tür zum Hof?

öffne die tür zum hof

So etwas kann ich hier nicht sehen

Wieso?

Verschmelzungen von Präpositionen und Artikeln werden vor dem Parsen aufgelöst, d.h. “zum” in der Spielereingabe wird nach “zu dem” umgewandelt.

blue

Verstanden werden nun U TÜR ZUM HOF und U TÜR ZU DEM HOF.

Ehrlich gesagt, wundert es mich, warum das überhaupt geht.

Es funktioniert immer, wenn das Objekt der Gefragte ist. Sonst nicht.

[CharAnn] gibt in say-texten den printed name des Objekts in Klammern aus. Als understand-Definition habe ich das so noch nie gesehen.

Eine saubere Implementierung des Fragens nach Objekten kannst Du nur mit einer Neudefinition des ganzen Frage- und Antwortmechanismus erreichen.

Dazu gibt es aber schon Extensions, die das handeln, z.B. “Conversation Framework” von Eric Eve. Hier werden neue Aktionen definiert, die das Fragen nach Objekten ermöglichen.

http://inform7.com/extensions/Eric%20Eve/Conversation%20Framework/index.html

Die korrekte Schreibweise wäre nach Einbinden der Extension z.B.:

Instead of quizzing CharAnn about CharAnn:

say “…”;

Das hat den großen Vorteil, dass alle Synonyme mit abgedeckt sind, so wie es Deine Absicht ist.

— MI

Oh, das ist eine interessante Antwort, und wenn das so ist, dann wundert mich das Funktionieren bei Mrs. Whitemoore auch. Ich werde mal deinen Hinweis mit der Extension beherzigen.

Edit: Hm, okay, so einfach ist es dann doch nicht, weil die Extension ja auf Englisch ist und der Spielerbefehl “frag nach” dann nicht so einfach funktioniert … Mal gucken.

Mikawa:

Ehrlich gesagt, wundert es mich, warum das überhaupt geht.

Es funktioniert immer, wenn das Objekt der Gefragte ist. Sonst nicht.

“[CharWhitemoore]” wird in Marios Beispiel als Understand-Token (Noun-Filter) interpretiert, erlaubt sind aber, wenn man keine Conversation-Extensions benutzt, nur Topics (Texte). Eigentlich darf NI das nicht durchwinken und es sollte ein Problem-Bericht ausgegeben werden. Das sieht nach einem I7-Bug aus.

Hier hat sich Inform 7 anscheinend selbst ausgetrickst: Die Schreibweise “[CharWhitemoore]” wird in say-Texten zur Ausgabe des Objektnamens ohne Artikel verwendet; dann ist es eine Textersetzung (eine Print-Routine). Die gleiche Schreibweise wird auch für Understand-Tokens benutzt:

blue

Zudem verwendet I7 für Topics, Teile der Spielereingabe (Snippets), Ausgabetexte und Vokabeln die gleiche Schreibung mit Anführungszeichen (“Ann”), obwohl es sich hinter den Kulissen um völlig unterschiedliche Dinge handelt.

Compiler verwirrt. Autor auch.

Mikawa:

Dazu gibt es aber schon Extensions, die das handeln, z.B. “Conversation Framework” von Eric Eve.

Gibt es schon irgendwo eine Übersetzung des “Conversation Frameworks”?

Zitat:

Compiler verwirrt. Autor auch.

:-) Vielleicht hat das auch mit der Umgewöhnung zu tun - ich bin normale Programmiersprachen gewohnt, mit einer abstrakten Syntax, bei der man genau weiß, was geht und was nicht.

Inform 7 verleitet dazu, Sachen schreiben zu wollen, die nicht unbedingt Sinn machen. Die eingebaute Doku ist da auch nicht immer hilfreich, da sie sich eher an komplett Unerfahrene richtet und das, was ich wissen will, schwer zu finden ist (“Inform 7 for Programmers” von Ron Newcomb hilft da aber gegen.)

Mittlerweile experimentiere ich mit der Schrägstrich-Schreibweise, die in der Inform 7 Doku u.a. für Topic-Tabellen genutzt wird:

Aber so richtig klappt das auch nicht, z.B. erlaubt mir

“`

Ask CharWhitemoore about “Ann/Schwester/meiner Schwester”

“`

den Befehl:

“Frage die Frau nach meiner Schwester”, aber nicht “Frage die Frau nach Ann”.

Schreibe ich hingegen

“`

Ask CharWhitemoore about “Ann/Schwester”

“`

dann kann ich sowohl nach “Ann” als auch nach “Schwester” fragen.

Es scheint also entweder ein Limit zu geben bzgl. der Länge des Strings, oder der Anzahl der durch / getrennten Begriffe, oder der Nutzung von Leerzeichen.

Mario Donick:

“`

Ask CharWhitemoore about “Ann/Schwester/meiner Schwester”

“`

So kannst Du fragen nach:

Ann Schwester

Schwester Schwester

meiner Schwester

Durch das Leerzeichen muss die zweite Schwester immer dabei sein.

Gibt es keine Möglichkeit das Leerzeichen irgendwie zu maskieren?