Games/ETS2/Modding guides/1.54

Introduction

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.

Recommendations

• 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

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

Changes & New Features

Cargo system

New cargo system aims to decouple trailer and it's cargo model to generic assembly. Where trailers with specific loading methods will be able to automatically load any cargo that uses it. The system is designed to independently define trailer data from cargo data.

Basically binding cargo to trailer remains the same via cargo model match. What changes is how this two are bound together. If for example you are working on a new trailer that should support existing cargoes in the game you just need to define body with proper cargo_loading_methods and rest of auxiliary data in the body. No need for cargo data extension.

Similarly if you want to add new cargo, in majority of cases you don't need to touch any trailer data. Everything should work once you define new cargo model match, except in the case of custom loading method where you need to define custom loads data per body per cargo. This loading method should be last resort in case you special cargo is not able to use any other loading method.

So in summary what you need to do, depends whether you are adding new trailer or new cargo to the game:

• For new trailer: setup trailer data via accessory_trailer_body_data_u and ensure your trailer is using body accessory and has linked trailer_def_u unit. In the case of owned trailer, it is linked inside trailer_body_set_u unit and in case of the freight market trailer it is linked inside master trailer_u defined inside /def/vehilce/trailer/<trailer>.sui
• For new cargo: define cargo_data_u as until now and newly put cargo model match and belonging cargo accessory in the folder: /def/vehicle/cargo/<cargo_name>/.

Trailer data

To support cargo loading and lashing on trailer, body accessory needs to be used, it's mandatory, since cargo system loads new attributes from it:

• cargo_loading_methods[] - array of tokens representing supported cargo [loading methods|#Loading-Methods] by this body
• cargo_regular_width - float representing at which width extension parts for the trailer are switched on
• cargo_warning_signs - bool value indicatin whether body should have warning signs part switching supported or not
• cargo_areas[] - array of area sizes (X,Z) that are used for any of area based loading method
• cargo_areas_cylinder_data[] - array aligned with cargo areas, storing additional data for cylinder based loading (each item representing height, slope angle for given cargo area)
• cargo_custom_loads[] - array of cargo_custom_load_data_u unit pointers storing custom load offset per cargo
• cargo_lashing_mounts[] - array of cargo_lashing_mount_u unit pointers storing lashing mount definitions
• cargo_lashing_strap - unit pointer to cargo_lashing_gear_u storing configuration of lashing gear used when strap gear method is sečected by the cargo model match
• cargo_lashing_chain - unit pointer to cargo_lashing_gear_u storing configuration of lashing gear used when chain gear methods is selected by the cargo model match.

Cargo Custom Load Data

New unit cargo_custom_load_data_u was introduced to store custom load placement for the cargo model match:

• cargo_token - cargo suffix token for which this custom load data are used
• offset - position offset from cargo locator
• rotation - rotation offset from cargo locator in degrees

Cargo Lashing Mount

New unit cargo_lashing_mount_u was introduced used on vehicle body to lash cargo on and define the open/closed ring models:

• spacing - float defining space between individual lashing mount points on the lashing mount
• hook_angle_constraints - float3 defining angle constraints on each axis for the hook used with this mount, ranging from 0 to 90° (zero meaning no rotation allowed, 90° meaning 90 degrees into either negative or positive direction)
• open_model - string as path to the model placed on lashing mount when lashing is done to it
• closed_model - string as path to the model placed on lashing mount when when spaced position is not used (this model will be placed only in case spacing is grater than 0)

Cargo Lashing Gear

New unit cargo_lashing_gear_u was introduced to store lashing gear data:

• material - string referencing material to represent generated geometry lash look
• size - float2 defining width and height of generated lashing geometry intersection
• texcoord_uratio - float defining U ratio of texture used within material of generated geometry: uratio = texture_width / texture_height
• start_hook - string as path to the model to be added on the start of the generated lashing path
• start_hook_length - float as length from model origin to the hook end it it's forward direction for which lashing will be offset
• end_hook - string as path to the model to be added on the end of the generated lashing path
• end_hook_length - float as length from model origin to the hook end it it's forward direction for which lashing will be offset
• binder - string as path to the binder model that is inserted on first part of lashing, model has to be placed along forward direction to be properly aligned with generated lashing
• binder_length - float as length from model origin to the end of the binder bottom in it's inverse forward direction

Cargo model match data

Existing cargo model match unit was reworked and now supports following attributes:

• data_path - array of strings defining different models of same cargo model match (aka has same dimensions but different look)
• dimensions - float3 representing dimensions of the cargo model match in each axis (X,Y,Z). Y component is currently ignored however might be used in the future.
• unit_volume_factor - float as factor of the cargo unit volume defined in cargo data. This is usually used to distinguish different cargo model matches of the same cargo, that have completely different visual and thus different ratio to the cargo unit volume. Unless you are not defining new cargo model matches for existing cargo nor you have multiple cargo model matches you should not define it
• loading_method - token of the loading method cargo model match will be using, see [more|#Loading methods]
• lashing_method - token of the lashing method cargo model match will be using, see [more|#Lashing methods]
• lashing_gear_type - token of the lashing device cargo model match will be using, see [more|#Lashing gear types]
• lashing_hook_angle_constraints - float3 defining angle constraint on each axis of the hook in range between 0 and 90° (this will work similarly as angle constriants on body lashing mounts except that his is applied only when direct lashing is used for the cargo model match)

Common structures

TBA