Open main menu

Games/ETS2/Modding guides/1.38

< Games‎ | ETS2/Modding guides



The following page contains modding guidelines for the new update of the game.

To better understand changes in units it is recommended to check Units documentation page.


  • When basing your model on the original ones, add to your mod also ALL original /automat/ files used by it. The names of the files are generated as CityHash64 hash of theirs content so whenever we change the parameters of the material in any way, a different file will be used to store them and the original file might cease to exist if there is no other model utilizing the original parameters.
  • When modifying original models, always include ALL components of the model (pmg+pmd) instead of just those you changed. Otherwise you risk crash if we change the model.
  • As always when adding new objects to files which support multi-file approach (e.g. road_look.sii) it is HIGHLY RECOMMENDED to use suffix or prefix in the name to avoid conflicts with new objects we are adding in patches. Otherwise you might have to use the batch renaming functionality (see Batch renaming) to fix the conflicts when new patch appears.

How to convert map

  • For saving the map you need to create base_map/map folder just aside of game executable exe. Former base folder is still used for saving other data (eg. weather settings in base/def).
  • There has been changes of some edge models (for easier and more exact snapping in future). If you are using them in your map you need to reposition them to fit new model and fix eventual other errors around. For simplification of the process there are helpers. Extract entire content of the zip file to game executable folder and run the batch file - it will run the fixer exe (modified editor) with proper params. Load your map and fixer automatically offsets those items by proper offsets all over the map. Then check the affected items over the map (complete name list is in the included TXT file), fix whatever you want or need, save the map, and exit the editor. Remove the fixer from the folder. This process should be done ONLY ONCE as repeated run of the fixer would move those items again.
  • [10M, exe+bat+txt files]
  • [10M, exe+bat+txt files]

You can then continue in regular way.

  • Load map
  • Do rebuild (F8)
  • Save map

Changes & New Features


Editor now saves map sector files into base_map folder. All other data (eg weather settings) are still store into base folder.

many other features, TBD


updated to version 2.01.01 (data update during betas), removed defaults, separate sounds per truck, TBD

Complete sound system documentation is described at Documentation/Engine/Sound.


Lots of significant changes have been made to the underlying workings of the skybox system.
Most importantly, we can now blend between both sun profiles and weathers at once (so 4 layers in total), this means that weather transitions may now be triggered automatically at any moment, including in the middle of a sun profile transition.


Each part of the skybox model is now being handled by a dedicated material.
As a result, the following effects have been removed:


And replaced by:

  • - used on the clouds part (hi-res clouds ring)
  • - used on the stars part
  • - used on the back part (low-res clouds background)

These need to be correctly set in the materials of the skybox model itself.

Climate definitions:

Previously, stars and clouds shared the same texture. It is now possible to separate the two via the stars_texture attribute, which now exists in place of the obsoleted skycloud_part attribute.

If stars_texture matches skycloud_texture, the engine expects that the texture contains both stars and clouds, and everything should appear to behave as it used to.
If stars_texture is different, then stars are rendered using this texture and the engine treats skycloud_texture as if it doesn't contain stars at all.
If stars_texture is "null", stars are not rendered.

A newly-added stars_opacity attribute accessible via the weather editor controls opacity of the stars.

Your existing climate definitions should still work. If the engine encounters a skycloud_part definition, a warning is displayed and the remaining attributes filled in accordingly.
However, you should still update your climate definitions to the current format, which can be done by simply loading up your climate definition in the weather editor and saving it.

Game data

Many SII files have been renamed to SUI and vice versa. Why?

By definition, SII files are the ones containing game units and are starting by SiiNUnit mark, while SUI files are included or shared part of some other unit and are not starting by any mark. This was generally true for a long time but game itself did not enforced it technically. Game data could include any file. Thus your mods might or might not work based on other conditions (namely file links in other files) now.

We unified the naming to this strict format to be better able to automatically test all game data and thus speed up development. We also encourage to change all modded data in same way to prevent errors.

License plate data

There was changed generation of LP slightly. Country-based LP are working exactly same as before: if vehicle type is matched that data set is used, otherwise first data set is used (regular car typically). City-based LPs has been working similarly except there was hardcoded pobability (33%) of using country-based LP instead. Right now city-based LP generation always checks both country and city data for defined vehicle types. If vehicle type is matched data sets are used, but if both country and city type definition exists the decision is based on probabilty field on city data. As default value is 0.67, it works similarly as before.

Main difference is that if you do not define city LP for some vehicle type, first fallback is to country LP for that vehicle type and only the secondary fallback is the first vehicle type in city LP list. Also you can enforce local LP if desired by setting probability to 1.0 in city-based LP definitions. As example, this behavior is used in Idaho DLC for emergency vehicles (medical, fire and police).

Vehicle data

Engine data

Default ranges tweaked a bit to better simulate behavior of modern engines and better use default torque curve. Default value of rpm_range_power is now (1400, 1900) and default value of rpm_range_high_gear is now (1000, 1350). Non-default data of few engines has been tweaked as well.

Interior data

There is new animation engine_brake_stick_anim. It is driven by engine brake user setting (input) from disabled to enabled with maximum intensity (similarly like retarder stick animation).

Accessory horn addon data

There is new unit type accessory_horn_addon. Its same as accessory_addon but in addition it contains attribute sound_path that could link soundref file or sound bank event directly. It is used for new horn accessories on ETS2 trucks.


Vehicle types

There has been an extensive cleanup and renaming among traffic vehicle types to bring more consistency into the type separation logic and consistency. Most of the type names are based on their real-world counterparts. They are further subdivided to allow correct application of traffic rules and/or some special behavior for all vehicles. There is more info in "/def/vehicle/traffic_vehicle_types.sii". Note together with type names, also traffic vehicle storages were renamed accordingly (/def/vehicle/traffic_storage*.sii). Please check if vehicle definitions added by mods are in correct storage(s)

Trailer types

Together with vehicle types, also several trailer types were renamed. Their names are based on the vehicle types they are used by. There is more info in "/def/vehicle/traffic_trailer_types.sii". Note together with type names, also traffic trailer storages were renamed accordingly (/def/vehicle/traffic_storage_trailer*.sii). Please check if trailer definitions added by mods are in correct storage(s)

Referencing multiple vehicle/trailer definitions

A new attribute tags (array of tokens) has been added to both vehicle and trailer data definitions. Tags serve as 'filters' which allow referencing multiple vehicle/trailer definitions without the need to name each unit name explicitly. The way of referencing has been unified across the traffic definitions. Now, each reference can be:

  • explicit unit name: ""
  • combination of vehicle/trailer type together with 1-3 inclusion/exclusion tags: "vehicle_type tag1_include1 !tag2_exclude tag3_include"

The unified system can now be used for:

  • traffic vehicle definitions (trailer_chains[])
  • parked vehicle hookup definitions (allowed_vehicle[] and allowed_trailer[])
  • parked trailer hookup definitions (allowed_trailer[])
  • spawn density rules

NOTE: this change made parked vehicle hookup attribute allowed_vehicle_type[] obsolete.