Sudden-Strike-Maps

Greetings to the community,

Any possible tutorial somewhere on how to add schemes to a mod/game like SS2? For example I need to get the desert and the winter schemes from Sudden Strike Forever to Sudden Strike 2, and is it easier to do this operation using another mod in the SS2 engine?

Any answer would be appreciated and thanks in advance

I think it would be easier to take the SSF schemes from a mod based on SuSt II or SSRW. In SSF some of the resource files containing the landscape graphics have a slightly different structure. In a mod these would have been adapted to SuSt II already. You can also use a mod based on SSRW because SSRW schemes are compatible with SuSt II afaik.

On the other hand: A scheme from SSF that has been adapted for a later part of the series might be not pure SSF. You should check if all resources match the original. For example many mods have integrated new objects. Other objects from SSF might be missing. Houses (houses.rs2, in SuSt II dom.res) are another problem. It seems that SuSt Graph does not work with the houses.rs2. This might be due to a different file structure caused by additional functionality of houses in SuSt II. Other rs2 files you can rename to *.res and use them in SuSt II or SSRW. Rule of thumb: If you can open the res file using Tijn's Res Converter the res file is compatible.

Regarding ground textures (rhombs, in mappic.rs2): Winter and desert scheme contain some textures from the summer scheme but do not define correct transitions from these ground types to those designed for the scheme. You can see this if you put all ground textures on a map in the editor. You should delete these textures or (better) rework the transition tiles.

Adding a scheme actually is not too complicated. Copy the scheme's res files and add the new scheme in sudtest.ini. Then copy the scheme's editor res files and add the new scheme in edit3.ini. For the entries to the ini files you can refer to the scheme entries already contained there. As always the devil is in the details. You will have to transfer the information contained in the desc files. There are some differences between SSF and SSRW regarding desc parameters iirc.

I have tried to convert the beach scheme from SSF to my private little mod based on SSRW some time ago. I will try to locate my notes and post more as soon as I find them.

I see, thanks for the reply
Can I get a link to Tijn's tool?

All the tools you can wish for here

I could not find the Res Converter in the collection above. I will search my hard disk and post it later.
Res Exporter
This tool is even better for your project because you can shift objects from one scheme to another.

Great to hear, thanks, please post it later when you find it

Found it
Still searching for my notes on converting a scheme from SSF to SSRW.

Awesome, thanks comrade!
So now there's two, one by medevac and the one you've just shared, is there a difference?

Yes, there is. The tool I have uploaded is more or less a viewer for objects while the Res Exporter can transfer objects from one scheme to another. I like to use the Converter for browsing schemes.
By the way: I finally managed to find my notes on scheme conversion but I will need some time to prepare them for posting as they are scrbbled on paper. Don't expect too much though. My experiment had not been 100% successful. I would definitely recommend looking for a mod that contains the SSF schemes. It will save you a lot of time and tedious work.

Got it, thanks commander.

Ich stelle meine Vorgehensweise am Beispiel des Strandschemas aus SSF vor.

Ich gehe hier davon aus, dass sämtliche sue-Dateien (auch die des Editors!) aus SSF und SSRW entpackt vorliegen. Zum Testen des übernommenen Schemas in SSRW ist es hilfreich, wenn dort die Dateien sudtest.ini und edit3.ini so modifiziert werden, dass das Spiel und der Editor mit den entpackten sue-Dateien arbeiten können. Das erspart viel Arbeit, weil die sue-Dateien dann nicht dauernd entpackt und neu gepackt werden müssen.
Wie man das erreicht, habe ich vor langer Zeit hier und hier beschrieben.

Noch ein Hinweis zu den bei SSF an vielen Stellen auftretenden Dateien VSSVER.SCC: Bei diesen Dateien scheint es sich um automatisch vom Entwicklungssystem erzeugte Dateien zu handeln. Auf stackoverflow.com werden sie als „part of the Visual SourceSafe binding mechanism“ und als „safe to delete“ bezeichnet. Ich habe testweise die Dateien VSSVER.SCC gelöscht, ohne dass dies bei einem längeren Test mit SSF erkennbar negative Auswirkungen hatte. Es scheint, als seien die Dateien wirklich verzichtbar.

1 Überblick verschaffen
Um die sue-Dateien des Strandschemas zu identifizieren, genügt ein Blick in die ini-Dateien des Spiels und des Editors. Dort werden die Einträge zum Strandschema gesucht. In editor2.ini finden wir die folgenden Zeilen:
[scheme_3]
MiniMapGamma=150
Name=Strand
DataDir1=desc_common.sue
DataDir2=desc_summer.sue
DataDir3=RES\
DataDir4=common.sue
DataDir5=units_edit.sue
DataDir6=beach.sue
DataDir7=beach_edit.sue
DataDir8=summer.sue
DataDir9=summer_edit.sue
Es ist zu erkennen, dass sowohl die Dateien des Strandschemas als auch die des Sommerschemas verwendet werden. Das liegt daran, dass das Strandschema weitgehend mit dem Sommerschema identisch ist. Der einzige Unterschied ist, dass die Übergänge der Bodentexturen (Rhombs) anders definiert sind. Im Sommerschema gehen fast alle Terrains in die Grastextur von Gras 1 über. Die einzige Ausnahme ist Boden 2 mit einem Übergang zu Boden 1. Im Sommerschema geht Wasser aber in Sand über, nicht in Gras 1.

In der sudtest.ini wird das Strandschema so definiert:
DataPathScm3_0=beach.sue;summer.sue;desc_summer_00.sue;desc_summer.sue
DataPathScm3_2=summer.sue
Dazu kommen noch die folgenden Einträge zu „Schema 0“. Diese dürften für alle Schemata gelten, denn hier werden schemaunabhängige Dateien angegeben, z.B. die Einheiten und Animationen mit ihren Desc-Dateien.
DataPathScm0_0=common.sue;units_00.sue;units.sue;animats.sue;desc_common_00.sue;desc_common_00.sue;desc_common.sue
DataPathScm0_1=common.sue

Welche Dateien brauchen wir?
Die für die Konvertierung des Schemas relevanten Dateien können wir leicht finden, wenn wir uns die Einträge des Schemas in den ini-Dateien anschauen. Zu einem Schema gehören
- die Grafikdateien der Landschaftselemente
- die Desc-Dateien, die Informationen über diese Landschaftselemente enthalten
- die Editordateien der Landschaftselemente
Die Landschaftselemente kennen wir aus dem Menü des Editors:
Terrain, Free Objects, Horizontal Objects, Vertical Objects, Trees, Roads, Houses, Cliffs, Craters, Bridges und Fences.
Zu diesen Kategorien finden wir in SSF die Dateinamen
mappic (in SSRW rhombs), fre, lay, stand, tree, trop, houses (in SSRW dom), cliff, vor, most und zabor
Einige Dateinamen kommen im SSF-Editor und sogar in den sue-Dateien eines Schemas mehrfach vor. Dann gilt die Regel, dass diejenige verwendet wird, die in der in sudtest.ini zuerst aufgezählten sue-Datei enthalten ist. Das ist z.B. für die Bodentexturen von Bedeutung, denn eine Datei mappic.rs2 gibt es in beach.sue und in summer.sue. Da beach.sue in der sudtest.ini vor summer.sue genannt wird, verwendet das Strandschema die Version aus beach.sue.

Die Grafikdateien des Strandschemas finden wir in beach.sue und summer.sue. Sie haben in SSF die Dateiendung *.rs2, in SSRW dagegen *.res. Zu den meisten Grafikdateien gehört noch eine gleichnamige Datei mit der Dateiendung *.pl, in der die Farbpaletten für die Grafiken gespeichert sind. Ausnahmen sind mappic.rs2, zu der die Palettendatei rhomb.pl gehört, sowie houses.rs2 und most.rs2, zu denen keine Palettendatei existiert, weil die Paletten zusammen mit den Grafiken in der rs2-Datei gespeichert sind.

Die Desc-Dateien haben meistens die gleichen Dateinamen wie die Grafikdateien, tragen aber in der Regel keine Dateiendung. Es sind reine Textdateien, die wir in jedem Texteditor bearbeiten können. Ich benutze gern NotePad++, aber auch der Windows-eigene Texteditor kann verwendet werden.
Wir finden die benötigten Dateien in desc_common.sue und desc_summer.sue (eine desc_beach.sue existiert nicht).

Die Editordateien haben ebenfalls den gleichen Dateinamen, der aber meistens die Dateiendung *.edt hat. Die Ausnahme ist die Editordatei für die Bodentexturen mit dem Namen mappic.sb2. Zu den Bodentexturen gehört auch noch die Datei scheme.ini im Hauptverzeichnis von SSF. Dazu später mehr. Eine weitere Ausnahme betrifft die Zäune: Hier gibt es keine Datei zabor.edt, nur eine Datei zabor.tbl.
Editordateien sind in beach_edit.sue und summer_edit.sue zu finden.

In den sue-Dateien, in denen all diese Dateien enthalten sind, liegen noch einige weitere. In summer.sue gibt es eine rs2- und eine pl-Datei für die Pontonbrücken (pont) und eine Palettendatei user.pl, deren Zweck mir nicht klar ist. In summer_edit.sue sind die Dateien bred.rs2 und bred.pl enthalten, deren Bedeutung ich leider ebenfalls nicht kenne. Hinweise gern hier posten.

I'll demonstrate my approach using the beach scheme from SSF as an example.

I'm assuming that all sue files (including those of the editor!) from SSF and SSRW are unpacked. To test the imported scheme in SSRW, it's helpful to modify the sudtest.ini and edit3.ini files in SSRW so that the game and the editor can work with the unpacked sue files. This saves a lot of work, because the sue files don't have to be constantly unpacked and repacked.
I described how to achieve this a long time ago here and here.

Another note regarding the VSSVER.SCC files that appear in many places in SSF: These files appear to be automatically generated by the development system. On stackoverflow.com, they are described as "part of the Visual SourceSafe binding mechanism" and as "safe to delete." I deleted the VSSVER.SCC files as a test, but during a longer test with SSF, this had no noticeable negative effects. It seems that the files are dispensable.

1 Getting an Overview
To identify the sue files for the beach scheme, simply look in the ini files of the game and the editor. The entries for the beach scheme can bei found there. In editor2.ini, we find the following lines:
[scheme_3]
MiniMapGamma=150
Name=Beach
DataDir1=desc_common.sue
DataDir2=desc_summer.sue
DataDir3=RES\
DataDir4=common.sue
DataDir5=units_edit.sue
DataDir6=beach.sue
DataDir7=beach_edit.sue
DataDir8=summer.sue
DataDir9=summer_edit.sue
It can be seen that both the beach scheme and the summer scheme files are used. This is because the beach scheme is largely identical to the summer scheme. The only difference is that the transitions of the ground textures (rhombs) are defined differently. In the summer scheme, almost all terrains transition into the grass texture of Grass 1. The only exception is Ground 2, which transitions to Ground 1. However, in the summer scheme, water transitions into sand, not into Grass 1.

In sudtest.ini, the beach scheme is defined as follows:
DataPathScm3_0=beach.sue;summer.sue;desc_summer_00.sue;desc_summer.sue
DataPathScm3_2=summer.sue
In addition, there are the following entries for "Scheme 0." These should apply to all schemes, as they specify scheme-independent files, e.g., the units and animations with their DESC files.
DataPathScm0_0=common.sue;units_00.sue;units.sue;animats.sue;desc_common_00.sue;desc_common_00.sue;desc_common.sue
DataPathScm0_1=common.sue

Which files do we need?
The files relevant for converting the scheme can be easily found by looking at the scheme entries in the ini files. A scheme includes:
- the graphic files of the landscape elements
- the DESC files that contain information about these landscape elements
- the editor files of the landscape elements
We know the landscape elements from the editor menu:
Terrain, Free Objects, Horizontal Objects, Vertical Objects, Trees, Roads, Houses, Cliffs, Craters, Bridges, and Fences.
For these categories, we find the file names in SSF:
mappic (in SSRW rhombs), fre, lay, stand, tree, trop, houses (in SSRW dom), cliff, vor, most, and zabor
Some file names appear multiple times in the SSF editor and even in the scheme's sue files. The rule then applies that the one contained in the sue file listed first in sudtest.ini is used. This is important, for example, for the ground textures, because a mappic.rs2 file exists in beach.sue and summer.sue. Since beach.sue is listed before summer.sue in sudtest.ini, the beach scheme uses the version from beach.sue.

The graphic files of the beach scheme can be found in beach.sue and summer.sue. In SSF, they have the file extension *.rs2, whereas in SSRW they have the file extension *.res. Most graphic files also have a file of the same name with the file extension *.pl, which stores the color palettes for the graphics. Exceptions are mappic.rs2, which contains the palette file rhomb.pl, as well as houses.rs2 and most.rs2, for which no palette file exists because the palettes are stored together with the graphics in the rs2 file.

The DESC files usually have the same filenames as the graphic files, but usually don't have a file extension. They are plain text files that can be edited in any text editor. I like to use NotePad++, but Windows' own text editor can also be used.
We can find the required files in desc_common.sue and desc_summer.sue (there is no desc_beach.sue).

The editor files also have the same filename, but they usually have the *.edt extension. The exception is the editor file for the ground textures, named mappic.sb2. The ground textures also use the scheme.ini file in the main SSF directory. More on this later. Another exception concerns the fences: There is no zabor.edt file here, only a zabor.tbl file.
Editor files can be found in beach_edit.sue and summer_edit.sue.

The sue files, which contain all these files, contain several more. In summer.sue, there's an rs2 and a pl file for the pontoon bridges (pont), and a palette file, user.pl, whose purpose is unclear to me. Summer_edit.sue contains the files bred.rs2 and bred.pl, whose purpose I unfortunately don't know either. Feel free to post any information here.

Nachdem die benötigten Dateien (hoffentlich) vollständig identifiziert wurden, müssen sie jetzt von SSF auf SSRW übertragen werden. Zunächst brauchen wir Verzeichnisse, in denen wir die für das Strandschema benötigten Dateien ablegen können. Diese Verzeichnisse müssen wir natürlich auch in den ini-Dateien von Spiel und Editor eintragen.

Anlegen eines neuen Schemas
Zuerst legen wir das neue Schema an. Wir sollten aber nicht alle Daten des Strandschemas auf einmal von SSF auf SSRW übertragen. Bei Fehlern und Problemen ist es dann nämlich schwer, die Ursachen für die Probleme zu finden. Stattdessen werden wir die Daten des Strandschemas nach und nach in eine Kopie des Sommerschemas von SSRW integrieren. Wir haben dann als Ausgangsposition ein funktionierendes Schema. Wenn eine Änderung zu Problemen führt, dann können wir gezielt die zuletzt übernommenen Daten überprüfen.
Da in Vanilla SSRW vier Kartenschemata vorhanden sind, wird das SSF-Strandschema das fünfte Schema. Daher legen wir die folgenden Verzeichnisse an:
- SSRW\desc_scheme5
- SSRW\game_scheme5
- SSRW\Editor\edit_scheme5
An dieser Stelle fällt mir ein, dass ich hier SSRW aus der deutschen Universe-Compilation verwende. Bei der 2004 veröffentlichten Version liegen alle Dateien eine Ebene tiefer im Verzeichnis Run. Wer also eine SSRW-Version mit anderer Verzeichnisstruktur benutzt, muss die Dateipfade entsprechend anpassen.
In diese Verzeichnisse kopieren wir jetzt die jeweils passenden Daten des Sommerschemas von SSRW.
- SSRW\desc_common\LAND nach SSRW\desc_scheme5\LAND
- SSRW\game_scheme1 nach SSRW\game_scheme5
- SSRW\Editor\edit_scheme1 nach SSRW\Editor\edit_scheme5
Zum Schluss muss das Schema noch in den ini-Dateien von Spiel und Editor eingetragen werden. In der sudtest.ini fügen wir die folgende Zeile ein:
scheme5=desc_scheme5\;desc_common\;game_scheme5\
Die edit3.ini im Editorverzeichnis wird um die folgenden Zeilen ergänzt:
[scheme_5]
Name=SSF Strand
MiniMapGamma=150
DataDir1=..\_lng\;..\_game_scheme5\;_edit_scheme5\
DataDir2=..\_desc_common\;_edit_common\

Now that the required files have (hopefully) been fully identified, they now need to be transferred from SSF to SSRW. First, we need directories in which to store the files required for the beach scheme. Of course, we also need to add these directories to the ini files of the game and editor.

Creating a new scheme
First, we'll create the new scheme. However, we shouldn't transfer all of the Beach Scheme data from SSF to SSRW at once. If errors and problems occur, it will be difficult to find the causes of the problems. Instead, we'll gradually integrate the Beach Scheme data into a copy of the Summer Scheme from SSRW. This will give us a working scheme as a starting point. If a change causes problems, we can specifically check the most recently imported data.
Since there are four map schemes in Vanilla SSRW, the SSF Beach Scheme will be the fifth scheme. Therefore, we create the following directories:
- SSRW\desc_scheme5
- SSRW\game_scheme5
- SSRW\Editor\edit_scheme5
At this point, it occurs to me that I'm using SSRW from the German Universe compilation. In the version released in 2004, all files are located one level lower in the Run directory. So, if you're using a version of SSRW with a different directory structure, you'll need to adjust the file paths accordingly.

We'll now copy the appropriate data from SSRW's summer scheme into these directories.
- SSRW\desc_common\LAND to SSRW\desc_scheme5\LAND
- SSRW\game_scheme1 to SSRW\game_scheme5
- SSRW\Editor\edit_scheme1 to SSRW\Editor\edit_scheme5
Finally, the scheme needs to be entered into the ini files of the game and editor. Add the following line to sudtest.ini:
scheme5=desc_scheme5\;desc_common\;game_scheme5\
The following lines are added to edit3.ini in the editor directory:
[scheme_5]
Name=SSF Beach
MiniMapGamma=150
DataDir1=..\_lng\;..\_game_scheme5\;_edit_scheme5\
DataDir2=..\_desc_common\;_edit_common\

Eine ganze Reihe von Dateien können ohne große Änderungen direkt in SSRW übernommen werden und zwar:

Freie Objekte (fre)
Wir löschen die aus SSRW stammende Dateien fre.res und fre.pl. Dann kopieren wir fre.rs2 und fre.pl aus summer.sue in das Verzeichnis game_scheme5 und benennen anschließend fre.rs2 in fre.res um. Die Editordatei fre.edt wird aus summer_edit.sue nach Editor\edit_scheme5 kopiert und überschreibt die dort vorhandene Version aus SSRW.
Die Desc-Datei fre aus desc_common.sue\land aus SSF stimmt mit der Variante aus SSRW\desc_scheme5\land überein. Es sind keine Anpassungen notwendig.

Horizontale Objekte (lay)
Die Übernahme der horizontalen Objekte klappt ebenfalls reibungslos. Wir löschen im Verzeichnis game_scheme5 die Dateien lay.res und lay.pl, kopieren lay.rs2 und lay.pl aus summer.sue nach game_scheme5 und benennen lay.rs2 in lay.res um. Dann kopieren wir lay.edt aus summer_edit.sue nach Editor\game_scheme5 und überschreiben damit die vorhandene Version. Die Desc-Dateien stimmen bis auf die in SSRW fehlenden Soundeinstellungen aus #igor\land\lay überein. Wir können daher die SSRW-Datei beibehalten.

Krater (vor)
Wir löschen die Dateien vor.res und vor.pl aus game_scheme5, kopieren die Dateien vor.rs2 und vor.pl aus summer.sue nach game_scheme5 und benennen vor.rs2 in vor.res um. Eine passende edt-Datei existiert in summer_edit.sue nicht. Das gilt ebenso für die übrigen SSF-Schemata und auch für die Schemata aus SSRW. Also benötigt der Editor wahrscheinlich keine zusätzlichen Informationen über Krater. Die Desc-Dateien sind identisch, sodass keine Anpassung erforderlich ist.

Zäune (zabor)
Die Dateien zabor.res und zabor.pl aus game_scheme5 werden gelöscht. Die Dateien zabor.rs2 und zabor.pl werden nach game_scheme5 kopiert und zabor.rs2 wird in zabor.res umbenannt. Die leere edt-Datei aus SSRW wird zunächst unverändert gelassen und die Datei zabor.tbl aus summer_edit.sue entsprechend ignoriert. Ein Test im Editor und im Spiel sollte ohne Probleme verlaufen. Nun vergleichen wir die Desc-Dateien.
Die Desc-Datei aus SSF:
#igor\land\zabor
Level 5
Der Include-Link #igor\land\zabor verweist auf die folgenden Soundeinstellungen:
CrackSound type 0 hedge 0.4 load
CrackSound type 1 hedge 0.4 load
CrackSound type 2 hedge 0.4 load

Zum Vergleich die Version aus SSRW:
Level 5
CrackSound type 0 hedge 0.3
CrackSound type 1 hedge 0.3
CrackSound type 2 wire 0.3

Der Level-Parameter hat in beiden Versionen den gleichen Wert. Da bei den Zäunen aus SSF ein Weidezaun, ein Gartenzaun und ein Stacheldrahtverhau vorhanden sind, erscheint mir der CrackSound wire in der SSRW-Version geeigneter, was letztlich den Ausschlag dafür gibt, die SSRW-Datei beizubehalten.

A lot of files can be imported directly into SSRW without major changes:

Free Objects (fre)
We delete the files fre.res and fre.pl originating from SSRW. Then we copy fre.rs2 and fre.pl from summer.sue to the game_scheme5 directory and then rename fre.rs2 to fre.res. The editor file fre.edt is copied from summer_edit.sue to Editor\edit_scheme5, overwriting the existing SSRW version.

The description file fre from desc_common.sue\land in SSF matches the version from SSRW\desc_scheme5\land. No adjustments are necessary.

Horizontal Objects (lay)
The import of the horizontal objects also works without problems. We delete the lay.res and lay.pl files in the game_scheme5 directory, copy lay.rs2 and lay.pl from summer.sue to game_scheme5, and rename lay.rs2 to lay.res. We then copy lay.edt from summer_edit.sue to Editor\game_scheme5, overwriting the existing version. The desc files are identical except for the sound settings from #igor\land\lay, which are missing in SSRW. We can therefore keep the SSRW file.

Crater (vor)
We delete the vor.res and vor.pl files from game_scheme5, copy the vor.rs2 and vor.pl files from summer.sue to game_scheme5, and rename vor.rs2 to vor.res. A matching edt file does not exist in summer_edit.sue. This also applies to the other SSF schemes and also to the schemes from SSRW. So the editor probably doesn't need any additional information about craters. The DESC files are identical, so no adjustment is necessary.

Fences (zabor)
The files zabor.res and zabor.pl from game_scheme5 are deleted. The files zabor.rs2 and zabor.pl are copied to game_scheme5, and zabor.rs2 is renamed to zabor.res. The empty edt file from SSRW is initially left unchanged, and the zabor.tbl file from summer_edit.sue is ignored accordingly. Testing in the editor and in the game should run smoothly. Now we compare the DESC files.
The DESC file from SSF:
#igor\land\zabor
Level 5
The include link #igor\land\zabor refers to the following sound settings:
CrackSound type 0 hedge 0.4 load
CrackSound type 1 hedge 0.4 load
CrackSound type 2 hedge 0.4 load

For comparison, the version from SSRW:
Level 5
CrackSound type 0 hedge 0.3
CrackSound type 1 hedge 0.3
CrackSound type 2 wire 0.3

The Level parameter has the same value in both versions. Since the SSF fences include a pasture fence, a garden fence, and a barbed wire fence, the CrackSound wire in the SSRW version seems more suitable to me, which ultimately led me to keep the SSRW file.