Geschrieben um 10:59 am 14.02.2005 | Zitat | Editieren | Löschen | |
Mitglied Dr Gumby Beiträge: 181 | Hallo, ich bin da auf einen Bug in der Routine ProcessGermanVerbs gestoßen. (Email an Max ist unterwegs) Gibt man ein Verb ein, dass mit einem "e" beginnt, wird dieses auch abgeschnitten und so in den buffer für den Befehl "again" abgelegt. Gibt man "g" ein, erkennt der Parser das Verb nicht mehr. Da in meinem Spiel unbekannte Wörter und Verben ausgegeben werden, kam eben die Meldung, "Ich kenne das Verb "rzähl" nicht" (anstatt erzähl). Unter Z-Code läuft es (das nur zur Info) hier der Code von Zeile 363 bis 375 aus german.h:
|
Geschrieben um 12:53 am 14.02.2005 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 634 | Kris:
Und das löst das Problem? Die Zählerveriable x sollte eigentlich immer größer als Null sein, weil sie einfach den Wert hat, auf dem sie nach Durchlaufen der Schleiße stehen geblieben ist. Die Bedingung, dass es sich um das erste Wort handelt, steht in flag: Ist sie Null, war's das erste Wort, denn wenn es ein Wort nach einem Komma war, wird flag auf eins gesetzt. Etwas kompliziert, finde ich. Der Fehler liegt hier woanders: Nachdem du 'g' eingegeben hast, wird die alte Eingabe, buffer3, zurück in den buffer kopiert. Dann wird die Routine LanguageToInformese aufgerufen, allerdings bevor der neu eingelesene Buffer in Tokens zerlegt wird. parserm.h, Zeile 1183 ff.
Das heißt also, im Buffer steht 'erzähle dem mann was vom pferd', im Feld parse, in dem die Wörter abgelegt werden, steht immer noch 1, 'g//', 1, 5. Dummerweise greift LTI aber auf parse zu, und liest den falschen Input. verbend ist 5, und dort steht das 'e' von 'erzähle'. Wenn du 'again' oder 'nochmal' sagst, solltest du den Fehler nicht mehr sehen. Warum läuft es aber korrekt im z-Code? Tja, um 'e', 'se', 'ne' als englische Synonyme für die östlichen Himmelsrichtungen zuzulassen, gibt es dort die Abfrage, dass das Wort länger als 2 Buchstaben lang sein muss. Diese Abfrage gibt es im Glulx-Code auch:
Nur ist sie nicht richtig: Es wird geprüft, ob das erste Wort hinter der zweiten Stelle anfängt, und das tut es bei Glulx immer. Hier müsste
stehen, vgl., man kann's offensichtlich gar nicht oft genug posten, Roger Firths Inform FAQ. Deshalb mein Vorschlag: Probiere einmal, den Input vor und nach der Analyse zu "tokenisieren": parserm.h, Zeilen 1265 ff
Der von dir zitierte Code hat übrigens noch einen Fehler: Anstatt zu prüfen, ob ein Wort ein Komma ist, wird geprüft, ob der Startpunkt im Buffer 44 ist, wieder eine Verschiebung der Indizes. Zudem würde hier eine Vokabel als ZSCII-Zeichen abgefragt. Richtig müsste es (vermutlich) heißen:
Probiere dies bitte mal aus, es ist nicht getestet. Der Fehler tritt übrigens auch in der z-Version auf, wenn man nämlich ein Verb benutzt, dessen fünfter Buchstabe 'e' ist und 'again' sagt, oder bei einem 'e' an siebter Stelle und 'nochmal', vgl. diese Passage aus Wilhelm Tell:
|
Geschrieben um 14:36 am 14.02.2005 | Zitat | Editieren | Löschen | |
Mitglied Dr Gumby Beiträge: 181 | Vielen Dank für den ausführlichen Bericht, konnte natürlich nicht alles in der Mittagspause umsetzen :-) Martin:
x entspricht beim ersten Parsen der Anzahl der "Wörter", beim "again" aber ist es 0 (da parse-->0-1 ebenfalls 0 ist). Ich werde heute abend gerne Deinen Code testen und melde mich dann wieder. Dank und Gruß Kris |
Geschrieben um 10:52 am 15.02.2005 | Zitat | Editieren | Löschen | |
Mitglied Dr Gumby Beiträge: 181 | Also, ich habe das gestern Abend mal getestet: Martin:
|
Geschrieben um 15:19 am 15.02.2005 | Zitat | Editieren | Löschen | |
Mitglied Prof Gumby Beiträge: 634 | Zitat:
Okay, da war ich etwas zu schnell, ich hatte das buffer übersehen. Der Code ist richtig, wie er ist: Es wird geprüft, ob am Wortanfang das Zeichen ',' steht. Und da das ein delimiter ist, ist damit das ganze Wort bestätigt. Ich wollte wohl folgendes sagen:
Entschuldigung. Kris:
Ja, mache ich. |