Geschrieben um 09:55 am 22.07.2010 | Zitat | Editieren | Löschen | |
Mitglied Bachelor Gumby Beiträge: 40 | <td valign="top"><div class="post"><p>Und schon wieder etwas, das ich nicht verstehe:</p> <p>Ich nachdem ich die Endprodukte der Verdauung im erfolgreich Klohaus verwurstet habe, wend ich mich nun den Ausgangsprodukten in der Küche zu. Über dem Herd ist eine Stange befestigt, an der hängen die Töpfe: ```</p> <p>Object -> stange "Metallstange"</p> <p>with description "Die Stange ist aus schwarzem Metall und mit Ösen an der Wand befestigt.",</p> <p> name 'metallstange' 'stange',</p> <p> initial [;print "^An einer Metallstange über dem Herd hängt ";</p> <p> WriteListFromCase(child(self), ENGLISH_BIT + TERSE_BIT + CONCEAL_BIT + RECURSE_BIT, Nom);</p> <p> ],</p> <p>has static transparent;</p> <p>Class kochgeschirr</p> <p>with list_together [;</p> <p> if (inventory_stage == 1) {</p> <p> print "Kochgeschirr, nämlich ";</p> <p> if (c_style & INDENT_BIT == 0) print " ";</p> <p> else print " --^";</p> <p> } else if (c_style & INDENT_BIT == 0)</p> <p> print ".";</p> <p> ],</p> <p> before [; Take: move self to kueche;],</p> <p>has container open transparent;</p> <p>Object ->-> topf1 "Topf"</p> <p>class kochgeschirr</p> <p>with description "Schon ziemlich groß",</p> <p> name 'koch-' 'topf' 'groß',</p> <p> adj "groß",</p> <p>has male;</p> <p>Object ->-> topf2 "Topf"</p> <p>class kochgeschirr</p> <p>with description "Unwahrscheinlich groß",</p> <p> name 'koch-' 'topf' 'riesig',</p> <p> adj "riesig",</p> <p>has male;</p> <pre><code> Die Raumbeschreibung tut, was sie soll: **Zitat:** > An einer Metallstange über dem Herd hängt Kochgeschirr, nämlich ein großer Topf, ein sehr großer Topf, eine Bratpfanne und ein Kupferkessel. Doch das Ansteuern der einzelnen Töpfe klappt nicht: **Zitat:** > >u topf Was meinst du, den großen Topf, den riesigen Topf ioder den Kupferkessel. >u großen Topf So etwas kannst du hier nicht sehen. Das Problem taucht auch auf, wenn ich das Adjektiv nicht oder anders dekliniere, jedoch bei dem riesigen Topf. Den findet der Parser problemlos, obwohl die Objektbeschreibung bis auf das Adjektiv identisch ist. Was mache ich falsch? Schöne Grüße, Christof</code></pre></div></td> |
Geschrieben um 11:52 am 22.07.2010 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 634 | Die Vokabel 'groß' enthält ein Eszett. Sie sollte 'gross' heißen. Als einer der ersten Schritte werden alle Umlaute und Eszetts in Kreuzworträtsel-Notation (ae, oe, ue, ss) umgewandelt. Daher müssen alle Wörter, die Inform erkennen soll, in dieser Notation und komplett in Kleinbuchstaben sein. Wenn Du mit der Debug-Option -D kompilierst, steht Dir der Befehl 'libcheck' zur Verfügung: 660099C++:
Wenn man von der zusätzlichen Leerzeile vor der Liste absieht, ja. :-) |
Geschrieben um 18:40 am 22.07.2010 | Zitat | Editieren | Löschen | |
Mitglied Bachelor Gumby Beiträge: 40 | Ups, das wäre wohl ein typischer Anfängerfehler, was? Danke für die Antwort, da hätte ich tagelang drüber gebrütet... In die Debug-option muss ich mich gleich mal reinfriemeln. Ich kenne nur die Fehlermeldungen, die im compilation_log landen. Zitat:
Und ob die beabsichtigt ist. Ich habe dafür die "^^" bei der Lib rausgenommen, weil dann die Listenausgabe von Objekten und Tochterobjekten besser aussieht. Schoene Gruesse! Christof |
Geschrieben um 09:34 am 23.07.2010 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 634 | C++:
Nö, das passiert auch alten Hasen noch. Deform verlangt halt eine gewisse Syntax, die aber leider nicht vom Compiler überprüft und korrigiert werden kann. Deswegen gibt es den Libcheck als Hilfestellung. |
Geschrieben um 13:32 am 23.07.2010 | Zitat | Editieren | Löschen | |
Mitglied Retired Gumby Beiträge: 1062 | Martin:
Das ist ja praktisch! Da wühlt sich unsereins jahrelang durch die Lib und übersieht diese nützliche Testfunktion. Die möchte ich gerne auch in der I7-Übersetzung nutzbar machen, habe aber noch eine Frage dazu: Wenn ich libcheck im Glulx-Format ausführe, werden die Vokabeln mit Umlaut vollständig angegeben: Mein Glulx-Testspiel:
Die Vokabel 'schüssel' von Objekt 341040 (die Schüssel) hat Umlaute. Die Vokabel 'mädchen' von Objekt 342160 (das Mädchen) hat Umlaute. 2 Fehler. Im Z-Code-Format sieht das aber so aus: Mein Z-Code-Testspiel:
Die Vokabel 'schüss' von Objekt 52 (die Schüssel) hat Umlaute. Die Vokabel 'mädche' von Objekt 87 (das Mädchen) hat Umlaute. 2 Fehler. Beide Vokabeln mit Umlauten (und auch mögliche weitere) haben eine Länge von 6 Zeichen. Das ist ja nicht schlimm, aber mich würde interessieren, wo der Unterschied herkommt. Ich habe die deform-Routinen für den Libcheck bis auf die Raumabfrage 1:1 übernommen. |
Geschrieben um 15:52 am 23.07.2010 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 634 | ChristianB:
Das stimmt, zumindest für menschliche Leser und für Glulx. Glulx verwendet den Zeichensatz ISO 8859-1 (Latin-1), daher nimmt jedes Zeichen ganau einen Platz im String ein. Zeichen, die nicht in diesem Zeichensatz enthalten sind, können nicht in Vokabeln enthalten sein. Die Z-Maschine verschlüsselt Zeichen anders und kennt das Konzept der Z-Zeichen oder Z-Characters, die in den hinteren Kapiteln des DM4 auch beschrieben sind und die nicht ganz trivial sind. Statische Texte ("~Hallo!~") und Vokabeln ('hallo') werden als Dreiergruppen von Einträgen verschlüsselt. Jeder Eintrag kann Werte von 0 bis 31 annehmen, kann also mit fünf Bits verschlüsselt werden. Man kann 3*5 Bits in ein Z-Code-Word packen. Das letzte Bit der 16 Bits im Word wird dann dazu verwendet, um zu signalisieren, dass der String zu Ende ist. Ganz grob geht die Verschlüsselung so: Die lateinischen Kleinbuchstaben von a bis z benötigen einen Eintrag. Die entsprechenden Großbuchstaben werden als ein Shift-Code und der Buchstabe, also als zwei Einträge verschlüsselt. Mit einem anderen Shift-Code kann man noch weitere Zeichen als zwei Einträge verschlüsseln. Das sind, wenn nichts angegeben wird, Satzzeichen und Ziffern. Alle anderen Zeichen, und dazu zählen die Umlaute, müssen als eine Sequenz von vier Einträgen verschlüsselt werden: Die ersten beiden Einträge kennzeichnen ein solches Zeichen, die beiden anderen geben den Code des Z-Zeichens an. Wie bei Latin-1 sind die Umlaute im Z-Code Zeichen mit Codes über 127, auch wenn deren Codes unterschiedlich sind. Das Neun-Zeichen-Limit der Vokabeln bezieht sich nicht auf die Anzahl der tatsächlichen Zeichen, sondern auf diese Einträge. "Schüssel" hat demnach elf, "Mädechen" zehn Einträge und Vokabeln werden nach neun Einträgen einfach abgeschnitten. Eine Vokabel mit zwei Umlauten, zum Beispiel 'Ölöfen', würde nach drei Zeichen abgeschnitten, die neun Einträge belegen. Anmerkung 1: Glulx kann ja mittlerweile Unicode, obwohl in der Original-Spezifikation stand, dass "ISO 8859-1 heilig" sei. Wie der Unicode in Glulx genau funktioniert, weiß ich nicht, aber ich vermute, dass die Texte in UTF-8 abgelegt werden. In diesem Format haben die Zeichen mit einem Code von weniger als 128 - das sind die lateinischen Buchstaben ohne Umlaute, die Ziffern und die gägnigen Satzzeichen - einen Eintrag. Zeichen aus Latin-1, zu denen die Umlaute gehören, haben zwei Einträge. Exotischere Zeichen - mathematische Symbole oder so - haben drei oder vier Einträge. In diesem Fall wäre "Schüssel" neun Einträge lang. Ein "Schlüssel" würde also bereits beschnitten, da in Glulx auch ein Neun-Zeichen-Limit gilt. Anmerkung 2: Wenn man den Text (nicht die Vokabel) "Schüssel" in ein String-Feld ausgibt, ist die Länge des Strings allerdings wie vermutet acht, da das Wort acht Zeichen hat. Was oben als "Einträge" bezeichnet wurde, bezieht sich nur darauf, wie der z-Code oder wie Glulx die Texte intern ablegen. Anmerkung 3: Was ich oben als Kleinbuchstaben, als Großbuchstaben sowie als Ziffern und gängige Satzzeichen bezeichnet habe, heißt im Z-Code-Sprech Alphabet 1, Alphabet 2 und Alphabet 3. Man kann diese Alphabete mit der Direktive ZCharacter ändern, um Zeichen zu sparen. Die Ersparnis ist wegen des Neun-Zeichen-Limits besonders für Vokabeln wichtig. Da Deform aber im Parser keine Umlaute verwendet, habe ich das nicht gemacht, aber andere Übersetzungen machen das. 'ae' hat zwei Einträge, 'ä' hätte, wenn man es auf Kosten der Klammer auf zum Beispiel ins Alphabet 3 verschöbe, ebenfalls zwei Einträge. Das wäre also keine Ersparnis. Und ich finde es gut, dass man dem Parser mit den 'ae'-Varianten kommen kann. Anmerkung 4: Wer jetzt meint, dass vier Einträge für einen Umlaut zu viel sind und seine exotische Agentenjagd durch Finnland, Estland und die Türkei komprimieren will, kann mit Abbreviate "ä" und der Option -a bei jedem 'ä' zwei Einträge sparen. (Es gibt nämlich noch drei weitere Shift-Codes, die sagen, dass der nächste Eintrag eine Abkürzung ist. Einer der Codes ist in Inform als @XX-Notation implementiert, die anderen beiden sind Abkürzungen, die man mit Abbreviate angeben kann.) Anmerkung 5: Die ganze Wahrheit mit mehr Details als man vermutlich wissen möchte und sich behalten kann, steht in Abschnitt 3 des Z-Maschinen-Standards. Das war unser kleiner Ausflug in den Maschinenraum der Z-Maschine. Bitte geben Sie die Overalls und die Schutzhelme am Ausgang ab. Dort haben Sie auch die Gelegenheit, sich zu waschen. |
Geschrieben um 01:49 am 26.07.2010 | Zitat | Editieren | Löschen | |
Mitglied Retired Gumby Beiträge: 1062 | Martin:
So. Die Buchstabensuppe ist endlich runtergespült. Martin, vielen Dank für diese erhellende Erklärung. Jetzt ist mir einiges klar geworden, das ich im DM4 nie so richtig durchblickt hatte. Dass die Z-Maschine Texte im Grunde wie ein Fernschreiber aus der guten alten Zeit codiert, war mir nicht bewusst. |