if-de :: Forum Foren-Übersicht
Autor Nachricht
<  unbenennbares Problem
proc
BeitragVerfasst am: Mi, 13 März 2013 - 0:56  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 08.12.2009
Beiträge: 890
Wohnort: Berlin

Ich werd wahnsinnig, jetzt geht's bei mir wieder auch mit vertauschten Includes. Was ist denn das für ein Unsinn?
Jedenfalls konnte ich endlich Version 7 of Basic Screen Effects SP by Emily Short ergoogeln, das ist eine spanische Erweiterung die BSE mit ein paar Specials anreichert. Wo kommt denn das her??? Dein Spiel MUSS mit

Code:
Include Version 7 of Basic Screen Effects by Emily Short

ohne "SP" laufen, sonst stimmt da was nicht (SP läuft vermutlich nur mit einer Spanischen Spracherweiterung korrekt.)
_________________
interactive fiction database
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Rabea
BeitragVerfasst am: Mi, 13 März 2013 - 1:03  Antworten mit Zitat
Wasserträger
Wasserträger


Anmeldungsdatum: 25.02.2013
Beiträge: 36
Wohnort: Bielefeld

Also nach der Extension muste ich auch lange suchen. Komischerweise habe ich die Version 7 ohne SP nicht gefunden. Egal wo ich gesucht habe und dann ist mir rein zufällig die SP in die Hände gerutscht, auch durch googeln.

Ich habe jetzt auf meinem Rechner Inform komplett platt gemacht (alles gelöscht, samt jeglicher Unterordner) und wieder neu installiert.

Dieses mal habe ich einzig und allein nur die deutsche Erweiterung installiert, keine BSE.
Habe dann das beispiel von Mikawa wieder ausprobiert und nur in den Quelltext "Include BSE...bla" reingeschieben (ohne sie zu installieren) und bei mir werden zwar die Befehle etc erkannt, keine Fehlermeldung, aber das Spiel läuft trotzdem nicht.... immer wieder hängt es sih bei der Frage auf.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Mischa
BeitragVerfasst am: Mi, 13 März 2013 - 8:10  Antworten mit Zitat
Abenteurer
Abenteurer


Anmeldungsdatum: 05.03.2008
Beiträge: 285
Wohnort: Wien

Rabea hat folgendes geschrieben:
SE.
Habe dann das beispiel von Mikawa wieder ausprobiert und nur in den Quelltext "Include BSE...bla" reingeschieben (ohne sie zu installieren) und bei mir werden zwar die Befehle etc erkannt, keine Fehlermeldung, aber das Spiel läuft trotzdem nicht.... immer wieder hängt es sih bei der Frage auf.


Hast du jetzt die Includes in der von proc geschriebenen richtigen Reihenfolge eingebunden?

proc (frei zitiert) hat folgendes geschrieben:
Include basic screen effects by emily short.
Include German by Team Gerx.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Rabea
BeitragVerfasst am: Mi, 13 März 2013 - 8:36  Antworten mit Zitat
Wasserträger
Wasserträger


Anmeldungsdatum: 25.02.2013
Beiträge: 36
Wohnort: Bielefeld

Habe beide Reihenfolgen ausprobiert und da kommt immer das gleiche bei rum.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Mikawa
BeitragVerfasst am: Mi, 13 März 2013 - 8:50  Antworten mit Zitat
Abenteurer
Abenteurer


Anmeldungsdatum: 03.09.2009
Beiträge: 442
Wohnort: Cham

Das Problem dürfte ziemlich weit in die Tiefen des Systems gehen.
Die Reihenfolge der Einbindung spielt hier eine untergeordnete Rolle. Nach meinen Tests crasht der Zoom Interpreter auf OSX, und Git und Glulxe unter WIN bringen eine Endlosschleife bei der consents Abfrage. Seltsam, seltsam ........... Hilfe, wo ist der Debugger für I7 ???

Edit: es hat nicht mal was mit BSE zu tun. Auch ohne die Extension crasht es. Es genügt, in der Statuszeile eine Textersetzung in [] Klammern einzusetzen, kombiniert mit der consents Abfrage. Es wird immer seltsamer ...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Martin
BeitragVerfasst am: Mi, 13 März 2013 - 9:24  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München

Hmmm. Das scheint mir ein Bug in YesOrNo zu sein, obwohl mir nicht ganz klar ist, wieso das nur bei GerX auftritt, denn GerX fasst weder YesOrNo noch DrawStatusLine an.

In YesOrNo wird eine Spielerabfrage mit read eingelesen:

Code:
[ YesOrNo i j;
    for (::) {
        if (location == nothing || parent(player) == nothing)
            read buffer parse;
        else read buffer parse DrawStatusLine;
        j = parse->1;

        if (j) { ! at least one word entered
            i = parse-->1;
            if (i == YES1__WD or YES2__WD or YES3__WD) rtrue;
            if (i == NO1__WD or NO2__WD or NO3__WD) rfalse;
        }
        L__M(##Quit, 1); print "> ";
    }
];

Dieser Code ist schon vom ausge-ifdefften Glulx-Teil befreit. Hier wird das einzige Mal im I6-Quellcode die Form read buffer parse routine verwendet, die nicht dokumentiert ist. (Normalerweise wird keine Routine angegeben.) Wenn man eine Routine angibt, wird diese vor dem Einlesen ausgeführt. Das ist wahrscheinlich ein Relikt aus frühen Inform-Versionen.

Wenn man den Code nun abändert und in das Spiel einsetzt, scheint es zu funktionieren:

Code:
Include (-

[ YesOrNo i j k;
    for (::) {
        if (location ~= nothing || parent(player) ~= nothing) {
            DrawStatusLine();
        }
        read buffer parse;
        j = parse->1;
       
        if (j) { ! at least one word entered
            i = parse-->1;
            if (i == YES1__WD or YES2__WD or YES3__WD) rtrue;
            if (i == NO1__WD or NO2__WD or NO3__WD) rfalse;
        }
        L__M(##Quit, 1); print "> ";
    }
];

-) instead of "Yes/No Questions" in "Parser.i6t".

Was da aber genau nicht funktioniert hat, ist mir schleierhaft. Das Zentrieren mit CenterPrint verwendet einen eigenen Puffer. Und eigentlich ist die neue YesOrNo nicht viel anders als die bisherige.

Ich habe aber eine Vermutung: Der einfache Code

Code:
Array buffer -> 20;
Array parse --> 5;

[ sub; rfalse; ];

[ main;
    read buffer parse sub;
];

erzeugt folgende Opcodes:

Code:

[ main
   @store       TEMP4 buffer;
   @storeb      TEMP4 1 0;
   @call_1n     sub;
   read         TEMP4 array -> TEMP1;
   rtrue;
];

TEMP1 und TEMP4 sind globale Variablen, die Inform intern als Register verwendet. Dadurch, dass buffer zunächst (ohne ersichtlichen Grund) auf das Register TEMP4 gelegt wird, das dann stattdessen verwendet wird, kann es passieren, dass der Textpuffer beim Aufruf von read nicht mehr buffer ist, da die Routine sub das globale Register TEMP4 überschreiben kann.

Blöd daran ist, dass das oben als vier Opcodes umgesetzte read für den Autoren atomisch ist: Man kann sich den Puffer zwischen Routinenaufruf und einlesen nicht mehr anzeigen lassen. Außerdem werden die Register TEMP1 bis TEMP4 nur versteckt vom Compiler verwendet. Allein am I6-Code kann man ein Überschreiben nicht erkennen.

Dabei wäre die Anweisungsfolge
Code:

   @storeb      buffer 1 0;
   @call_1n     sub;
   read         buffer array -> TEMP1;

ökonomischer und sicherer gewesen. Die eigentlich äquivalente und auch verständlichere Variante

Code:

[ main;
    sub();
    read buffer parse;
];

erzeugt:

Code:

[ main
   @call_1n     sub;
   @store       TEMP4 buffer;
   @storeb      TEMP4 1 0;
   read         TEMP4 array -> TEMP1;
   rtrue;
];

Das unselige Register ist zwar immer noch da, aber wenigstens bekommt niemand zwischen der Belegung und der Verwendung die Möglichkeit, dieses globale Register zu korrumpieren.

Ich schlage vor, die YesOrNo in GerX anzupassen und auch Oxford zu benachrichtigen, weil (a) die (vermulich als deprecated gekennzeichnete) Umsetzung von read buffer parse routine im Compiler fehlerhaft ist und (b) die Standard-Lib dieses gefährliche Konstrukt auch noch verwendet.
_________________
Every silver lining has a cloud.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ChristianB
BeitragVerfasst am: Mi, 13 März 2013 - 10:30  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 05.05.2004
Beiträge: 633
Wohnort: Hamburg

Es ist schon merkwürdig: Ich kann den Fehler überhaupt nicht reproduzieren. Aber da er offenbar nur mit GerX auftritt, könnte es an der Ausgabe liegen. Die Ausgabe eines Objektnamens ohne Artikel ("[Objektbezeichner]") wird in GerX etwas anders gemacht. Ich kanns jetzt gerade nicht testen, aber versucht doch mal die Ausgabe über den printed name zu realisieren:

center "[printed name of location]" at row 1;
_________________
Worichtung willst du ingehen?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Martin
BeitragVerfasst am: Mi, 13 März 2013 - 10:32  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München

Nachtrag: Warum tritt der Fehler bei GerX auf, aber nicht bei der Original-Lib? Das gobale Register TEMP4 tritt auch noch an anderen Stellen auf:

Code:

[ main;
    string 0 "Bonanza!";
];

wir kompiliert zu:

Code:

[ main
    @loadw 0 12 -> TEMP4
    @storew TEMP4 0 abbrev{"Bonanza!"};
    rtrue;
];


(Das ist jetzt noch komplizierter als vorher: Es gibt 96 sogenannte Abbreviations in der Z-Maschine. 32 davon kann man in Inform über die Syntax "@xx" ausgeben lassen und mit string wie oben setzen. Die 64 anderen werden über Abbreviate aktiviert, wenn man mit economic mode mit -e kompiliert. Ein besonderer Speicherbereich, der abbreviations table, gibt an, wo man nach der passenden Abkürzung zu suchen hat. Die Adresse dieser Tabelle steht im Header an der Stelle 0-->12. An dieser Stelle legt Inform den vorkompilierte String "Bonanza!" ab.)

Die Original-Lib verwendet die Anweisung string nie. GerX hingegen verwendet die Abbreviations sehr häufig, insbesondere bei der Ausgabe der Objekte, wo die Endungen als Abkürzungen abgelegt sind.

Meine Vermutung ist, dass die übliche Routine für die Statuszeile einfach den Namen des Aufenthaltsorts ohne Beugung ausgibt. Die Anweisung "[location]" in Rabeas Code (und nicht etwa das Zentrieren, wie vermutet) macht dann Ärger, denn sie verwendet die Ausgaberoutinen der Lib, in der bei GerX halt die Endungen gesetzt werden.

(Ich wollte das mit einem Beispiel mit Stuhl testen, aber "Zelle (auf dem Stuhl)" wird nur im Raumtitel vor der Beschreibung ausgegeben, die Statuszeile heißt einfach "Zelle".)

Außerdem ist auch diese Verwendung von TEMP4 überflüssig. Man könnte string ohne globales Register sauberer umsetzen als:

Code:

[ main
    @loadw 0 12 -> sp
    @storew sp 0 abbrev{"Bonanza!"};
    rtrue;
];

_________________
Every silver lining has a cloud.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Mikawa
BeitragVerfasst am: Mi, 13 März 2013 - 10:41  Antworten mit Zitat
Abenteurer
Abenteurer


Anmeldungsdatum: 03.09.2009
Beiträge: 442
Wohnort: Cham

Zitat:
Ich kanns jetzt gerade nicht testen, aber versucht doch mal die Ausgabe über den printed name zu realisieren:


Du hast recht, Christian.
Es liegt an der Printausgabe der deutschen Textersetzungen, denn ein [printed name of location] in der Statuszeile funktioniert einwandfrei.

Übrigends: es hat nichts mit BSE zu tun, denn auch mit say... statt center... geht es nicht.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Martin
BeitragVerfasst am: Mi, 13 März 2013 - 10:48  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München

Okay, bevor hier noch mehr Cross-Posts auftauchen, hier das TL;DR meiner zugegegebenermaßen etwas langen Ausführungen:

Das Verhalten liegt daran, dass in YesOrNo eine alte Syntax für read verwendet wird, die ein globales Register benutzt. Dasselbe Register wird für string, also das Setzen von @00 bis @31 verwendet, daher haut's die Objektausgabe während des Einlesens, das durch die alte Syntax auch die Ausgabe der Statuszeile umfasst, auf die Nase.

Das Problem sollte in der Original-Lib gelöst werden. Als Workaround kann man die YesOrNo, die ich oben angegeben habe, einbinden.

Idealerweise sollte man aber auch den Compiler anfassen, der das Register in beiden Fällen unnötigerweise belegt.
_________________
Every silver lining has a cloud.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
proc
BeitragVerfasst am: Mi, 13 März 2013 - 13:07  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 08.12.2009
Beiträge: 890
Wohnort: Berlin

ChristianB hat folgendes geschrieben:
Es ist schon merkwürdig: Ich kann den Fehler überhaupt nicht reproduzieren.

Ich habe noch zwei Ergänzungen, auf die ich mir keinen Reim machen kann.
1. Gestern Abend konnte ich Mikawas Beispiel erst reproduzieren, habe dann nur die Includes vertauscht, schließlich lief das Beispiel in Originalfassung wie gewünscht. Seitdem konnte ich den Fehler auch mit zurückgetauschten Includes auf Win7/6G60 nicht mehr reproduzieren, wohl aber auf Ubuntu und XP. Das ist beunruhigend.
2. Rabeas Fehler entstand durch printed name-Anweisungen *vor* der Objektdeklaration, in der richtigen Reihenfolge funktioniert alles wie gedacht. I7 sollte solche Zuweisungen stacken bis die Objektdeklaration kommt und dann erst ausführen (obwohl eine Fehlermeldung in solchen Fällen besser wäre), aber das hat eben auch den Sinn, Rules auf oder Aktionen mit Objekten vor der Objektdeklaration anlegen zu können. Auch in Mikawas Beispiel bringt eine Lab-deklaration am Ende und printed name-Zuweisung am Anfang nichts durcheinander, in Rabeas würde ich im ersten Debugging-Durchgang mal ein hakeliges Zusammenspiel zweier Extensions als Ursache vermuten.
_________________
interactive fiction database
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ChristianB
BeitragVerfasst am: Mi, 13 März 2013 - 22:37  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 05.05.2004
Beiträge: 633
Wohnort: Hamburg

Martin hat folgendes geschrieben:
Das Problem sollte in der Original-Lib gelöst werden. Als Workaround kann man die YesOrNo, die ich oben angegeben habe, einbinden.

Danke, Martin! Ich habe Deine abgeänderte YesOrNo() für GerX übernommen und eine Testversion erstellt.

http://ifiction.pageturner.de/inform7/test/German_3-130313--TEST.zip

(Ich habe bei der Gelegenheit die Yes-Or-No-Words-Abfrage von den sperrigen *_WD-Konstanten auf die Is_*_word()-Routinen verlegt.)

Martin hat folgendes geschrieben:
Ich schlage vor, die YesOrNo in GerX anzupassen und auch Oxford zu benachrichtigen, weil (a) die (vermulich als deprecated gekennzeichnete) Umsetzung von read buffer parse routine im Compiler fehlerhaft ist und (b) die Standard-Lib dieses gefährliche Konstrukt auch noch verwendet.

Edit: GerX ist angepasst; bei Admiral Nelson müsste jemand Meldung machen, der versteht, was da schiefläuft (also ich schonmal nicht). Wie kann man sich eigentlich diese compilierten Opcodes anzeigen lassen?
_________________
Worichtung willst du ingehen?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Martin
BeitragVerfasst am: Do, 14 März 2013 - 14:37  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München

ChristianB hat folgendes geschrieben:
Ich habe Deine abgeänderte YesOrNo() für GerX übernommen und eine Testversion erstellt.

Prima, danke. Vielleicht kann Rabea ja mal diese Version testen und schauen, ob auch das eigenartige Verhalten, dass der Anfangsraum der Sonnenhügel ist, damit behoben ist. Der Fix bezieht sich eigentlich nur auf YesOrNo.

ChristianB hat folgendes geschrieben:
GerX ist angepasst; bei Admiral Nelson müsste jemand Meldung machen, der versteht, was da schiefläuft (also ich schonmal nicht).

Kann ich machen, obwohl ich befürchte, dass mein Beitrag wieder als "helpful" eingestuft wird, und was das heißt, weiß ich mittlerweile. :-)

ChristianB hat folgendes geschrieben:
Wie kann man sich eigentlich diese compilierten Opcodes anzeigen lassen?

Das geht mit -a und -t, -a schreibt die Opcodes in Inform-Syntax (allerdings ohne @) heraus, mit -t bekommt man zusätzlich noch die Darstellung als Hex-Zahlen, wie sie tatsächlich in der z5/z8-Datei steht. (Manche Werte, vor allem die Adressen von Routinen und Texten, sind zum Zeitpunkt des Assemblierens noch nicht bekannt. Sie werden nachträglich korrigiert - Backpatching sagt das TM dazu - und haben dann im tatsächlichen Story File andere Werte. Man kann die Bedeutung der Werte aber gut aus dem Kontext erkennen.)

Nachträglich kann man ein Spiel mit txd dekompilieren.

Die Ausgabe der Opcodes erzeugt aber ganz schön viel Zeug. Wenn man im Strict Mode kompiliert, werden auch alle Routinen der Runtime Veneer angezeigt, die zum Beispiel die Bereichsüberschreitungen bei der Feldzuweisung mit -> oder --> überprüfen und und die Programming Errors bescheren. Selbst ein unscheinbares Programm kann so ganz schön viel Code erzeugen.
_________________
Every silver lining has a cloud.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ChristianB
BeitragVerfasst am: Do, 14 März 2013 - 15:25  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 05.05.2004
Beiträge: 633
Wohnort: Hamburg

Martin hat folgendes geschrieben:
Kann ich machen, obwohl ich befürchte, dass mein Beitrag wieder als "helpful" eingestuft wird, und was das heißt, weiß ich mittlerweile. :-)

Seidem alle im Inform-Mantis-Bugtracker-System mitlesen können, bleibt es ja etwas seltener beim helpfully yours. Ein Versuch ist es wert.

(Und den letzten Beitrag von Dir, den ich mitbekommen habe, hat Graham ja übernommen, obwohl er ihn helpful fand.)
_________________
Worichtung willst du ingehen?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Martin
BeitragVerfasst am: Do, 14 März 2013 - 16:04  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München

Okay, ich habe die Gottesanbeterin mal gefüttert.

Gar nicht helpful war leider auch, was ich oben geschrieben habe. Die Korrektur für den bisherigen Code:

Code:

    if (location == nothing || parent(player) == nothing)
        read buffer parse;
    else read buffer parse DrawStatusLine;

muss natürlich heißen:

Code:

    if (location ~= nothing && parent(player) ~= nothing) {
        DrawStatusLine();
    }
    read buffer parse;

Die Negation von (a || b) ist (~~a && ~~b). Oben habe ich die nun verneinte Bedingungen noch mit Oder verknüpft.

Praktisch hat das aber wohl wenig Bedeutung, weil in einem normalen Spiel wohl eh weder (location == nothing) noch (parent(player) == nothing) ist.
_________________
Every silver lining has a cloud.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Beiträge der letzten Zeit anzeigen:   
Alle Zeiten sind GMT + 1 Stunde (MEZ)

Nächstes Thema anzeigen
Vorheriges Thema anzeigen
Seite 2 von 3
Gehe zu Seite Zurück  1, 2, 3  Weiter
if-de :: Forum Foren-Übersicht  >  Inform & Glulx

Neues Thema eröffnen   Neue Antwort erstellen


 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.



Kontakt: Administrator

Powered by phpBB and NoseBleed v1.05