Level-/Karteneditor für Historyline 1914-18

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.

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 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

Oh ja

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

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.

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....

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

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!