Script reißt X2 in die Tiefe (Absturz auf den Desktop)

[ManfredP]

Hallo,
habe da ein Setup-Script, dass mir regelmäßig X2 auf den Desktop reißt
Weis ehrlich nicht, was da los ist. Hier zunächst mal der Code von dem Ding:

Code: Select all

Nachdem ich im Source-Code noch nicht so viele Kommentare drin habe, sind sie hier nachgerüstet
Eigentlich setup.TradewithCentral.xml, aber mit dem Namen läuft das Spiel nicht mehr
      Script a.b.TradewithCentral
      Version: 100
      for Script Engine Version: 25
      Description
      Auto-Setup on this addition. 
      Arguments
      Source Text
      001   * First the language file load. This will load it from nn2051.xml with  nn the
      002   * language code
Hoffe, die ID ist frei ...
      003   load text: id=2051
      004   * Some Variables to be initialized and perhaps changed later
      005   $Stationtype = Freie Argon Handelsstation
Das heist intern 'Transporter für Stationen' und wird über die 2051-er benannt.
      006   $Upgrade = ReadText17-7000703
Das ist nur vorläufig
      007   $Price = 152766
Der war für die Schleife. Ist übriggeblieben, aber kaum der Fehler, um den es hier geht
      008   $Switch = [TRUE]
      009   * Now the connection to the correct ware
Das ist auch im 2051-er benannt. Das File kommt mit
      010   set script command upgrade: command=COMMAND_TYPE_STATION_30  upgrade=$Upgrade
      011   * You have to be able to buy it anywhere
Die Map ausmessen
      012   $SizeX = get max sectors in x direction
      013   $SizeY = get max sectors in y direction
Und durchscannen. Der Switch ist noch übriggeblieben von einer früheren Variante. Bedeutet aber eigentlich nur, dass nur eine Station gefunden wird, statt alle
      014   while $SizeX AND $Switch
      015    dec $SizeX = 
Vorsicht ist alles ...
      016 @  = wait 1 ms
      017    while $SizeY AND $Switch
      018     dec $SizeY = 
      019 @   = wait 1 ms
Damit sollte eigentlich der richtige Sektor gefunden werden
      020     $Sektor = get sector from universe index: x=$SizeX, y=$SizeY
Wenn diese Koordinate hier leer ist, nächste Koordinate
      021     skip if $Sektor
      022      continue
Ansonsten den Nullpunkt im Sektor markieren
      023     $Pos =  array alloc: size=3
      024     $Pos[0] = 0
      025     $Pos[1] = 0
      026     $Pos[2] = 0
Finde eine Frei Argon Handelsstation in diesem Sektor
      027     $Station =  find station: sector=$Sektor class or type=$Stationtype race=Argonen flags=[Find.Friend] refobj=null maxdist=70000 maxnum=1 refpos=$Pos
Gefunden ?
      028     if $Station
Besitzer sichern ...
      029      $Owner = $Station -> get owner race
Umschalten ...
      030      $Station -> set owner race to Player
Ware einbringen ...
      031      $Station -> add product to factory or dock: $Upgrade
      032      = $Station -> add 1 units of $Upgrade
und Preis setzen ...
      033      $Station -> set price of ware $Upgrade to $Price Cr
Jetzt Station wieder zum alten Besitzer zurück
      034      $Station -> set owner race to $Owner
      035      $Switch = [FALSE]
      036      continue
      037     end
      038    end
      039   end
      040   return null

Der Zweck der Übung ist, der Engine eine neue Ware bekannt zu machen (ich habe sie 'Transporter für Stationen`' genannt und auf die Position 7000803 gesetzt), diese Ware kaufbar zu machen, sie in den Vorräten anzulegen und den Preis anzulegen. Später soll ein neues Commando (das Script dazu existiert schon) von dieser Ware abhängen und die Funktion dieses Transporters erzeugen. Der Hintergrund des Ganzen ist eigentlich mein etwas schwächelnder Rechner. Er ist zu lahm, als das ein paar Dutzend Schiffe in einem einzigen Sektor einen Kreisverkehr mit Waren erzeugen könnten. Wenn dann noch ein paar Kämpfe toben (was eben vorkommt), schläft die Kiste ein. Also habe ich den Transporter aus den Schiffen aufgegriffen und ein automatisiertes Handelsscript darum verfasst. Es kostet Geld und Energiezellen, diesen Transporter zu benutzen -es ist also kein Cheat, denke ich Dafür wird die Ware (nur im gleichen Sektor, der Test fehlt im Moment noch) von einer Station zur anderen 'gebeamt' und braucht kein Schiff. Das automatisierte Script kann immer nur mit einer Ware umgehen und wird als Task ab ID 100 aufwärts gestartet, daher kann es Mehrere davon geben. Es muss auf der Station laufen, die die Waren produziert oder braucht und braucht zusätzlich eine Zentralstation als Lager für den ganzen Kram. Das Setup soll den Transporter (ein Gerät von 1/S-Größe) auf allen argonischen Handelsstationen einsetzen und verfügbar machen. Um sie (unabhängig von der Map, also auch bei MODs) aufzufinden, wird ein Scan durch die ganze X2-Galaxis gemacht. Dann wird auf der Station (sofern gefunden) die Ware eingerichtet, installiert und der Bestand aufgestockt. Weil es mit der normalen Einstellung nicht klappte, habe ich den Besitzer der Station temporär auf den Spieler gestellt (und hinterher wieder zurück). Zwischenfrage: Weis jemand, ob das wirklich notwendig ist oder war ein anderer Fehler schuld daran, dass es ohne diese Besitzeränderung nicht klappte, die Ware einzurichten)?
Dabei scheint es wohl zu dem Fehler zu kommen. Da es als Setup läuft, kann ich keine Fehlermeldungen erzeugen, ich weis nicht, was dann schon läuft. Ich weis auch gar nicht, wo ich anfangen soll zu suchen, da ich eigentlich alle Fehler, die mir einfallen, abgefangen habe (vor allem den Klassischen, dass es den Sektor nicht gibt).

Kann mir jemand helfen
Ich werde natürlich parallel auch noch weiter suchen und hier ergänzen, wenn mir dabei noch was auffällt. Ach ja, wie ist das eigentlich mit externen Log-Files: werden die bei einem Absturz noch geschlossen oder sind die witzlos, weil grundsätzlich leer? Weis das jemand?

Ach ja, btw.: Sind die Page-ID 2051 und die Text-IDs 100/101 noch frei?

Tschüß

ManfredP

[MADxHAWK]

Hi,

eine ursache könnte sein das du das Commando für eine station an eine ware gebunden hast, da man meines wissens nach nur schiffscommandos an eine ware binden kann. probier es mal ohne die ware

( set script command <commando> upgrade = [TRUE] )

ausserdem Kannst du den Preis einer Ware nur im vordeffinierten Rahmen bestimmen. Kannst es ja so lösen das bei ersten start des kommandos ein gewisser betrag fällig wird und das Upgrade nicht benötigt wird.



Greetz
MADxHAWK

[ManfredP]

Hi,

eine ursache könnte sein das du das Commando für eine station an eine ware gebunden hast, da man meines wissens nach nur schiffscommandos an eine ware binden kann. probier es mal ohne die ware

( set script command <commando> upgrade = [TRUE] )

Das wäre natürlich ein möglicher Grund. Insbesondere denkbar durch einen speziellen Fehler, den der Autor in seinem MSCI-Handbuch gemacht hat: Er hat nämlich 'set ship command upgrade' geschrieben, der Befehl heist aber in der Liste 'set script command upgrade'. Ich hatte das für einfach nur einen Fehler gehalten, aber so betrachtet, vielleicht hatte der Autor so sehr im Kopf, dass der von ihm verwendete Name besser wäre angesichts vorhandener Beschränkungen, dass er ihn ganz in Gedanken auch so geschrieben hat.

ausserdem Kannst du den Preis einer Ware nur im vordeffinierten Rahmen bestimmen.

Es ist aber eine Ware, die es eigentlich gar nicht gibt. In der Warenliste stehen doch so einen ganze Anzahl ReadText17-xxx-Zeilen. Das sind natürlich Objekte, zu denen in keinem t-File Beschreibungstexte vorhanden sind, also Waren, die zwar irgendwann mal definiert, aber nie benutzt wurden. Ich hätte nicht erwartet, dass es dazu auch solche Preisgrenzen gibt. Wo stehen die eigentlich, irgendwo muss die Engine die Werte doch herhaben? Ich kann mir bei den vielen Teilen irgendwie nicht vorstellen, dass die aus dem Source-Code stammen, also hardcodiert sind. Da sollte es doch irgendwo eine Tabelle geben, eventuell auch über solche ReadText-Zeilen festgelegt. Wenn das so sein sollte, könnte man die doch sogar ändern. Wie ist das eigentlich? Wenn es zweimal t-File-Zeilen zu der gleichen ReadText-Anweisung gibt, welche wird dann genommen? Die Erste, die Zweite oder kollidiert das?

Kannst es ja so lösen das bei ersten start des kommandos ein gewisser betrag fällig wird und das Upgrade nicht benötigt wird.

Klar geht das auch. Aber eine Ware, die man irgendwo im 'Laden' kauft und die einem dann die Möglichkeit zu diesem Vorgang eröffnet -das wäre doch irgendwie cooler, oder? Allerdings kann dass das Script natürlich auch zu Fuss abprüfen und, wenn die Ware fehlt, gibt's beim Start des Script 'ne Message, dass das so nicht geht.

Greetz
MADxHAWK

[ManfredP]

Hallo,
ich weis, ein Edit ist schöner, aber zwei gegensätzliche Aussagen in ein und demselben Text ...

Es geht um das t-File. Dazu habe ich nämlich inzwischen etwas herausgefunden, dass ich noch nicht so hundert-pro einordnen kann. Da brauche ich noch ein paar Info's von Leuten, die schon mal eine Komando-Ergänzung verfasst haben. Denn es geht ja, klarerweise. Nur wie, wurde mir durch meine Tests eher noch unklarer.

Zunächst allgemein: ein Languagefile (so nennt Fitzner, der das Handbuch geschrieben hat, die Dinger) wird per 'load text: id=<laguagefileid>'-Anweisung geladen. Danach aber taucht diese ID nicht mehr auf, page- und textid sind ja wieder was anderes. Schlussfolgerung: Sämtlichen Texte wandern, egal aus welchem File sie kommen, in eine große Liste und werden gemeinsam verwaltet. Wenn daher in einer Datei zum Beispiel page=20, text=20 benutzt werden und in einer zweiten Datei tauchen diese gleichen IDs erneut auf, dann kollidieren diese zwei Definitionen miteinander, auch, wenn sie aus verschiedenen Dateien im t-Verzeichnis (oder einem der pck-Pakete) stammen. Diese Kollision sollte kein Problem sein, sie tritt ja eigentlich oft auf. Nur genau da blicke ich nicht mehr so recht durch, denn nach meinem Eindruck geht es eben unter Umständen doch nicht.

Ich hatte ein Setup-Script geschrieben, das ist ja oben angegeben. Ein Vorläufer desselben enthielt nur die load text-Anweisung. Damit machte ich den Namen der neuen Ware bekannt, sodass er dann in den Listen und an der entsprechenden Stelle im Source-Code auch erschien -das war der Zweck der Übung.

Ich habe nun dieses einfache Setup-Script laufen lassen und danach gespeichert. Und dieses Savegame stürzte dann wieder ab. Da aber nur der load text drin stand in dem Setup, war das schwer zu verstehen. Darum habe ich einen Test gemacht. Ich schrieb ein Test-Script, das zu zwei text-IDs (100 und 101) unter einer pageID (10) einen ReadText machte und diese Texte dann als Nachricht verschickte. Die Nachricht enthielt nur diesen Text 'ReadText10-100' bzw. 'ReadText10-101', die beiden Text-Nummern gab es also noch nicht. Dann ergänzte ich dieses Auslesescript um eine load text-Anweisung auf die t-Datei, die diese beiden Texte definierte -mit dem fantasievollen Text 'Dies ist ein Test' und 'Dies ist noch ein Test'. Dieses Script gab die Texte korrekt wieder. Dann speicherte ich den Spielstand (nach dem load text) und startete diesen Spielstand neu. Anschließend entfernte ich die load text-Anweisung aus meinem Test-Script und ließ es ein drittes Mal laufen -jedoch eben ohne die load text-Anweisung. Aber die beiden Nachrichten enthielten trotzdem die beiden Test-Texte. Da es keinen Setup mit einer load text-Anweisung zu diesen beiden Texten gab, müssen die Testtexte im Savegame gespeichert werden. Das wird sicher auch bei meinem Kurz-Setup-Script so gewesen sein. Da das Setup-Script beim nächsten Laden auch wieder die load text-Anweisung zum gleichen t-File aufrief, wurden also diese ID's doppelt definiert. Und da im Setup ja sonst nichts drin war, kann es doch eigentlich nur diese Tatsache gewesen sein, die den Absturz verursachte. Wie aber machen das dann Andere? Es geht doch schließlich und wird wohl sicher auch nicht so kompliziert sein.

Kann mir dazu jemand was sagen?

Tschüß

ManfredP

[Chris Gi]

Hallo,

ich kann mir eigentlich nicht vorstellen, dass der Abbruch mit der 'load text'-Anweisung zu tun hat. Ich habe ein solches Phänomen, wie im letzten Post beschrieben, noch nie erlebt.
Mir ist es auch schon passiert, dass von verschiedenen Scripten die gleiche Text-/Page-ID-Kombination benutzt wurden. Dies hat dann dazu geführt, dass bei einem Laden der Text aus dem einen t-File, beim nächsten Laden dann der Text aus dem anderen t-File benutzt wurde. Aber zu einem Absturz hat dies nicht geführt. Dass nach dem Entfernen der 'load text'-Anweisung aus dem Setup-Script immer noch der Text richtig kommt, könnte darauf hindeuten, dass X2 die Texte beim Neuladen immer noch irgendwie im Speicher hat. Nach Verlassen und Neustarten von X2 sollten dann - wenn meine Vermutung stimmt - wieder die ReadText-Sachen kommen.

Mich wundern da eher andere Zeilen in Deinem Setup-Script:

029 $Owner = $Station -> get owner race
Umschalten ...
030 $Station -> set owner race to Player
Ware einbringen ...
031 $Station -> add product to factory or dock: $Upgrade
032 = $Station -> add 1 units of $Upgrade
und Preis setzen ...
033 $Station -> set price of ware $Upgrade to $Price Cr
Jetzt Station wieder zum alten Besitzer zurück
034 $Station -> set owner race to $Owner

Das ist natürlich schon heftig: einfach mal 'ne Argon Handelsstation dem Spieler zuordnen und wieder zurück, da kann ich mir schon vorstellen, dass das in die Hose geht. Ich würde mal hier alle Zeilen auskommentieren, bis auf die 'add product to factory or dock'-Anweisung und dann mal schauen, ob das Script dann funktioniert. Ich kann es jetzt nicht genau sagen, aber ich meine, in meinen Setup-Scripten verwende ich nur diese Anweisung. Das kann ich heute abend noch mal prüfen, wie ich das genau mache.
Es kann sein, dass das Hinzufügen der Ware aber auch nur über ein Egosoft-Script geht. Da gibt es eins, den genauen Namen weiß ich im Moment nicht und ich hab auch gerade kein X2 zur Hand, das heißt '!galaxyedit.add.ware' oder so. Das kannst Du statt der 'add product'-Anweisung mal probieren.

Und zum Preis: Diese Softwareerweiterungen sind in einer Datei namens TWareT.pck verankert. Da ist auch der Preis festgelegt. Die Preise können nur in einem Mod verändert werden. Aber da gibt es mehrere freie Waren, die 'ReadText-soundso', die alle verschieden teuer sind. Kannst ja mal ein paar ausprobieren, welche preislich am besten Deinen Vorstellungen entsprechen. Dann sparst Du Dir diese 'set price'-Geschichte, von der ich auch nicht weiß, ob die bei anderen Stationen als Spielerstationen funktionieren. Vielleicht stürzt das Ding ja ab, wenn Du die Station dann wieder der Originalrasse zuordnest.

Noch ein Hinweis: Gehört diese Erweiterung nicht eigentlich in ein Ausrüstungsdock?

[MADxHAWK]

Hallo,

also das ändern des besitzers einer KI Station ist normalerweise problemlos. Ich habe mir schön öffters bei scripten zum Test meiner Scripts Stationen von einem Volk "ausgeliehen", sprich mich als Eigentümer deffiniert und sie anschließend an das Volk zurückgegeben.
In diesem Fall ist es aber auch komplett unnötig den Besitzer zu ändern um eine Ware hinzu zu fügen.

Ich kann mir auch nicht vorstellen das das setupscript den spielstand zum absturz bring, da setupscripts NICHT im scriptcache abgespeichert werden. sie werden geladen, ausgeführt und terminiert. in den Savegames wird jedoch nur der Scriptcache mit gespeichert. ich würde also an deiner stelle mal alle deine Scripts überprüfen.

Was X auf jeden Fall zum absturz bringt ist die verwendung von XML steuerzeichen wie z.b. <> /

z.B. write to playerlog 'x<y'

wenn du solche Zeichen unbedingt verwenden willst musst du diese über ein Languagefile laden.

Greetz
MAD

[Chris Gi]

Jo,

da fällt mir ein, mir ist das X2 auch mal abgeschmiert, als ich vergessen hatte, eine id wieder mit Hochkomma abzuschließen. Ich hatte in der XML so was stehen wie <t id="110>Bla bla bla</t> statt <t id="110">Bla bla bla</t>.
Jetzt scheint Dein XML ja in Ordnung zu sein. Hast Du seitdem noch einmal versucht, Dein Script auszuführen?

Gruß
Chris Gi

[ManfredP]

Hallo!
Also folgendes: Es ist richtig, zweimal die gleiche ID/page-Kombi in zwei verschiedenen Dateien führt zu keinen Problemen. Genommen wird der Text aus der zuletzt Geladenen. Ein Reset oder Neustart bringt nichts, offenbar werden die Texte im Savegame gespeichert (Nach meinem Eindruck wurde das missverstanden: Nicht die Scripts werden gespeichert, wäre ja auch sinnlos, sondern die Texte, also diese riesige, hypotetische, aber sehr wahrscheinliche Tabelle aus dem Hauptspeicher mit allen Texten drin, die jemals per loadtext-Anweisung aus XML-t-Dateien geladen wurden. Dadurch werden zwar die Savegames größer (eventuell sind das auch nur Pointer in der Form Datei:Dateiposition, die auf die XML-t-Dateien verweisen), aber das Laden der Texte geht vermutlich schneller.

Oh, oh, jetzt kommt die Beichte. Das ist mir furchtbar peinlich, mea culpa und so, aber angesichts der freundlichen Hilfe hier muss es sein: Ich habe ... schluck ... Umlaute benutzt ... im XML-t-File. Das hat er wohl nicht verkraftet. Vor allem nicht, weil das t-File (es ist gelöscht, in kann's nicht mehr nachprüfen) eventuell nicht im UTF-8-Format gespeichert wurde. Solange es der klassische 7-Bit-ASCII-Kram ist, ist alles easy, ist immer das Gleiche (erst bei UTF-16 nicht mehr), aber Umlaute sind nunmal nicht 7-Bit-ASCII und daher unterschiedlich. Mit andern Worten: In dem t-File waren binäre Codes drin. Hatte mich von der Tatsache verleiten lassen, dass irgendwo im Spiel, dem Editor, weis nicht mehr, Umlaute auftauchten. Man kann sie mit dem Script-Editor nicht eingeben, aber da dort alles von DirectX abhängt, und dessen englisches DirectInput bei mir keine Umlaute kann, war das klar und kein Grund zur Sorge.

Na ja, hatte in dem bewussten Script die Textreferenzen entfernt und das setup noch nicht wieder benutzt (wollte erst mal die Ermittlungsergebnisse abwarten). Test allerdings zeigen, dass man auch Strings nachtragen kann (statt Transporter für Stationen eben Transporter in Stationen und nun stimmt's -allerdings, wie gesagt, nicht im Setup. Und beim Neustart (inklusive Rechner) tags drauf war der Name immer noch in der Liste -das nur nochmal zum Thema Abspeichern.

Tschüß

ManfredP

[Chris Gi]

Das mit den Umlauten ist mir auch schon passiert, aber mit einer UTF-8 Codierung des t-Files kein Problem. Ich nutze häufig Umlaute, und die Scripte laufen bei einer UTF-8-Codierung des t-Files ohne Probleme.

Sind Deine Probleme jetzt behoben oder brauchst Du noch Hilfe ?

Gruß,
Chris Gi

[MADxHAWK]

Hallo Manfred,

deine Aussage die Scripts betreffend ist so nicht ganz richtig. Jedes Script das ausgeführt wird, wird in dem so genannten Scriptcache abgelegt und von dort aus ausgeführt. Dieser Scriptcache wird mit dem Savegame gespeichert. Aus diesem Grund ist es auch nötig bei einer neuen Scriptversion das laufende Script zu beenden und über ein Hilfsscript neu zu starten. Siehe dazu auch den Abschnitt Scriptcache aus dem MSCI Handbook. Dies kann dazu führen das X2/X3 beim laden eines Spielstands abstürzt. Umlaute in der Sprachdatei dürften eigentlich nicht zu Problemen führen da diese als wirre Zeichen dargestellt werden wenn die codierung nicht stimmt. was jedoch auf jedenfall zu einem Absturz führen kann ist die Verwendung der Zeichen < und > im Text. Hier sollte man dan die Steuercodes &lt; für < sowie &gt; für > verwenden.

Greetz
MADxHAWK

[ManfredP]

Hallo,
ja, das Problem ist jetzt teilweise behoben, einen Teil habe ich noch nicht wieder ausprobiert (Zeitmangel).

Es waren allem Anschein nach die Umlaute, da es mit einer neuen t-Datei ohne Umlaute ging (da ich die t-Datei im Rahmen eines Aufräumens, um das Spiel wieder zum Laufen zu kriegen, gelöscht hatte). Wegen des Löschens kann ich allerdings eine fehlerhafte Notation im Kommandoteil des XML-Textes nicht ganz ausschließen. Allerdings hatte ich ein vorhandenes t-File aus dem entsprechenden Ordner benutzt (und beim Neuen wieder), sodass das nicht so extrem wahrscheinlich ist.

Es ist mir allerdings mehrmals was aufgefallen: Ich habe schon ein paar Mal Scripte kopiert, also unter einem weiteren Namen gespeichert. Im Editor geht das nicht -bekannt. Also habe ich es, mit dem normalen Texteditor, unter Windows gemacht. Man muss nur zweimal den Namen im Script-Text und natürlich im Speichern-Dialog ändern und es klappt. Dabei zeigt aber der Notepad die Kodierung des Textes an. Und obwohl die alle aus dem X2-Editor stammen (die Vorlagen, die Scripts, die kopiert werden sollen, nicht die Kopien), wurde da manchmal UTF-8, aber manchmal eben auch ANSI angezeigt. Und die sind bei den Umlauten meines Wissens verschieden. Wenn das auch bei t-Dateien der Fall sein sollte, kommt es natürlich auf die Kodierung der jeweiligen Datei an. UTF-8 könnte gehen, ANSI wahrscheinlich nicht.

Was nun die Texte angeht, scheint man mich noch immer nicht richtig verstanden zu haben. Deshalb jetzt mal langsam zum Mitdenken: Ich habe ein Script laufen lassen, dass nur drei Texte aus einer entsprechenden t-Datei lud. Es terminierte sofort anschließend, lief also nicht weiter. Dann habe ich mit einer entsprechenden Anweisung (natürlich in einem geeigneten Auslesescript verpackt) diese Texte ausgelesen und als Nachricht verschickt. Danach habe ich das Spiel gespeichert. Dann bin ich ausgestiegen aus dem Spiel und wieder eingestiegen (dabei habe ich unterschiedliche Prozedere verwendet -in mehreren Tests- von lediglich zum Ladebildschirm zurück bis Computer aus) und habe das Script mit der LoadText-Anweisung zu meiner eigenen t-Datei nicht wieder ausgeführt. Es war auch kein Setup-Script, wurde also nicht automatisch gestartet. Trotzdem konnte ich mit dem Auslesescript wieder Nachrichten erzeugen, die die Texte aus der eigenen t-Datei enthielten. Was sagt Ihr nun? Wo soll da der Script-Cache hineinpassen (den habe ich auch sogar einmal gelöscht -da gibt's doch so 'nen Punkt am Editor-Eingang)? Da stimmt doch was nicht an dieser Überlegung mit dem Cache oder spinne ich jetzt?

Tschüß

ManfredP