- 1 Introduction
- 2 Recommendations
- 3 How to convert map
- 4 Changes & New Features
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_mapfolder just aside of exe. Older
basefolder is still used for saving other data (eg. weather settings)
- 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. Copy them to exe placement and run the batch file. It will run the fixing exe (modified editor) with proper params. Load your map, check the affected items (list in in txt file) fix whatever you want or need and save the map and exit. Rmove the fix. This process should be done ONLY ONCE as repeated run of the fix would move those items again.
You can then continue in regular way.
- Load map
- Do rebuild (F8)
- Save map
Changes & New Features
Editor now saves map files into ```base_map``` folder. All other data (eg weather settings) are still store into ```base```.
many other features, TBD
updated to version 2.01.01 (data update during betas), removed defaults, separate sounds per truck, TBD
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:
- eut2.sky.rfx - used on the clouds part (hi-res clouds ring)
- eut2.sky.stars.rfx - used on the stars part
- eut2.sky.back.rfx - used on the back part (low-res clouds background)
These need to be correctly set in the materials of the skybox model itself.
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_texture, the engine expects that the texture contains both stars and clouds, and everything should appear to behave as it used to.
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.
"null", stars are not rendered.
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.
- many SII files (units) that should be SUI files (includes) renamed, TBD
License plate data
- changed generation rules
- data-driven city LP probability
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.
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).
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)
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: "traffic.vehicle.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.