On Cross-Game Compatibility for Mods

Post Reply
User avatar
Posts: 52
Joined: 08 Sep 2019 11:24
Location: Western Pomerania

On Cross-Game Compatibility for Mods

#1 Post by derLPMaxe » 07 Apr 2020 13:55

G‘day everyone,

this thread is supposed to gather information on how to make mods for ETS2 and ATS compatible with both games without the need of porting the mod.
I‘m new to modding SCS games so pardon me if my assessments are shallow, my conclusions naïve and my terminology trivial and sometimes confusing. Also pardon my Linux.


A mod created for instance for ATS may depends on content from the game‘s archives (like base.scs; I reckon that‘s the case for fender mirrors for ATS, but can be the case for other things, too). As of now, this content has to be included into a port. In general, this is not an issue, but can be, if it uses content that cannot be included. This method can also become an issue when updates are rolled out.
The current situation around porting can be time-consuming and is not user-friendly, which, as a side-effect, is to some extend operationally splitting the community.
And to not talk around the elephant in the room for too long: I, and I‘m sure many others, have an interest in a common framework to use ATS and ETS2 content across both games either for modding or gaming, because they both feature cool exclusive contents and it‘s not always possible to include these into mods. Also, as far as I understand, porting mods often means rewrtiting the definitions, this should be made obsolete for future mods by the solution to be found. In general, any additional work to port mods should be made obsolete by a solution.

A proposed solution:

For short, a framework in a standardised structure, utilising directories and/or relative symbolic links to order content, definitions to specify the content needed by the specific mods, complemented by game archives provided by the end-user.
In detail, let‘s discuss this with the example of a hypothetic cross-game compatible mod depending on content from both ETS2 and ATS, installed for ETS2. The dependencies are the base.scs archives from the respective games.

Directory structure of framework for ETS2 (would be almost the same for ATS):

Code: Select all

	/Euro\ Truck\ Simulator\ 2
			/scs 		// is a symbolic link to ../American\ Truck\ Simulator, where-ever that is
			/community 	// is a symbolic link to the ATS mods folder
			/scs 		// is a symbolic link to ../Euro\ Truck\ Simulator\ 2
			/community	// is a symbolic link to the ETS2 mods folder
Instead of accessing ETS2's base.scs via

Code: Select all

../Euro\ Truck\ Simulator\ 2/base.scs
, for the mod, the program is instructed to access it via

Code: Select all

../Euro\ Truck\ Simulator\ 2/ets2_content/scs/base.scs
, which is essentially the same, but important for compatibility with ATS.


Instead of including the ATS dependencies into the mod archive, the program is instructed to access these via

Code: Select all

../Euro\ Truck\ Simulator\ 2/ats_content/scs/base.scs
which, being routed through a symbolic link is essentially the same as

Code: Select all

../American\ Truck\ Simulator/base.scs

The ../community symbolic links are to provide a common access point to dependencies on other mods.

In order to keep things as user-friendly as possible, I‘d argue for a configuration by a shell script (or batch file for Windows) that asks the end-user for paths to both game and mod directories of both games and then creates the structure. Either that, or we would do away with symbolic links and have the dependencies copied over manually by the end-user, which would be the next best solution in regards to user-friendliness but rather space consuming.


Obviously, this wont make content magically compatible. New definitions have to be written specifically for this framework, but if it works, it should provide a great compatibility platform. Also, updates can still break mods but in different ways.
I hope a solution to this problem can decrease time spent on porting and further unify the community.
Of course the premise this idea is based on could be totally wrong and much deeper work has to be done on the mod's archives in order to port them successfully.

Feel free to correct me and leave your thoughts and ideas down below.

Tip of the day: For compatibility with OpenGL (Mac & Linux), use BC3/DXT5 as the compression method and generate mipmaps when creating DDS files.
The unixoid truck-sim community thanks you. Thank you!

Fare thee as well as I fare.

Post Reply

Return to “Public research”

Who is online

Users browsing this forum: No registered users and 1 guest