Schemes

[Gareth]

Vertikale Objekte (stand)
Nach dem gleichen Prinzip wie im vorherigen Post werden auch die vertikalen Objekte auf SSRW übertragen:
- game_scheme5\stand.res und stand.pl löschen
- stand.rs2 und stand.pl aus summer.sue nach game_scheme5 kopieren
- stand.rs2 in stand.res umbenennen
- stand.edt aus summer_edit.sue nach Editor\game_scheme5 kopieren und die dort vorhandene Version überschreiben

Der Vergleich der Desc-Dateien aus desc_scheme5\land (SSRW) und aus desc_summer.sue\land (SSF) zeigt größere Abweichungen. Die im Parameter preload aufgezählten Objekte sind unterschiedlich. Da wir die vertikalen Objekte aus SSF in das Schema übernommen habe, muss logischerweise auch die Liste der vorab zu ladenden Objekte sich an den aus SSF übernommenen Objekten orientieren, nicht an denen aus SSRW. Außerdem enthält die Desc-Datei aus SSF eine Reihe von onDmg_AddExplosion-Parametern für verschiedene Objekte, die in der Version aus SSRW fehlen. Ich übernehme daher die Desc-Datei von SSF, entferne aber den Verweis auf die Soundeinstellungen in igor\land\stand.

Die in der Desc-Datei aus SSF bei den onDmg_AddExplosion-Parametern genannten Explosionen und die damit verbundenen Animationen sind leider nicht alle in SSRW vorhanden. Sie müssen daher aus SSF übernommen und in SSRW eingefügt werden.
In desc_common\explosions von SSRW fehlen die Desc-Dateien BOOMHAY, FALLEN, FOUNTAIN und STAND. Sie werden aus desc_common.sue\explosions von SSF kopiert, dabei werden aber die Verweise auf Sounds (#igor\...) entfernt. Die Dateien werden in die Liste EXPLOSIONS eingetragen. Gleichnamige Varianten von SMOKE und V2 sind bereits in SSRW vorhanden.

In den übernommenen Explosions-Descs werden die folgenden Animationen genannt:
- BOOMHAY in BOOMHAY
- FOUNTAIN in FOUNTAIN
- SMALDUST in STAND
Diese Animationen fehlen in SSRW und werden daher aus SSF von desc_common.sue\animat nach SSRW\desc_common\ANIMAT kopiert. Alle übernommenen Animationen werden in die Liste ANIMAT eingetragen. Die in der Desc-Datei FALLEN genannten Animationen LIGHT_BIG, AIREX und B_STD_SMOKE sind in SSRW bereits in einer Variante vorhanden und werden unverändert gelassen.

Auch die zugehörigen Animationsgrafiken mit ihren Farbpaletten müssen in SSRW vorhanden sein. Sie sind dort im Verzeichnis game_common abgelegt. Die Dateien fountain.ani und fountain.col sowie smaldust.ani und smaldust.col sind bereits vorhanden, boomhay.ani und boomhay.col werden von animats.sue aus SSF dorthin kopiert.

In der Explosion FALLEN wird außerdem als Addshot die Shot-Datei FIRE aufgeführt. Diese existiert in einer leicht unterschiedlichen Variante auch in SSRW und wird daher nicht verändert.
Auch FOUNTAIN enthält einen Addshot-Eintrag mit dem Shot FOUNTAIN_CHILD, der in SSRW nicht vorhanden ist. Die Shot-Datei wird daher aus SSF übernommen und in der Liste SHOTS im Verzeichnis SHOTS nach dem Vorbild aus SSF als
invis fountain_child
eingetragen.
Nach diesen Änderungen können die aus SSF bekannten Animationen in dem Schema auf einer Testkarte betrachtet werden: Ein zerstörter Brunnen zeigt eine Wasserfontäne, die Heuschober zeigen bei Zerstörung die Animation mit dem fliegenden Stroh.

Bäume (tree)
Wir führen wieder die bereits bekannten Arbeitsschritte aus:
- game_scheme5\tree.* löschen
- tree.rs2 und tree.pl aus summer.sue nach game_scheme5 kopieren
- tree.rs2 in tree.res umbenennen
- tree.edt aus summer_edit.sue nach Editor\game_scheme5 kopieren und die dort vorhandene Version überschreiben
Die Desc-Dateien zeigen Abweichungen, weil im Sommerschema von SSRW und im Strandschema aus SSF natürlich unterschiedliche Bäume enthalten sind. Wir übernehmen daher die desc-Datei aus desc_summer.sue\land von SSF in SSRW und entfernen den Verweis auf die Soundeinstellungen wie bei den vorherigen Desc-Dateien.

Bei einigen Bäumen wird als Boomtype nicht deadtree, sondern autree genannt, wahrscheinlich für Herbstbäume (autumn). Die Entwickler von SSRW haben sich das Leben einfach gemacht und den Herbstbäumen die gleiche Zerstörungsanimation verpasst wie den grün belaubten Bäumen. Wir können daher einfach autree durch den Standardwert greentree ersetzen.

Wahrscheinlich ist es sogar noch einfacher stattdessen alle Zeilen zu löschen, in denen autree vorkommt. Dann müsste das Spiel für die entsprechenden Bäume eigentlich auf den unter ExplosionType default festgelegten Wert zurückgreifen. Es ist aber auch möglich, die Definition des Boomtypes autree aus SSF zu übernehmen.
- autree in die Liste BOOMTYPES eintragen
- Explosionsdatei autumn von SSF nach SSRW kopieren und in EXPLOSIONS eintragen, Verweis auf #igor\explosions\std entfernen
- In autumn genannte Animations-Desc treeautu von SSF nach SSRW kopieren und in ANIMAT eintragen. Die ebenfalls genannte Datei b_std_smoke ist in SSRW schon vorhanden.
- In treeautu genannte Animation vzrvaut1.ani und zugehörige Palettendatei vzrvaut1.col sind in SSRW bereits vorhanden (in _game_common).
- Shot-Dateien bomb und pierce* (6 Dateien, deren Name mit pierce beginnt) um einen Eintrag "explosion autree autumn" ergänzen
- Shot-Dateien fire und fire_big um einen Eintrag "explosion autree fire" ergänzen, damit auch die als autree gekennzeichneten Bäume eine Feueranimation zeigen

[Gareth]

Vertical Objects (stand)
The vertical objects are also transferred to SSRW following the same principle as in the previous post:
- delete game_scheme5\stand.res and stand.pl
- copy stand.rs2 and stand.pl from summer.sue to game_scheme5
- rename stand.rs2 to stand.res
- copy stand.edt from summer_edit.sue to Editor\game_scheme5 and overwrite the existing version

Comparing the desc files from desc_scheme5\land (SSRW) and desc_summer.sue\land (SSF) reveals significant differences. The objects listed in the preload parameter are different. Since we imported the vertical objects from SSF into the scheme, the list of objects to be preloaded must logically be based on the objects imported from SSF, not those from SSRW. In addition, the SSF description file contains a number of onDmg_AddExplosion parameters for various objects that are missing in the SSRW version. I'm therefore adopting the SSF description file, but removing the reference to the sound settings in igor\land\stand.

Unfortunately, not all of the explosions and associated animations listed in the SSF description file in the onDmg_AddExplosion parameters are available in SSRW. They must therefore be imported from SSF and inserted into SSRW.

The description files BOOMHAY, FALLEN, FOUNTAIN, and STAND are missing from SSRW's desc_common\explosions. They are copied from SSF's desc_common.sue\explosions, but the references to sounds (#igor\...) are removed. The files are added to the EXPLOSIONS list. Variants of SMOKE and V2 with the same name are already available in SSRW.

The following animations are named in the imported explosion descriptions:
- BOOMHAY in BOOMHAY
- FOUNTAIN in FOUNTAIN
- SMALDUST in STAND
These animations are missing in SSRW and are therefore copied from SSF from desc_common.sue\animat to SSRW\desc_common\ANIMAT. All imported animations are entered into the ANIMAT list. The animations LIGHT_BIG, AIREX, and B_STD_SMOKE named in the FALLEN description file already exist in SSRW in a variant and are left unchanged.

The corresponding animation graphics with their color palettes must also be present in SSRW. They are stored there in the game_common directory. The files fountain.ani and fountain.col, as well as smaldust.ani and smaldust.col, already exist; boomhay.ani and boomhay.col are copied from animats.sue in SSF.

The FALLEN explosion also lists the shot file FIRE as an addshot. This also exists in a slightly different version in SSRW and is therefore not changed.

FOUNTAIN also contains an addshot entry with the shot FOUNTAIN_CHILD, which is not present in SSRW. The shot file is therefore imported from SSF and entered in the SHOTS list in the SHOTS directory as
invis fountain_child
following the SSF model.

After these changes, the animations known from SSF can be viewed in the scheme on a test card: A destroyed well shows a water fountain, and the haystacks show the animation with the flying straw when destroyed.

Trees (tree)
We'll repeat the steps we've already seen:
- Delete game_scheme5\tree.*
- Copy tree.rs2 and tree.pl from summer.sue to game_scheme5
- Rename tree.rs2 to tree.res
- Copy tree.edt from summer_edit.sue to Editor\game_scheme5 and overwrite the existing version
The desc files show differences because the summer scheme in SSRW and the beach scheme in SSF naturally contain different trees. We'll therefore import the desc file from desc_summer.sue\land from SSF into SSRW and remove the reference to the sound settings as we did with the previous desc files.

For some trees, the boom type is autree instead of deadtree, probably for autumn trees. The SSRW developers made life easier for themselves and gave the autumn trees the same destruction animation as the green-leafed trees. We can therefore simply replace autree with the default value greentree.

It's probably even easier to delete all lines containing autree instead. Then the game would have to use the value specified under ExplosionType default for the corresponding trees. However, it's also possible to import the definition of the autree boom type from SSF.
- Add autree to the BOOMTYPES list
- Copy the explosion file autumn from SSF to SSRW and add it to EXPLOSIONS, removing the reference to #igor\explosions\std
- Copy the animation description treeautu named in autumn from SSF to SSRW and add it to ANIMAT. The file b_std_smoke already exists in SSRW.
- The animation vzrvaut1.ani named in treeautu and the associated palette file vzrvaut1.col already exist in SSRW (in game_common).
- Add an entry "explosion autree autumn" to the shot files bomb and pierce* (6 files whose names begin with pierce).
- Add an entry "explosion autree fire" to the shot files fire and fire_big so that the trees marked as autree also display a fire animation.

[Gareth]

Bodentexturen (Rhombs)
Wir kopieren die Texturgrafiken aus beach.sue in das Verzeichnis game_scheme5 und benennen sie um:
- mappic.rs2 zu rhombs.res
- RHOMB.PL zu rhombs.pl
Ob die Texturgrafiken korrekt übernommen wurden, können wir durch Entpacken der neuen rhombs.res mit SuSt Graph prüfen. Liefert SuSt Graph eine Bitmap mit den Texturkacheln, dann sollte alles geklappt haben.

Als nächstes wird die Datei mappic.sb2 aus beach_edit.sue nach edit_scheme5 kopiert und in rhombs.edt umbenannt. Sie muss an das Format der edt-Dateien von SSRW angepasst werden. Es ist mir nicht gelungen, diese Datei mit irgendeiner Software automatisch zu erstellen. Also blieb nur der Weg, das von Hand zu erledigen. Glücklicherweise hat Mzach das Format der edt-Datei beschrieben. Wer sich also für die Hintergründe der folgenden Arbeitsschritte interessiert, der möge hier (Rhombs_Res.txt) und hier nachlesen.

Wir öffnen die Datei rhombs.edt in einem Hex-Editor. Beim Abzählen der Bytes für die erste Terraintextur anhand der Erläuterungen von Mzach und meinen eigenen Untersuchungen zu dem Thema zeigt sich, dass die Informationen über das Terrain, zu dem das aktuelle Terrain übergehen soll, und die von Mzach als Offset bezeichnete Farbinformation für das Originalinterface des Editors in der sb2-Datei fehlen. Sie müssen anhand der Informationen aus scheme.ini in die Datei eingefügt werden. Die folgende Übersicht zeigt die Werte aus der scheme.ini und die daraus erzeugten Hexadezimalwerte, die in die Datei eingefügt wurden.

Tabelle 1.jpg (47.51 KiB) 164 mal betrachtet

Die Werte für den Texturübergang geben die Nummer des Schemas an, zu dem die jeweilige Terraintextur einen Übergang hat. Alle Terrains bis auf Ground 2 und Water gehen zu Grass über (erstes Terrain, daher Nummer 0). Ground2 geht zu Ground1 über (fünftes Terrain, daher Nummer 4). Water geht zu Sand über (achtes Terrain, daher Nummer 7). Der Wert –1 gibt die Standardtextur an, d.h. die Textur, mit der eine neue Karte des Schemas gefüllt wird.
Die Umwandlung der Farbwerte im RGB-Format in das von SuSt verwendete Format mit 5-6-5 Bits wurde ebenfalls von Mzach beschrieben (Seite 18-21 des Dokuments): Das Ergebnis der Umwandlung wurde dann als Hexadezimalzahl dargestellt.
Eine Desc-Datei zu den Bodentexturen existiert nicht. Es sind also keine weiteren Anpassungen notwendig.

Probleme
Bei einigen Kategorien bin ich auf verschiedene Schwierigkeiten gestoßen, von Fehlermeldungen des Editors und des Spiels bis hin zu Abstürzen mit BTW:
- Straßen (trop)
- Gebäude (houses, in SSRW: dom)
- Klippen (cliff)
- Brücken (most)
Die Gebäude sind dabei aus meiner Sicht das geringste Problem, denn fast alle Gebäude aus dem SSF-Schema sind auch im Sommerschema/Normal Scheme von SSRW enthalten. Ich kann ganz gut damit leben, auf ein paar Hütten und Industriegebäude aus SSF zu verzichten und dafür die erheblich größere Auswahl aus SSRW zur Verfügung zu haben.
Für die Probleme bei Straßen, Klippen und Brücken habe ich leider keine Lösung. Dennoch muss eine Übernahme auch dieser Elemente möglich sein, denn die Schemata aus SSF sind ja in verschiedenen Mods vorhanden. Vielleicht kann Tijn dazu ein paar Hinweise geben, wenn er mal wieder vorbeischaut. Bis auf weiteres könnte man die Probleme umgehen, indem man die benötigten Dateien für Straßen, Klippen und Brücken aus einem Mod übernimmt, in dem das SSF-Schema enthalten ist.

[Gareth]

Ground Textures (Rhombs)
We copy the texture graphics from beach.sue to the game_scheme5 directory and rename them:
- mappic.rs2 to rhombs.res
- RHOMB.PL to rhombs.pl
We can check whether the texture graphics have been imported correctly by unpacking the new rhombs.res file with SuSt Graph. If SuSt Graph returns a bitmap with the texture tiles, then everything should have worked.

Next, the mappic.sb2 file from beach_edit.sue is copied to edit_scheme5 and renamed to rhombs.edt. It must be adapted to the SSRW edt file format. I wasn't able to create this file automatically using any software, so the only option was to do it manually. Fortunately, Mzach has described the format of the edt file. Anyone interested in the background of the following steps should read here (Rhombs_Res.txt) and here.

We open the rhombs.edt file in a hex editor. Counting the bytes for the first terrain texture based on Mzach's explanations and my own research on the topic, it becomes apparent that the information about the terrain to which the current terrain should transition, and the color information for the original editor interface, which Mzach calls the offset, are missing from the sb2 file. They must be inserted into the file using the information from scheme.ini. The following overview shows the values from scheme.ini and the hexadecimal values generated from them, which were inserted into the file.

Tabelle 2.jpg (49.83 KiB) 160 mal betrachtet

The texture transition values indicate the number of the scheme to which the respective terrain texture has a transition. All terrains except Ground 2 and Water transition to Grass (first terrain, hence number 0). Ground 2 transitions to Ground 1 (fifth terrain, hence number 4). Water transitions to Sand (eighth terrain, hence number 7). The value -1 specifies the default texture, i.e., the texture used to fill a new map in the scheme.
The conversion of color values in RGB format to the 5-6-5 bit format used by SuSt was also described by Mzach (pages 18-21 of the document): The result of the conversion was then displayed as a hexadecimal number.
A DESC file for the ground textures does not exist, so no further adjustments are necessary.

Problems
I encountered various difficulties in some categories, ranging from error messages from the editor and the game to crashes with BTW:
- Roads (trop)
- Buildings (houses, in SSRW: dom)
- Cliffs (cliff)
- Bridges (most)
The buildings are, in my opinion, the least of the problems, as almost all buildings from the SSF scheme are also included in the Summer Scheme/Normal Scheme of SSRW. I'm quite happy with foregoing a few huts and industrial buildings from SSF in favor of having the considerably larger selection from SSRW at my disposal.
Unfortunately, I don't have a solution for the problems with roads, cliffs, and bridges. However, it should be possible to transfer these elements as well, as the SSF schemes are available in various mods. Perhaps Tijn can provide some insight on this when he visits again. For now, the problems could be circumvented by importing the required files for roads, cliffs, and bridges from a mod that includes the SSF scheme.

[Gareth]

Aufräumen
Wir haben unsere Arbeit auf der Grundlage einer Kopie des Sommerschemas von SSRW begonnen. Dabei haben wir einige Dateien kopiert, die nicht schemaspezifisch sind. Dazu gehören die Passagiericons in icon.res mit der Palette icon.pl und die Grafiken der Pontonbrücken in pont.res mit der Palette pont.pl. Diese Dateien sollten wir in game_scheme5 wieder löschen. Besonders bei den Icons ist das sinnvoll, damit nicht durch Erweiterung um zusätzliche Icons zwei unterschiedliche Versionen entstehen. Weil die Dateien aber in dem Schema verwendet werden, müssen wir nach dem Löschen der Dateien dafür sorgen, dass sie weiterhin auffindbar sind. Daher ergänzen wir in der Datei sudtest.ini die Zeile
scheme5=desc_scheme5\;desc_common\;game_scheme5\
um einen Eintrag für das erste Schema, in dem die im Verzeichnis des Strandschemas gelöschten Dateien noch liegen:
scheme5=desc_scheme5\;desc_common\;game_scheme5\;game_scheme1\

Karten von SSF auf SSRW übertragen
Karten im Strandschema von SSF könenn im Editor von SSRW geladen werden, wenn wir das Schema auch in SSRW funktionsfähig eingerichtet haben. Wir suchen uns im Editor von SSF eine Karte aus, die im Strandschema erstellt wurde. Dann kopieren wir das Verzeichnis mit den Editordateien der Karte aus maps.ca im SSF-Verzeichnis in das Verzeichnis maps.src von SSWR.

Damit die Editordateien vom SSRW-Editor richtig interpretiert werden, müssen wir die Datei INFO im Verzeichnis der Karte bearbeiten. Die ersten vier Bytes der Datei geben die Nummer des Kartenschemas an, in dem die Karte im SSF-Editor erstellt wurde. Wenn wir die INFO-Datei unserer Karte in einem Hex-Editor öffnen, finden wir dort in den ersten vier Bytes die Werte 02 00 00 00. Das bedeutet, dass das verwendete Kartenschema die Nummer 2 hat. Diese Nummer steht für das dritte Schema des SSF-Editors, weil die Nummerierung – wie in der Programmierung üblich – bei 0 beginnt. Das Strandschema ist bei SSF tatsächlich das dritte Schema, wie wir in der Datei editor2.ini von SSF sehen können.

Im Editor von SSRW haben wir in den vorangegangenen Posts das Strandschema als fünftes Schema eingefügt. Also ändern wir in der INFO-Datei das erste Byte 02 durch 04 und speichern die Datei. Jetzt können wir die Karte im SSRW-Editor laden.

Es kann sein, dass das Ergebnis nicht ganz einwandfrei ist. Wenn wir z.B. die Gebäude aus SSRW verwenden, weil die entsprechende Datei aus SSF nicht mit SSRW kompatibel ist, dann fehlen einige Gebäude aus SSF. Wenn diese aber in der Karte verbaut wurden, dann werden sie im Editor von SSRW nicht dargestellt. Ähnliches kann bei den Straßen, Klippen und Brücken passieren, wenn die entsprechenden Dateien nicht mit denen aus SSF übereinstimmen. Der größte Teil der Karte sollte aber korrekt im SSRW-Editor erscheinen.

Sommerschema übernehmen
Wenn wir ein funktionierendes Strandschema haben, dann ist die Übernahme des Sommerschemas einfach. Wir legen wie oben ein neues Schema an: game_scheme6 und im Editorverzeichnis edit_scheme6. Ein Verzeichnis desc_scheme6 brauchen wir eigentlich nicht unbedingt, weil sich die Landschaftselemente und damit auch die zugehörigen Desc-Dateien nicht ändern. Sollten sich allerdings später Änderungen ergeben, die nur für eines der Schemata gelten sollen, dann müssen wir das Desc-Verzeichnis des Strandschemas kopieren und dann Änderungen an der Version vornehmen, in der die Änderungen wirksam werden sollen.
In den ini-Dateien tragen wir das neue Schema ein. In sudtest.ini:
Scheme6=desc_scheme5\;desc_common\;game_scheme6\;game_scheme5\;game_scheme1\
Wir müssen auf desc_scheme5 und game_scheme5 verweisen, weil wir die Einstellungen und die meisten Grafiken aus dem Strandschema auch im Sommerschema verwenden.
In edit3.ini:
[scheme_6]
Name=Summer (SSF)
MiniMapGamma=150
DataDir1=..\_lng\;..\_game_scheme6\;..\_game_scheme5\;_edit_scheme6\;_edit_scheme5\
DataDir2=..\_desc_common\;_edit_common\
Auch hier verweisen wir natürlich auf die Grafik- und Editordateien des Strandschemas. Vorher geben wir aber die entsprechenden Dateien des neu angelegten Sommerschemas an, weil die Daten zu den Bodentexturen unterschiedlich sind. Weil diese aus dem Sommerschema geladen werden sollen, muss das Sommerschema 6 vor dem Strandschema 5 genannt werden.
Jetzt müssen wir noch die Dateien mit den Bodentexturen kopieren und umbenennen. Die edt-Datei muss dann in der gleichen Weise bearbeitet werden, wie das schon weiter oben beschrieben wurde. Dabei muss bei dem Terrain Wasser statt 07 00 00 00 die Folge 00 00 00 00 eingetragen werden, weil im Sommerschema die Übergänge von Wasser zu Gras 1 (Terrain 0) und nicht zu Sand (Terrain 7) erfolgen.

Anmerkung zum Schluss
Natürlich hätten wir die Schemata auch in der Form übernehmen können, wie sie in SSF vorliegen, also so, dass die Masse der Daten im Sommerschema liegt und das Strandschema bis auf die Bodentexturen diese Daten übernimmt. Ich habe es hier umgekehrt gemacht, weil ich für meinen "Private Little Mod" eigentlich nur das Strandschema haben wollte. Daher habe ich das zuerst übertragen. Dass das Sommerschema mit geringem Aufwand ebenfalls zu übernehmen wäre, ist mir ehrlich gesagt erst jetzt bewusst geworden, als ich meine Notizen für das Forum aufbereitet habe.

Das wäre es erstmal von meiner Seite. Ich hoffe, dass man mit meinen Ausführungen etwas anfangen kann. Wenn Fragen auftauchen, bitte hier posten. Ich werde mich bemühen, sie zu beantworten.

[Gareth]

Cleaning Up
We started our work based on a copy of the SSRW summer scheme. We copied some files that aren't scheme-specific. These include the passenger icons in icon.res with the icon.pl palette and the pontoon bridge graphics in pont.res with the pont.pl palette. We should delete these files in game_scheme5. This is especially useful for the icons, so that adding additional icons doesn't create two different versions. However, because the files are used in the scheme, we need to ensure that they can still be found after deleting them. Therefore, we add an entry to the line
scheme5=desc_scheme5\;desc_common\;game_scheme5\
in the sudtest.ini file for the first scheme, where the files deleted from the Beach scheme directory are still located:
scheme5=desc_scheme5\;desc_common\;game_scheme5\;game_scheme1\

Transferring maps from SSF to SSRW
Maps in the Beach scheme in SSF can be loaded in the SSRW editor if we have configured the scheme to work in SSRW. In the SSF editor, we select a map created in the Beach scheme. Then we copy the directory containing the map editor files from maps.ca in the SSF directory to the maps.src directory in SSRW.

In order for the editor files to be correctly interpreted by the SSRW editor, we need to edit the INFO file in the map directory. The first four bytes of the file indicate the number of the map scheme used to create the map in the SSF editor. If we open our map's INFO file in a hex editor, we'll find the values 02 00 00 00 in the first four bytes. This means that the map scheme used is number 2. This number represents the third scheme in the SSF editor because, as is common in programming, numbering starts at 0. The Beach scheme is actually the third scheme in SSF, as we can see in the SSF editor2.ini file.

In the SSRW editor, we added the Beach scheme as the fifth scheme in the SSRW editor in previous posts. So, we change the first byte 02 in the INFO file to 04 and save the file. Now we can load the map in the SSRW editor.

The result may not be entirely accurate. For example, if we use buildings from SSRW because the corresponding SSF file isn't compatible with SSRW, some SSF buildings will be missing. However, if these buildings were incorporated into the map, they won't be displayed in the SSRW editor. A similar issue can occur with roads, cliffs, and bridges if the corresponding files don't match those from SSF. However, most of the map should appear correctly in the SSRW editor.

Importing the Summer Scheme
If we have a working beach scheme, then adopting the summer scheme is easy. We create a new scheme as above: game_scheme6 and in the editor directory, edit_scheme6. We don't actually need a desc_scheme6 directory because the landscape elements and thus the associated desc files don't change. However, if changes occur later that should only apply to one of the schemes, we need to copy the desc directory of the beach scheme and then make changes to the version in which the changes should take effect.
We enter the new scheme in the ini files. In sudtest.ini:
Scheme6=desc_scheme5\;desc_common\;game_scheme6\;game_scheme5\;game_scheme1\
We need to reference desc_scheme5 and game_scheme5 because we also use the settings and most of the graphics from the beach scheme in the summer scheme.
In edit3.ini:
[scheme_6]
Name=Summer (SSF)
MiniMapGamma=150
DataDir1=..\_lng\;..\_game_scheme6\;..\_game_scheme5\;_edit_scheme6\;_edit_scheme5\
DataDir2=..\_desc_common\;_edit_common\
Here, too, we are referencing the graphics and editor files of the beach scheme. However, we first specify the corresponding files of the newly created summer scheme, because the data for the ground textures is different. Since these are to be loaded from the summer scheme, summer scheme 6 must be named before beach scheme 5.

Now we need to copy and rename the files with the ground textures. The edt file must then be edited in the same way as described above. For the water terrain, the sequence 00 00 00 00 must be entered instead of 07 00 00 00, because in the summer scheme, water transitions to grass 1 (terrain 0) and not to sand (terrain 7).

Final note
Of course, we could have adopted the schemes as they exist in SSF, i.e., with the bulk of the data in the summer scheme, and the beach scheme adopting this data except for the ground textures. I did it the other way around here because I actually only wanted the beach scheme for my "Private Little Mod." So I transferred that first. To be honest, I only realized now, when I was preparing my notes for the forum, that the summer scheme could also be adopted with little effort.

That's all from me for now. I hope my explanations are of some use. If you have any questions, please post here. I will try to answer them.