Beiträge von Dragonsphere

Ich habe in den nächsten Tagen auch wieder ein größeres Editor-Update für euch!

Am Wochenende habe ich viel am Editor gemacht, so ziemlich alle eure Anregungen sind inzwischen eingebaut (bis auf die Undo-Funktion) und Fehler behoben. Auch gibt es einige neue Features, die mir selber noch fehlten.

Das habe ich gemacht:

- Jahreszeit wird gelesen/gespeichert (bei Karten, die noch nicht im Spiel sind, per Temp.-Datei, sonst direkt in der CODES.DAT des Spiels).

- Karten aus dem Spiel lassen sich nun auch anhand des Levelcodes laden

- Der Levelcode der gerade editierten Karte erscheint nun in der Titelleiste des Fensters

- Wenn ein Gebäude an Stelle eines anderen gebaut wird, bleiben nun enthaltene Einheiten und eingestellte Rohstoffeinnahmen erhalten.

- Damit ist auch der Zuordnungsfehler bei den Gebäudedaten behoben.

- Deutsche Einheiten werden im Auswahlfenster gedreht dargestellt.

- Das Feld unter einer Einheit kann nun geändert werden, ohne das die Einheit entfernt/neu gesetzt werden muss.

- Zuvor gesetzte Einheiten lassen sich nun per Doppelklick von einem Feld entfernen.

- Auch das "ü" wird nun korrekt als "ue" geschrieben, um Kodierungsprobleme zu vermeiden

- Es kann jetzt eingestellt werden, ob die Karte als Einzelspieler- oder Zweispielerkarte gespeichert werden soll (dann fehlt nur noch der .COM file).

- Kleinere Fehlerbehebungen.

Ich muss nur noch ein paar letzte Kleinigkeiten anpassen, dann gibt es hier die inzwischen sechste Beta-Version.

Zitat von tbc21

Habe mehrere .COM ausprobiert in einer simplen Karte nur mir schwerer Ari auf beiden Seiten. Der Computer Gegner hat leider nie angegriffen, weder als Spieler 1 noch als 2.

Das kann auch nicht funktionieren, denn ich habe bei meinem Vorschlag etwas wesentliches nicht bedacht gehabt. Sorry! In der CODES.DAT Datei gibt es ja einen Marker, ob eine Karte eine Ein- oder Zweispielerkarte ist. Der muss natürlich auch entsprechend gesetzt werden und dann gibt das Spiel auch eine Fehlermeldung aus, wenn es keine passende .COM zur Karte gibt.

Ich habe das jetzt auch mal ausprobiert mit einer kleinen Karte mit nur jeweils einer schweren Ari auf beiden Seiten. Ist die Karte als Zwei-Spieler-Karte konfiguriert, greift der Computergegner nie an, ist sie dagegen als Singleplayer-Karte konfiguriert und ich kopiere die 00.COM (also die von PULSE) passend zur Karte, dann greift er in der zweiten Angriffsrunde mit seiner Ari an! Aber auch erst in seiner zweiten Angriffsrunde und nicht direkt...

Also ja, die .COM Dateien sind die Strategieanweisungen für den Computergegner und ohne ist er noch dümmer, als ohnehinschon. Wie kriegen wir nun raus, wie die Dateien aufgebaut sind?

Entpackt sind alle .COM Dateien 306 Byte groß und sie unterscheiden sich oft nur in wenigen Bytes, wenn überhaupt.

Ein Vergleich der Dateiinhalte ergibt, dass es nur vier unterschiedliche .COM Dateien für alle Karten gibt!

00.COM bis 20.COM sind identisch.

21.COM,23.COM bis 44.COM und 46.COM sind identisch.

45.COM und 47.COM sind identisch.

22.COM gibt es nur einmal.

00 bis 23 sind ja die Karten der deutschen Einzelspieler-Kampagne und 24 bis 47 die der französischen

Karte Nummer 22, die eine eigene .COM-Datei hat, ist die Karte CANDL

Zitat von salo13

Zitat von tbc21

Anscheinend können alle Schiffe auf das Feld mit den Panzersperren fahren, solange es direkt an der Küste oder mitten im Meer/See liegt.

Das hat mit dem Editor nichts zu tun.

ja, diesen Bug bzw. Feature ☺️ gab es schon damals und auf bestimmten Karten konnte man das kreativ nutzen. Es ging aber meines Wissens nach nur für Flachwasserfähige Schiffe

Ja, eindeutig ein Fehler im Code des Spiels. Die Panzersperren-Grafik hat die ID "SMOUN130" und ist der Kategorie "hohe Berge" zugeordnet, damit solle sie nur von Einheiten betreten werden können, die auch auf Berge steigen können.Und das Schiffe, auch für die flachwasserfähigen, keine Bergsteiger sind, ist in der UNIT.DAT auch korrekt gesetzt. Von den Datendateien des Spiels her, dürfte das also nicht passieren können

Zitat von tbc21

Bei allen Karten, die ich erstellt und gegen den Computer gespielt habe, scheint er mittlere und schwere Artillerie sowie das Schienengeschütz nicht für Angriffe zu benutzen, obwohl sie jeweils in Reichweite waren.

Vielleicht hat das mit den .COM Dateien zu tun. Dort könnten doch evtl. auch sowas wie Strategieanweisungen drin sein. Diese gibt es ja nicht für unsere neuen Karten nicht.

Du kannst ja mal eine .COM Datei einer von der Größe/Einheitenzahl her ähnlichen Karte so umbenennen, dass sie zu deiner Karte passt und dann testen, ob sich das Verhalten des Computergegners ändert.

Und wie ist das eigentlich mit den regulären Zwei-Spieler-Karten des Spiels? Benutzt der Computergegner da Artillerie/Schienengeschütz? Dürfte dann ja eigentlich auch nicht so sein....

Auch von mir ein ganz herzliches Willkommen hier salo13 !

Zitat von salo13

ich habe jetzt mal versucht in der ersten Karte das Deport durch eine Fabrik zu ersetzen. Das geht nicht, er meldet dann "no data for factory 0 found" beim speichern.

Da bin ich schon dran

Zitat von tbc21

Anzeigen der Namen funktioniert jetzt bei mir. Hier nur ein Mini Problem mit dem Umlaut bei Schienengeschütz

Habe mir das gerade angesehen und anscheinend war es mal wieder spät geworden, als ich den Code dazu geschrieben habe.... Da habe ich doch tatsächlich den Umgang mir ä und ö behandelt und das ü glatt vergessen

Aber super, dass das Anzeigen der Namen jetzt klappt

Zitat von tbc21

Die halben deutschen Schiffe sind jeweils verkehrt herum (180Grad gedreht) auf der Karte gegenüber der Darstellung im Einheiten Auswahlfenster.

Das war allerdings in den Vorgängerversionen auch schon so.

Es sind doch alle deutschen Einheiten um 180 Grad gedreht.... Ist aber kein Problem die deutschen Einheiten auch im Auswahlfenster so darzustellen, wie auf der Karte. Ich muss dafür nur an einer Stelle eine +3 ergänzen

Also zukünftig lieber so?

Hier mal wieder eine neue Version - Beta 1.5

Die meisten Punkte, die ihr mir zurückgemeldet habt, bin ich angegangen. Bei zu vielen verschiedenen Geländegraftiken für das Spiel oder Einheiten auf ungeeigneten Feldern u.ä. ploppt nun eine Warnung auf. Unter Settings könnt ihr die Warnungen aber auch abschalten, wenn ihr z.B. ganz absurde Karten bauen und nicht belästigt werden wollt

Neu sind zudem auch der hier schon angekündigte "Replace" Dialog, um bestimmte Felder einfach durch andere erstzen zu können und ein "Map info" Dialog, der euch eine Übersicht/Statistiken anzeigt, wie die Einheiten-, Gebäude- und Rohstoffverteilung auf eurer Karte so aussieht und auch, wie viele Geländegrafiken ihr bereits genutzt habt. Beides ist neu im Edit Menü.

Was noch nicht umgesetzt ist, ist das Speichern/Auslesen, ob eine Karte im Sommer oder Winter spielt und den Fehler, der nicht angezeigte Einheitenname bzw. das dort falssche Strings angezeigt werden, konnte ichr leider nicht reprodzieren. Ich habe inzwischen noch auf zwei anderen Rechnern, ohne Qt-Installation, intensiv ausprobiert und getestet, bekam aber immer die Namen korrekt unten im Fenster angezeigt.

Daher hier nochmal eine 64-Bit Version mit den Dlls dabei und hoffentlich funktioniert es damit nun auch bei euch korrekt.

HL-Editor BETA 1-5 64 Bit .zip

Viel Spaß damit

Kurze Ergänzung:

Die Zuordnung der Geländefelder zu einer der sieben Kategorien scheint anhand der ID/des Namens der Grafik aus der PARTS.DAT / PARTW.DAT möglich zu sein.

So scheinen die ID-Strings aller Grafiken der Kategorie "Tiefes Wasser/flaches Wasser" mit "SSSEA" zu beginnen, flaches Wasser / Küstengrafiken mit "SCOAS", Schienenwege mit "SRAIL" usw. und tatsächlich sind beginnen auch die Grafiken der kleinen Brücken wie auch die der Berge mit "SMOUN", was ja zur Kategorie "Berge/schmale Brücken" im Handbuch passt.

Damit sollte es ja gut machbar sein, auszuwerten, ob eine Einheit auf einem "erlaubten" Feld steht oder nicht.

Ich habe mit meinem vierjährigen ein paar Mal Lotus III gespielt. Er saß auf meinem Schoß und durfte mit steuern. Das fand er sehr spannend, vor allem die Strecke im Schnee.

Bei Lotus gibt es ja auch wenig Action und auch keine dramatischen Unfälle o.ä.

Ansonsten kann man auch wunderbar Lemmings nehmen, um den Kleinen die Bedienung der Maus nahezubringen. Da gibt es auch keine schnellen Bildwechsel o.

ä.

Ansonsten habe ich mit meinen Kindern auch schon "Party" zur Jukebox im Setup von Tyrian gemacht.

Hallo und ein frohes neues Jahr!

Aufgrund von Frankies Frage und Fund im Handbuch, geht es hier im neuen Jahr mal mit etwas Reverse Engineering weiter .

Zitat von Frankie goes

Vielleicht hilft das ja weiter bei der Datenentschlüsselung ?

Danke für den Auszug aus dem Handbuch. Im Handbuch hatte ich auch schon nachgeschaut, aber diese zusätzlichen Erkärungen haben mich jetzt tatsächlich auf die (hoffentlich) richtige Idee gebracht.

Es gibt also 7 unterschiedliche Kategorien für die Geländefelder und wir wissen, es gibt ein Byte in der Unit.dat, das für die betret/befahrbaren Felder steht (Offset 5).

Da wäre es doch naheliegend, ein Bit pro Kategorie zu verwenden. Es gibt in der Datei 10 unterschiedliche Werte an den entsprechenden Offsets.

Gucken wir uns das doch mal genauer an:

Schnell ableiten lassen sich hier ja direkt Bit 0, 1 und 2, also Wasser und Schienen (Bitnummern von rechts nach links gelesen). Bit 3 könnten dann gut die Schützengräben zu sein. Bit 4 steht wohl für "Ebene, Straße/Brücke", wie es im Handbuch heißt. Bei Bit 5 tippe ich auf Wald und da Jäger über Berge fliegen können und Bomber nicht steht Bit 6 also für hohe Berge (und wie wir aus dem Handbuch erfahren auch schmale Brücken).

Das könnte es also sehr gut sein. Werde ich in den nächsten Tagen mal im Editor einbauen und testen.

Zitat von tbc21

Hey Dragonsphere,

habe mit den großen Schiffen herumgespielt:

Halbe Schiffe (Schlachtschiff, Zerstörer und UBoot) können ins Wasser an die Randfelder gesetzt werden.

Also das man auf der Karte nur das halbe Schiff sieht.

Habe dies zunächst am oberen Rand ausprobiert.

Es verhält sich beim Ziehen ganz normal und ist nach dem Zug als ganze Einheit sichtbar.

Am rechten und linken Rand scheint es auch zu gehen aber unten fangen die Schiffe an, sich komisch zu verhalten. Sie wurden alle drei als Panzerspähwagen dargestellt.

Halbe Schiffe in einer Fabrik mit Wasserzugang können zwar herausbewegt werden, bringen das Programm aber dann durcheinander: Das Schlachtschiff bestand bei mir plötzlich aus einer Hälfte Schiff und der andere Teil war wieder ein Panzerspähwagen. Genauso die anderen Beiden.

Vielleicht wäre das für die evtl. Plausibilitätsprüfung gut, dass man diese als "baubare" Einheit gar nicht zulässt bzw. dort entfernt?

Alles anzeigen

Hallo tbc21 , ein interessantes Experiment Da ist für mich die generelle Frage, wie "narrensicher" so ein Editor überhaupt sein muss, denn eigentlich müsste dann ja ganz allgemein sichergestellt werden, dass Einheiten nicht irgendwo platziert werden, wo sie nicht korrekt angezeigt werden oder von wo sie sich nicht wegbewegen können. Leider haben wir ja bisher nicht die Datei mit den Einheitendetails vollständig entschlüsselt. Denn da stehen definitv auch die Felder drin, auf die eine Einheit ziehen kann.

Ich finde es aber erstmal gar nicht verkehrt, mit dem Editor ausprobieren zu können, was das Spiel mitmacht und würde es daher erstmal dem gesunden Menschenverstand der Anwender überlassen.

Könnte man wohl ein Schlachtschiff auf einen Berggipfel setzen, oder wird es dann zum Spähpanzer?

Zitat von Frankie goes

Hoffe das feedback hilft Dir.

Danke Frankie goes, ja, das hilft mir sehr. Ich werde mir das mal auf verschiedenen Rechnern ansehen, wenn ich jetzt Weihnachtsurlaub habe.

Zitat von tbc21

Hey Frankie,

bei mir ähnlich. Wenn ich in den roten Bereich klicke, stürzt der Editor ab:

Fehler gefunden, ist in der nächsten Version gefixt.

Danke für euren Einsatz!

Zitat von tbc21

Das Phänomen ist mir beim Testen auch mal begegnet. Hatte dann eine Kleinigkeit geändert und plötzlich ging es. Hatte das damals als Anomalie abgetan und nicht weiter untersucht. Aber wenn man die Landschaften und Einheiten betrachtet, ist es eigentlich nur die logische Konsequenz des Spieldesigns: Es gibt ja manche Felder gar nicht. Die wurden wahrscheinlich aus genau den Gründen weggelassen. Zum Beispiel "fehlt" meines Wissens eine Weiche in eine bestimmte Richtung bei den Schienen.

Ja genau, eine Weiche mit Abzweigung nach oben rechts fehlt. Aber auch bei den Ufer-/Küstenteilen und den Feldwegen fehlt jeweils mindestens ein Feld.

Ich habe gesternnoch im Editor ein Statistik-Fenster eingebaut, der die Ressourcenverteilung, Gebäude und Einheiten pro Seite anzeigt. Das fehlte mir noch. Da habe ich dann auch die Zahl der verwendeten Geländefelder ergänzt.

Mit der Zahl der Geländefelder habe ich dann mal getestet und war erstmal verwundert, denn die mögliche Obergrenze schien von Karte zu Karte sehr zu variieren. Bei meiner Karte gibt es schon ab 87 verwendeten Geländefeldern Grafikfehler, aber die Karte GREEN verwendet z.B. 100 unterschiedliche Geländefelder ohne Probleme.

Durch Ausprobieren kam ich dann auf die Lösung: Die ersten 25 Felder, das sind das "normale" Grasland und die Gebäudegrafiken, werden immer geladen. Von den 104 möglichen Feldern lassen sich also nur 79 verwenden, die außerhalb der ersten 25 liegen. Bei Berglandschaften, geschwungenen Straßen oder Schützengräben reizt man das dann doch sehr schnell aus.

Die Grafiken werden auch stumpf nach ihrer Index-Nummer geladen und nicht nach ihrer Platzierung auf der Karte o.ä. Das bedeutet, dass bei zu vielen Feldern immer zuerst das letzte Geländeteil, "das Verbotsschild", nicht mehr funktioniert, dann das hinterste Schützengrabenteil usw. Wer also eine Karte ohne Schützengräben baut, hat noch etwas mehr Luft (nur sollte man dann auch Pioniere zulassen, sonst werden während des Spiels Grafikfehler gebaut )

Zitat von Dragonsphere

Gehen wir davon aus, dass das Spiel 64 KB als Puffer vorhält, in den es nur die benötigten Grafiken läd, dann müssten theoretisch 110 (65536 / 594) Geländefelder gleichzeitig geladen werden können.

Der Bahnübergang mit den Gleisen von unten links nach oben rechts ist allerdings Grafik Nummer 104. In der Praxis sind es also nur 105 Geländegrafiken (Zählung beginnt bei 0), die parallel angezeigt werden können. Das Spiel hält also nicht einmal ein Segment, sondern lediglich knapp 61 KB als Puffer für Geländegrafiken vor.

Auch das konnte ich lösen. Mit Blick auf einen Memorydump scheinen der Index aus der .LIB und die entsprechende .DAT-Datei zum Auffinden der jeweiligen Grafik mit in das Segment geladen zu werden.

Das macht dann 3504 zuzsätzliche Bytes bzw. 5,9 Geländegrafiken (3504/594), womit von den 110 nur noch 104 verbleiben (und mit etwas Glück funktioniert anscheinend auch eine 105te, ohne das die fehlenden Grafikdaten auffallen).

Zitat von Frankie goes

Der Editor wurde gestern ein bisschen getestet. Hatte eine bestehende Karte(Stern) modifiziert.

Habe beim Testen dann gemerkt das sich einige Einheiten beim mir Infanterie und Kavallerie, nicht bewegen konnten trotz freier Felder drumherum,

Hatte jemand auch schon dieses Phänomen?

Auf was für Feldern hast du die denn platziert? Auf Gebäuden, hohen Bergen, in Wasser usw. können die sich dann nicht bewegen. Der Editor prüft das nicht.

Mach gerne einen Screenshot

Hallo Frankie goes und Gratulation zum ersten Beitrag hier im Forum

Danke für dein Feedback. Das mit den Einheitennamen werde ich nochmal prüfen, sobald ich dazu komme, auf einem anderen Rechner ohne Qt-Installation zu testen. Es kann ja eigentlich nur eine fehlende Dll oder so etwas sein, da es bei mir auf meinem Hauptrechner wunderbar funktioniert.

Mir ist aber leider zwischenzeitlich auch noch ein Problem begegnet, bzw. eine Restriktion durch das Spiel.

Ich habe mich an einer schönen Karte mit vielfältigen Details versucht und ordentlich unterschiedliche Bäume, Straßen, Wege, Berge, Felsen, Teiche usw. platziert. Die Karte hat zunächst auch wunderbar funktioniert, bis ich abschließend meine idyllische Landschaft mit Schützengräben zerfurcht und einen Frontbereich gestaltet habe. Da gab es im Spiel bei den zuletzt gesetzten Feldern plötzlich üble Grafikfehler:

Im Editor sieht die gleiche Stelle so aus:

Die Karte wurde auch korrekt gespeichert, also kein Dateifehler o.ä.

Ich konnte es mir nur so erklären, dass History Line nicht alle Geländeteile gleichzeitig im Speicher vorhalten kann und die Anzahl unterschiedlicher Geländeteile, die nebeneinander auf einer Karte platziert werden können, daher im Spiel limitiert ist.

Um das zu testen habe ich mit einem kleinen Programm eine Karte generieren lassen, in der ich bei den Geländefeldern einfach hochzähle, also einfach alle Geländeteile nacheinander darstelle. Und ja, ab den schrägen Bahnübergängen gibt es nur noch diese Grafikfehler.

Nun wissen wir ja bereits, dass es im Spiel 175 verschiedene Geländegrafiken gibt und jede Geländegrafik unkomprimiert 594 Byte groß ist.

Um alle gleichzeitig im Speicher vorzuhalten, sind also 103.950 Byte nötig. Deutlich mehr, als in ein DOS-typisches 64 KB Segment passt und das ist hier wahrscheinlich das Problem.

Gehen wir davon aus, dass das Spiel 64 KB als Puffer vorhält, in den es nur die benötigten Grafiken läd, dann müssten theoretisch 110 (65536 / 594) Geländefelder gleichzeitig geladen werden können.

Der Bahnübergang mit den Gleisen von unten links nach oben rechts ist allerdings Grafik Nummer 104. In der Praxis sind es also nur 105 Geländegrafiken (Zählung beginnt bei 0), die parallel angezeigt werden können. Das Spiel hält also nicht einmal ein Segment, sondern lediglich knapp 61 KB als Puffer für Geländegrafiken vor.

Und das bedeutet nun, uns stehen beim Erstellen von Karten nur maximal 105 der 175 Geländegrafiken gleichzeitig zur Verfügung.

Da muss ich wohl noch eine Prüfung im Editor einbauen....

Gestern Abend habe ich noch etwas daran gebastelt.

Die Genauigkeit beim Auswählen/Platzieren von Einheiten und Gelände habe ich optimiert, indem ich die Geometrie des jeweiligen Widgets mitberücksichtige und nicht nur die Mauskoordnaten.

Das war ja manchmal noch ein bisschen hakelig...

Und ich habe Flood/Dry jetzt durch eine generelle Funktion zum Ersetzen einzelner Geländeteile ersetzt.

Oh ja

Danke. Ist im Quellcode auch schon korrigiert, habe ich hier beim Posten aber tatsächlich übersehen.

Zitat von llm

Zitat

Etwas testen mit einer an unterschiedlichen Stellen eingefügten Messagebox ergab dann auch, dass die 32 Bit Release-Version beim Entpacken der Dateien von History Line abschmiert.

Also habe ich testweise mal die Größe des von "Unpack_file" per malloc reservierten Speichers erhöht uns siehe da, es läuft. Es reicht sogar ein zusätzliches Byte beim Puffer für die entpackten Daten.

Finde das aber immernoch einen sehr merkwürdigen Fehler. Der betroffene Code läuft unter DOS und als 64-Bit Code wunderbar, nur unter 32 Bit braucht es ein zusätzliches Byte bei reserviertem Speicher.

Das ist doch seltsam...

find ich auch seltsam - fühlt sich an wie ein undefined-behavior-aus-dem-Weg geher das mit dem Byte - entweder schreibt der 64bit Teil über die Grenze - dann ist es undefined und "kann" funktionieren, oder der 32Bit schreibt über die Grenze und ist es eben nur zufällig besser merkbar - kann auch irgendwann ohne das Byte plötzlich wieder funktionieren - undefined-behavior=random Absturzgenerator

ich würde den Entpacker ordentlich mit assert zukleistern und prüfen ob alle Indices usw. richtig sind

unter Linux hab ich auch Segmentation-Fault irgendwo beim Entpacken

Alles anzeigen

Ich habe mir das am Wochenende nochmal ganz in Ruhe angesehen und den Fehler behoben.

Hier der bisherige, fehlerhafte Code. Na? Wem fällt etwas auf?

int TPWM_Unpack()
// Unpacks data that is compressed with Turbo Packer
// TPWM struct musst be set
{
    unsigned char b1;
    unsigned char b2;
    unsigned char packbyte;
    char          bit;
    unsigned int  i;
    unsigned int  inofs;
    unsigned int  outofs;
    unsigned int  distance;
    unsigned int  length;

    outofs = 0;
    inofs = 0;


    while (outofs < TPWM.unpacked_size)
    {
        packbyte = TPWM.packed_data[inofs];

        inofs++;

        for (bit = 7; bit >= 0; bit--)
        {
            if (getbit(packbyte, bit) = 1)
            {
                b1 = TPWM.packed_data[inofs];
                inofs++;
                b2 = TPWM.packed_data[inofs];
                inofs++;

                distance = (unsigned int)((b1 & 0xF0) << 4) | b2;
                if (distance > outofs) break;

                length = (unsigned int)(b1 & 0x0F) + 3;

                for (i = 0; i <= (length - 1); i++)
                {
                    TPWM.unpacked_data[outofs] = TPWM.unpacked_data[(outofs - distance)];
                    outofs++;
                    if (outofs > TPWM.unpacked_size) break;
                }
            }
            else
            {
                TPWM.unpacked_data[outofs] = TPWM.packed_data[inofs];
                inofs++;
                if (inofs > TPWM.packed_size) break;

                outofs++;
                if (outofs > TPWM.unpacked_size) break;
            }
        }
    }


    if (outofs >= TPWM.unpacked_size)
        return 0;
    else
        return -1;
}

Also, die Haupt-Whileschleife läut, solange outofs kleiner als die Größe der ungepackten Daten ist.

Aber immer wenn outofs erhöht wird, wird abgebrochen wenn outofs größer ist. Bleibt als die Frage, was ist denn, wenn outofs genau die Größe der ungepackten Daten hat....

Und da Offsets ja bekanntlich mit 0 beginnen... richtig, wir schreiben außerhalb des Puffers und haben unsere Schutzverletzung/Segmentation fault what so ever.

Warum ich das, als ich vor bald einem Jahr diesen Code geschrieben habe, anscheinend völlig ok fand und auch noch ein

if (outofs >= TPWM.unpacked_size) return 0;

ans Ende gesetzt habe, ist mir heute ein Rätsel. Anscheinend war mit bereits bei der DOS-Version des Entpackers aufgefallen, dass outofs zu groß wird, ohne die richtigen Schlüsse daraus zu ziehen. Zu wenig Freizeit um wach, mit Ruhe und klarem Verstand dem Hobby nachzugehen, würde ich da mal sagen.

Habe das ganze jetzt überarbeitet und nun folgenden Code:

int TPWM_Unpack()
// Unpacks data that is compressed with Turbo Packer
// TPWM struct musst be set
{
    unsigned char b1;
    unsigned char b2;
    unsigned char packbyte;
    char          bit;
    unsigned int  i;
    unsigned int  inofs;
    unsigned int  outofs;
    unsigned int  distance;
    unsigned int  length;

    outofs = 0;
    inofs = 0;


    while (outofs < TPWM.unpacked_size)
    {      
        packbyte = TPWM.packed_data[inofs];
        inofs++;

        for (bit = 7; bit >= 0; bit--)
        {
            if (getbit(packbyte, bit) = 1)
            {
                b1 = TPWM.packed_data[inofs];
                inofs++;
                b2 = TPWM.packed_data[inofs];
                inofs++;

                distance = (unsigned int)((b1 & 0xF0) << 4) | b2;
                if (distance > outofs) break;

                length = (unsigned int)(b1 & 0x0F) + 3;

                for (i = 0; i <= (length - 1); i++)
                {
                    if (outofs < TPWM.unpacked_size)
                    {
                        TPWM.unpacked_data[outofs] = TPWM.unpacked_data[(outofs - distance)];
                        outofs++;
                    }
                    else
                        break;
                }
            }
            else
            {
                if ((outofs < TPWM.unpacked_size) && (inofs < TPWM.packed_size))
                {
                  TPWM.unpacked_data[outofs] = TPWM.packed_data[inofs];
                  inofs++;
                  outofs++;
                }
                else
                  break;

            }
        }

        if (outofs >= TPWM.unpacked_size)
            break;

    }


    if (outofs == TPWM.unpacked_size)
        return 0;
    else
        return -1;
}

Wie ihr seht, war ich jetzt besonders vorsichtig und bei jedem Schreiben wird jetzt sichergestellt, dass der Offset stimmt. Sicherheitshalber auch nicht nur für die entpackten Daten sondern auch beim input buffer mit den gepackten Daten.

Zudem habe ich nochmal eine Abfrage direkt ans Ende der while-Schleife gesetzt, damit diese ja nicht einmal zu oft durchläuft.

Und 0 wird nur noch zurückgegeben, wenn die Größe am Ende stimmt (da nach jedem Schreiben outofs erhöht wird, landen wir genau bei der unpacked size)

Jetzt läuft es auch unter 32 Bit und ohne zusätzliches Byte reservierten Speicher

Ich persönlich habe das bisher gar nicht als Problem gesehen, bei Bedarf eben mit zwei Klicks die Jahreszeit anzupassen.

Finde ich weniger aufdringlich/umständlich als wenn jedes Mal eine Abfrage aufploppen würde.

In einer extra Datei speichern könnte ich das natürlich, oder wenn Karten aus dem Spielverzeichnis geladen werden prüfen, ob zur Nummer der Karte ein Code in der Code.dat steht und die Jahreszeit auslesen.

Zitat von tbc21

Wenn ich eine Karte von Sommer auf Winter ändere, sind danach alle Karten, die ich lade auch automatisch auf Winter eingestellt.

Auch nach dem Beenden des Editors ohne die Karten zu speichern, zeigt er beim nächsten Öffnen so z.B. reguläre Sommer Maps als Winter Karten an.

Vielleicht wird da ein Flag nicht zurückgesetzt?

Das mit dem Anzeigen der Namen der Einheiten scheint bei mir nicht zu funktionieren. Der sollte doch im Einheitenauswahlfenster unten angezeigt werden, gell?

Das "Flood/Dry Map" Feature funktioniert anscheinend nur bei dem mittleren der drei vollständigen Wasserfelder. Dieses wird bei erneuten Auswählen auch wieder zu Land.

Die anderen beiden (seicht und tief) reagieren nicht.

Alles anzeigen

Also, ob eine Karte im Sommer oder Winter spielt, ist leider nicht in der Dateien mit den Karten-Daten (*.fin/*.shp) gespeichert, sondern nur zusammen mit dem Levelcode in der Code.dat. Daher wird dieses Flag auch nur gespeichert, wenn man eine Karte dem Spiel hinzufügt und beim Laden einer Karte auch nicht mit geladen. Ist also quasi eine Session-Variable, die manuell gesetzt werden muss.

Was du zu Flood/Dry Map schreibst, ist benfalls kein Fehler. Wenn man eine neue Karte erstellt, besteht diese ja standardmäßig aus Gras-Feldern (Tile 0). Da es ja blöd wäre, diese alle erstmal mit Wasser ersetzen zu müssen, wenn man eine Seeschlacht erstellen möchte, habe ich diese Funktion eingefügt, die das standard Gras-Feld durch tiefes Wasser ersetzt. Und bisher auch nur dieses.

Es gibt ja auch keine typischen Nachbar-Gras-Felder, die ich sinnvoll durch seichtes Wasser ersetzen könnte. Höchstens Hügel o.ä., wenn man es wirklich als Fluten sehen will. Aber so richtig Höhenstufen hat man in HL ja nicht.

Ich überlege, daraus einfach eine generelle Ersetzen Funktion zu machen. Mit frei wählbaren Feldern.

Und was das Anzeigen der Einheitennamen angeht:

Markiere mal eine Einheit und gucke in die linke untere Ecke des Fensters.

Zitat von Sack84

Außerdem ein guter Speed Indikator. Bei 450 Mhz noch lauffähig aber nicht bei 900 MHz.

Lässt sich zum Glück patchen, und funktioniert dann auch auf schnellen PCs.

Kleiner Exkurs: Tyrian wurde in Borland Pascal 7.0 geschrieben und hat, auch wenn der typische "Runtime Error 200" vermieden wurde, leider dieselben Timing Probleme auf schnelleren Rechnern, wie viele andere damit erstellte Programme auch (u.a. auch mein Opti-Soundkarten Treiber, wo ich auch dachte, dass Problem einfach umgehen zu können).

Tyrian ist sowieso eines der Spiele mit den vielfältigsten (Fun-)Cheats und Eastereggs. Da ist doch wirklich alles drin, vom normalen Godmode und Geld-Cheat über versteckte Schwierigkeitsgrade bis zum versteckten Minigame Destruct.

Dazu noch der Weihnachtsmodus und sogar in der Jukebox gibt es Tastenkombinationen für lustigen Blödsinn.

Herzlich Willkommen und auf bald beim HL Mapeditor