Geschrieben um 15:12 am 30.04.2011 | Zitat | Editieren | Löschen | |
Mitglied Baby Gumby Beiträge: 6 | Richtiges Deutsch ala Informisator ist schrecklich lang. Sieht zwar im Text gut aus Aber im Sourcecode überall printed name und so verkorkste oe-namen... kleines föö -> The klein Foeoe is here. The printed name of it is "klein[^] Föö". Uaa! (Aber mir fiel bis gerade eben auch nichts besseres ein) Jedoch, dies hier funktioniert auf der Informseite: The klein$ Foo is here. ->
Du siehst nichts Besonderes an dem klein$ Foo.
Du siehst nichts Besonderes an dem klein$ Foo. Könnte man das ähnlich magisch aufbereiten wie derzeit Umlaute bei Eingabe und [^] bei Ausgabe? Sieht auch Uaa aus, ist aber kürzer |
Geschrieben um 21:24 am 30.04.2011 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 634 | Huck Hooks:
Verstehe ich nicht. Bei den Umlauten in der Eingabe und den Endungen in der Ausgabe wird doch gar nichts magisch aufbereitet. Der Autor muss sicherstellen, dass seine Vokabeln keine Umlaute haben und dass die Namen zur Ausgabe mit den richtigen Endungen markiert werden. Magisch ist da leider nichts. Natürlich wäre es schön, wenn man nicht immer Name und Vokabeln getrennt angeben müsste. Die Namen/Ids/Vokabeln erzeugt aber "ni" (Natural Inform), das I7 in I6 umwandelt und das für Englisch auch gut macht. Die Besonderheiten für Deutsch werden leider nicht berücksichtigt. In "ni" hineinschauen kann man nicht, da meines Wissens der Quelltext nicht offen liegt. Wenn es eine elegante Methode gäbe, hätte sie das Team GerX schon eingebaut. GerX wird aber vor vollendete Tatsachen gestellt: Die Autoren der Extension können zwar vieles in der zugrunde liegenden Bibliothek verändern, aber nicht in die Arbeit von "ni" eingreifen. Im Moment ist es leider so, dass man sich für eine der dokumentierten Strategien (Denglisch oder privately-named) entscheiden und diese dann konsequent anwenden muss. Deine Syntax mag zwar kürzer sein, sie sieht aber auch sehr nach Programm-Syntax aus (von der I7 ja eigentlich weg will) und ist wohl ohne große Verrenkungen auch nicht machbar. Du müsstest zum Beispiel jeden Objektnamen vor der Ausgabe durch einen Filter laufen lassen um die $ und zu ersetzen und jede Eingabe des Spielers in die -Syntax umwandeln (was nicht schwierig ist) und auch raten, welches Wort ein Adjektiv ist und ein $ anhängen (was sehr schwierig ist). Hucks:
Aber im Sourcecode überall printed name und so verkorkste oe-namen... So ist das halt: Damit die (hoffentlich zahlreichen) Spieler schöne Texte sehen, muss der Autor halt ein wenig tippen. |
Geschrieben um 23:52 am 30.04.2011 | Zitat | Editieren | Löschen | |
Mitglied Baby Gumby Beiträge: 6 | Magisch nenn ich alles was intern und automatisch läuft und für mich im Moment noch zu kompliziert ist. Automatisches Ersetzen per Inform6 zb Im Moment tu ich ein [^] in den printed name. Mach ich das ohne GerX, beschwert sich Inform. Also nehme ich an, GerX schnappt sich rechtzeitig den printed name, guckt ihn sich an und, nunja, zaubert rum. Wenn aber GerX ein [^] finden kann, kann es vielleicht auch ein $ finden. Also in Langform: The klein Foeoe is here. The printed name of it is "klein$ Föö". Und wenn der printed name nicht angegeben wird, ist der interne Name der printed name und ich kann einfach schreiben The klein$ Foeoe is here. Hmm, nachdenk, die [] sagen da wird irgendwas mit "to say ^" definiert? Dann klappts nicht. Sourcesuch. To say ^: (- print "@00"; -). Hmpf. Grmml. Und was heist das?^^ Kann man sich stattdessen in das printen vom printed name hängen und dasselbe tun? Also an dieselben Infos für die Grammatik kommen? Wenn das geht könnte man auch gleich alle aou in äöü verwandeln, und bei der Eingabeverwandlung ä nicht in ae, sondern in a. Und schwupps brauche ich keinen expliziten printed name mehr. (Bei ue ist halt nicht garantiert, das wirklich ü gemeint ist, ich konstruier mal BlauEiche. u* ist derzeit selten.) (Foo ist etwas krass. Hu*hnerdieb würde gehen.) Sonst: Entweder ich schreibe alles doppelt in Inform7, oder ich maximiere den Gruselfaktor und such mir ein Lpc mit deutscher Mudlib^^ |
Geschrieben um 19:51 am 01.05.2011 | Zitat | Editieren | Löschen | |
Mitglied Baby Gumby Beiträge: 6 | Wohl gerade noch vor Lpc gerettet.
druckt Lab Das kleine Foo ist ein kleines Foo. |
Geschrieben um 20:11 am 01.05.2011 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 634 | Natürlich ist die doppelte Definition auf den ersten Blick redundant. Aber im Z-Code (und auch in Glulx, dessen Inform-Lib das Z-Code-Verhalten nachäfft) sind Texteingabe und Textausgabe zwei verschiedene Paar Schuhe. Die [^] und Konsorten in I7 sind "@00", "@01", "@02" usw. in I6. Diese Notation fügt einen von 32 Kurzstrings ein, die im Z-Code zur Verfügung stehen. (Es gibt eigentlich 96 davon, aber der Autor hat mit der "@00"-Notation nur auf die ersten 96 Zugriff. Die restlichen 64 werden von I6 beim Komprimieren von Text mit Abbreviate und der Option -a verwendet.) Das ist praktisch, weil so veränderliche Textteile ausgegeben werden können, ohne dass zur Ausgabe eine Routine geschrieben werden muss; man kann einfach die @00-Notation in einem String verwenden. Bevor der short_name, wie der "printed name" in I6 noch hieß, ausgegeben wird, schaut sich Deform Fall, Geschlecht und Modus (also, ob ein bestimmter, unbestimmter opder gar kein Artikel vorangeht) an und setzt @00 bis @04 entsprechend. (Das mit der Routine wäre eigentlich gar nicht so schlimm, wenn es für den short_name nicht eine fest verdrahtete Variante direkt in der Kopfzeile gäbe, in der nur ein String, keine Routine stehen darf. Die Gründe dafür liegen im Format des Z-Codes, das so einen String für jedes Objekt vorsieht.) Die Eingabe funktioniert ganz anders: Aus allen Wörtern wird ein Wörterbuch angelegt. Diese Wörter sind alle in Kleinbuchstaben und sind auf neun Zeichen beschränkt. Weil Z-Code intern eine eigene Textkomprimierung benutzt, sind diese Zeichen keine ASCII- oder gar Unicode-Zeichen, sondern Z-Zeichen. Umlaute und Eszett belegen in dieser Komprimierung vier Zeichen. Dein 'föö' würde demnach schon alle Zeichen ausnutzen, von 'ölfässer' bliebe nur 'ölf' übrig. Man könnte die der Komprimierung zugrunde liegenden Alphabete ändern und die Umlaute und das Eszett auf Kosten einiger Punktuationen einbauen. Dann würden sie immer noch zwei Z-Zeichen belegen. (Man könnte das auf ein Z-Zeichen herunterkürzen, wenn man für ä. ö. ü und ß vier normale lateinische Klienbuchstaben opferte, was die Häufigkeit der Buchstaben gewiss hergibt [1].) Die Variante mit den Kreuzworträtselumschreibungen ae, oe und ue habe ich gewählt, weil sie üblich ist und ohne Umorganisieren der Alphabete nur zwei Zeichen belegen. Andere Übersetzungen von Inform verwenden sie auch. Ein Text mit Umlauten lässt sich eindeutig in diese Notation umwandeln, umgekehrt geht's nicht wie Dir Feuerwehrleute, Quellensteuerhinterzieher und Goethe-Leser aus Soest und Oer-Erkenschwick gerne bestätigen werden. (Außerdem kann man so deutsche Textadventures auf Tastaturen, die keine Umlaute haben, spielen, also quasi auf der ganzen Welt. Immer schön das Große Ganze im Blick behalten.) Die Adjektivendungen könnten zwar bei der Satzanalyse herangezogen werden, werden sie aber nicht. Deform schneidet Endungen für Adjektive nach einer recht simplen Heuristik einfach ab. Ob Wörter im Wörterbuch auch die Kurzstrings @00 usw. enthalten können, habe ich im DM4 und in der Z-Spec nicht gefunden, aber eine gute Idee ist es gewiss nicht, da sie halt veränderlich sind und die alphabetische Sortierung der Wörterbuch, die der Z-Code-Interpreter für seine binäre Suche erfordert, durchainanderbringt. Die einzige Möglichkeit, die redundante Angabe von Ein- und Ausgabewörtern zu unterbinden, wäre, den Quelltext zu bearbeiten, bevor "ni" an die Arbeit geht. das lässt uns I7 aber nicht machen. [1] Hmmm, eher nicht: Wikipedia zählt ä, ö und ü als ae, oe, ue und platziert das Eszett auf dem viertletzten Platz der übriggebliebenen 27 Buchstaben. Im Scrabble fehlt das Eszett, weil's Großbuchstaben sind, und ä und ü sind unter den letzten acht, ö unter den letzten vier. |
Geschrieben um 23:07 am 01.05.2011 | Zitat | Editieren | Löschen | |
Mitglied Baby Gumby Beiträge: 6 | Edit: Mein schönes "$" druckt prima, aber haut leider nicht mit der Eingabe hin. Showstopper? Das war verständlich Hoffe ich. Zwecks Kontrolle: Ausgabe: Also in Inform6 sind die @00 die "[variable]" in Inform7. Allerdings nur mit Strings, die man vor dem Drucken da reintut. Und Deform klinkt sich vor das Drucken und schreibt passende Endungen da rein, je nach Fall, Geschlecht und Modus (ich nenn das mal magisch^^). In Inform7 geht das mit Rule for printing the name of a thing: Und kombiniert ist das nette daran, wenn ich dadrin [^] einfüge, wird das nochmal ausgewertertet, bevor Inform6 das zu sehen kriegt. let d be an indexed text; let d be "[printed name]"; replace the regular expression "\$" in d with "[^]"; say "[d]"; Da geht dann als printed name "blau$ Foo" rein, das say sieht "blau[^] Foo", das geht an inform6's print "@00", und vorher war deform da und hat eine passende Endung nach @00 geschrieben. Nun hoffe ich das stimmt so und ich hatte bei blau nicht bloss Glück ^^ Eingabe: Puuuh, was für Klimmzüge kleine Speicher erforderten... Und wie clever manche Leute solche Konzepte ergänzen Ich überlegte kurz, wieviel Platz "" benötigt, wäre "a" statt "ae" genauso kompakt? Weil das kann man relativ sicher in beide richtungen umwandeln. Wahrscheinlich braucht es, weil nie benutzt, eher 5 chars... Stattdessen verwandle ich ae für die Ausgabe doch zu ä. Ausser, etwas ist selbstumlautend. Damit bleiben Feuerwehrleute erkennbar und rötliche Feuerwehrleute müssen einen expliziten printed name verwenden. Da dürfte der Aufwand proportional zur Häufigkeit sein. (Und ae ist doch gewohnter als a*). Eventuell könnte das wacklig werden, wenn irgendeine Automatik automatisch was anhängt. Zb "blau" zu "blaue". Im folgenden Code wird deshalb zuerst die Umlaut-umwandlung gemacht und danach "$"->"[^]", dadurch wird das "ue" in "blaue" nicht nochmal umgewandelt. Noch was kritisches fällt mir gerade nicht ein. Und nun gucke ich mal, ob ich das edeutsch (frei nach denglisch) dann lesen kann Und verschiebe ß auf ein anderes Mal. Achso, und findet ihr das schlimmer als lauter printed name oder doch nicht? ^^
|
Geschrieben um 07:34 am 02.05.2011 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 634 | Bevor Du jetzt hier ewig weitermachst: Verrenn Dich bitte nicht in Deine scho*n$ neu$ Syntax. Ich glaube nicht, dass jemand hier daran interessiert ist. Die I7/GerX-Autoren haben sich an die redundante Definition gewöhnt. Wenn Du Deine Syntax allerdings als sportliche Herausforderung betrachtest, sei es Dir ungenommen, damit zu experimentieren. Dann solltest Du Dir aber das DM4 (Designer's Manual, 4th Edition) und die Z-Code-Spezifikation selbst aneignen. Wie Du schon festgestellt hast: So ganz trivial ist das alles nicht. Für die Forumsleser sind Deine Gedanken zur neuen Syntax auch erst interessant, wenn die Syntax nutzbar ist. Hier alle Zwischenschritte zu posten ist ein wenig zu viel des Guten. (Langgediente Foprumshasen wissen auch, dass Projekte, die enthusiastisch begonnen wurden und wortreich im Forum angekündigt wurden, meist eine kurze Lebensdauer hatten.) Nichts für ungut. |
Geschrieben um 12:38 am 02.05.2011 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 326 | Kleiner Tipp am Rande, bei all der Diskussion: Mit etwas Geschick kann man sich einiges an Tastenanschlägen sparen, in folgendem Beispiel ist das eigentliche Objekt nur "zweimal" erwähnt. Die Understand-Definition kann eh nur ganz selten umgangen werden, da in einem sauber implementierten Spiel bei fast jedem Objekt zahlreiche Synonyme gefragt sind ... Beispiel:
Denglisch mag ich gar nicht, weil sich Code und Text unangenehm durchmischen. -- MI |