Games/ETS2/Modding guides/1.33

From SCS Modding Wiki
< Games‎ | ETS2/Modding guides
Revision as of 19:55, 27 November 2018 by ErykDwornicki (talk | contribs) (Mods localization support)

Jump to navigation Jump to search

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

  • If your mod adds Estonia, Latvia, Lithuania, Russia or Finland update your country, ferry, semaphore model and semaphore profile definitions to avoid conflicts.
  • Load map
  • Do rebuild (F8)
  • Save map
  • Select correct looks for models where the selection of the looks changed

Changes & New Features

Cloud Profiles

This update supports use of Steam Cloud which can be enabled on per driver profile basis. Please note that the cloud is only used to store the profile data and saves. If you are using cloud to synchronize profiles between multiple computers, you still need to ensure that the mods required by those profiles are available and updated on all relevant computers either using Steam Workshop or manually.

If profile is not opted-in into the cloud, which is the default behavior for already existing profiles, it will be stored in "Game User Path/profiles" as before. If profile is opted-in, most of its files are managed internally by the Steam Client. There is still small part of profile configuration which is not stored on the cloud. It contains setting related to HW such as input binding or sound settings. This portion is stored in "Game User Path/steam_profiles"" and you need to configure this part on each new computer you use the cloud profile on.

As with the opted-out profiles, the game will create a backup copy of the profile the first time a new version of the game runs on the computer. Note that the backup copy is created as a local copy. If you want to restore something from it, you need to opt-out the profile from the Steam, copy the files from the backup and then opt-it back in.

Unit naming changes

The parsing of unit names from sii files is now more strict. Previously it ignored dots at end of the name (e.g. "vehicle.something.") and considered multiple consecutive dots as one (e.g. "vehicle..something"). Starting with 1.33 both those names are invalid and will fail to load. Additionally the total number of the dot separated components of the name is now limited to 10.

Prefab changes

Added "Long Trailer" spawn point type. On this point no check against allowed_trailer_length is performed. If company prefab contains at least one long trailer point, unlimited trailer are also delivered to prefab (easy point) by game economy.

City data

Added city_name_localized and short_city_name_localized attributes for name localization feature. If not defined explicitly it defaults to closest logical variant (short to non-short, localized to non-localized). Attribute city_name_uppercase has been removed and the string is created by game from proper localized or non-localized name.

Country data

Added name_localized for name localization feature. Used in same way as original name before. Original name now contain untranslated name (much like the city). If name_localized is not defined explicitly it defaults to name.

Ferry data

Added ferry_name_localized for name localization feature. If not defined explicitly it defaults to ferry_name.

Game data

  • Attribute glass_config was made obsolete as interior glass configuration is now in separated file: /def/vehicle/interior_glass_config.sii.

Interior glass config

Whole configuration about glass panes is now accessible at /def/vehicle/interior_glass_config.sii.

Additionally there are three new attributes introduced with improved rain wiping algorithm:

  • [float] no_rain_ageing_factor - Modulator of aging of the drops with low or no rain intensity. The lower the value within <0,1> range, the longer will take the drops to dry when there is no rain or is at low intensity.
  • [float] drops_wiping_factor - Factor in range <0,1> defining ratio between drops being moved vs. wiped, where 0 means all drops will be moved and 1 means all drops will be removed when in contact with wiper.
  • [float] drops_moving_offset - Offset in meters for which drops are offset in the direction of wiper movement.

Traffic trailer data

Using company paint jobs for traffic trailers has been simplified. It is no longer needed to create separate trailer data variant for each paint job. An automatic company paint job selection has been added, which randomly selects one of the paint jobs stored in company_paint_job directory at corresponding trailer chassis definition location (i.e. player trailer paint jobs). This feature can be turned on using the following attribute in traffic trailer definition:

company_paint_job: true

Mods localization support

From 1.33 mods can add new localization strings. To do this inside directory /locale/$language$/ you have to create localization module. The module file name should be called that way: local_module.$mod_name$.sii for example local_module.mod_awesome_jobs.sii. The file must define single unit of class localization_db.

Note: $language$ should be name of the language the localization is for, for example: british english is en_gb, polish is pl_pl etc.

Example:

SiiNunit
{
localization_db : .localization
{
        key[]: "chassis" # This is localization token, you can use it by typing @@chassis@@.
        val[]: "Chassis" # This is its value in the language. For every language this value can be different.

        key[]: "truck_cabin" # Another localization token.
        val[]: "Cabin" # And its value - as you can notice its always pair of key and val attributes.

        # ...
}
}

If you do so your mod should be properly localized now.

Note: Mods localization cannot override strings that are already added. That means localization defined by mod with highest priority will be used.

TIP: Our system does not fallback untranslated tokens to english so you have to define localization for all languages supported by the game. Currently game supports following list of the languages.

bg_bg, ca_es, cs_cz, da_dk, de_de, el_gr, en_gb, en_us, es_es, es_la, et_ee, eu_es, fi_fi, fr_fr, gl_es, hr_hr, hu_hu, it_it, ja_jp, ka_ge, ko_kr, lt_lt, lv_lv, mk_mk, nl_nl, no_no, pl_pl, pl_si, pt_br, pt_pt, ro_ro, ru_ru, sk_sk, sl_sl, sr_sp, sr_sr, sv_se, tr_tr, uk_uk, vi_vn, zh_cn, zh_tw

If you cannot afford translating your mod to each language we recommend to at least copy english localization to rest of them.