Modding Basics 2: Mod Packaging
As you may have noticed, all mods come in SCS or ZIP packages. Packaging is something all mods have in common. Knowing how to package stuff is essential; you have to know how the file system of Euro Truck Simulator 2 works before you can have a working mod or map. Therefore, this lesson is about packaging, an essential skill you need to master if you want to make (map) mods.
Setting up your package application
Mods are packaged in ZIP or SCS files. To package these files, a proper packaging tool is required. Most compression applications (7zip, WinRar) are able to read the ZIP format. However, most SCS packages out there are nothing more than ZIP packages with a different file extension. If you force your packaging tool to open the file, it will be opened perfectly fine.
For quick access, you can also set your packaging tool as standard application to open these packages. Both Windows and Linux-based systems have straight forward approaches for this. For Windows, if no other program is assigned to the SCS extension, a screen pops up where you can set a standard application for this to open. Select your packaging tool and click "OK". Now you can open the package by clicking on it.
Well, that was easy enough!
Note: Not all packages can be opened by this method. There are two categories of packages that can't be opened by this method:
- Locked packages (example: the ProMods asset package)
- The SCS base game packages that are located in the installation folder of Euro Truck Simulator 2. For that, there is a drag and drop application from SCS their website, which can be found here
Relative file paths: how the ETS2 file system works
The next part is a bit harder to grasp: how does ETS2 read its files? The way how ETS2 handles files is essential to know if you want to make mods. ETS2 uses so called
relative file paths. This means that all file paths that are defined in definition files, but also the entire file structure is based upon the fact that every path is relative to a given "base" folder.
To illustrate the difference between the two, I'll give you two examples of file paths, one with the absolute file paths you are all familiar with and one with a relative file paths. Say, you want to do something with the dutch traffic lights. For the dutch traffic lights, you have model files, texture files and of course, definition files containing the entries. Now, I have extracted all the files from the base packages in my Euro Truck Simulator installation folder. The absolute file paths of these files are
Code: Select all
C:\Program Files (x86)\Steam\SteamApps\common\Euro Truck Simulator 2\model\traffic_light\city_nl.pmc
C:\Program Files (x86)\Steam\SteamApps\common\Euro Truck Simulator 2\model\traffic_light\city_nl.pmd
C:\Program Files (x86)\Steam\SteamApps\common\Euro Truck Simulator 2\model\traffic_light\city_nl.pmg
C:\Program Files (x86)\Steam\SteamApps\common\Euro Truck Simulator 2\model\traffic_light\traffic_lights_nl.dds
C:\Program Files (x86)\Steam\SteamApps\common\Euro Truck Simulator 2\model\traffic_light\traffic_lights_nl.tobj
C:\Program Files (x86)\Steam\SteamApps\common\Euro Truck Simulator 2\automat\02\ea743e2753ff4fdcbe4127e2668d26bdc29d8b.mat
C:\Program Files (x86)\Steam\SteamApps\common\Euro Truck Simulator 2\def\world\semaphore_model.sii
An important thing to notice that these paths will only work on this system with this particular setup. If you do this on another PC, the paths can be very different. If ETS2 were using these kind of paths, mods would be incredibly picky on where you place your mod files (OK, it is still picky, it only works if the mod is in the mod folder), and zipped packages may not even work in that system.
Now, let's take a look again with relative paths, which the game uses in all its definition files:
Code: Select all
/model/traffic_light/city_nl.pmc
/model/traffic_light/city_nl.pmd
/model/traffic_light/city_nl.pmg
/model/traffic_light/traffic_lights_nl.dds
/model/traffic_light/traffic_lights_nl.tobj
/automat/02/ea743e2753ff4fdcbe4127e2668d26bdc29d8b.mat
/def/world/semaphore_model.sii
Most people who are familiar with Linux-based systems see something familiar: the path begins with a "/". However, this is not the root folder of your computer's file system; it's the root (or base) folder of the package! The game reads every package with this file structure, where the root folder of the package is the same root folder in the game's file system. This allows separate package to be merged once the game reads them. As an example, let's take the three ProMods packages. In the image below, you see the three packages opened in their root folder:
DISCLAIMER: this is a work-version of ProMods you see here. The package on the left is locked in public versions.
You see the same file structure coming back again. Now, you have three separate packages here, but once the game reads them, the folders you see here are at the same level in the file structure.
Additions and overrides
As you may know, the game reads each package in alphabetic order. Each file in a package can have two functions: being an addition or an override.
An addition is a file that is new and has not been loaded before in the loading order of the game. They do not affect any existing content.
An override is a file with the
exact same file name and relative file path as an file that has been loaded earlier. Since the game can't cope with two files having the same file name and relative file path, the game will
always use and
only use the file that has been loaded last. This allows you to override files from packages that are loaded earlier in the loading order. If this system didn't work this way, map mods and any other mods wouldn't work at all.
So, those were the basics of packaging!
Next lesson: Mapping basics
Best,
MandelSoft