Changes

Jump to navigation Jump to search

Games/ETS2/Modding guides/1.9

21,015 bytes added, 09:07, 17 March 2016
m
50keda moved page Games/ETS2/Modding Guides/1.9 to Games/ETS2/Modding guides/1.9 without leaving a redirect
= Recommendations =
When adding new objects to files which support multi-file approach (e.g. road_look.sii) it is <strong>HIGHLY RECOMMENDED</strong> 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 <a href="[[#Batch renaming">Batch renaming</a>]]) to fix the conflicts when new patch appears.
Some new models utilizing the "sc" suffix or prefix are still work in progress and it is likely that they might change significantly in some next patch. For this reason it is recommended that you avoid using them in your mods at this time.
<li>Ensure that the log does not contain ANY errors related to missing signs. (see [[#Unit name checks">Unit name checks]])</li>
<li>If you added new road material or terrain material for use in a new sectors, you might want to rename them to add prefix or suffix to the name to avoid conflicts with the materials we added (see [[#Batch renaming]]).</li>
<li>Use the replacement dialog (F3, "Prefab node correction") to add to map nodes which we added to the prefabs (see <a href="[[#Changes in prefabs">Changes in prefabs</a>]]).</li>
<li>Save and reload the map or do rebuild (F8)
</li></ul>
 
= Changes =
== Changes in paintjobs ==
The trucks now have a additional third uv coordinates with improved layout and some paintjobs were updated to take advantage of that. The paintjobs can opt in to using this uv coordinate using a new <strong>alternate_uvset</strong> parameter in the paintjob definition. Please note that it is error when paintjob requires coordinate which the model does not have and the resulting behavior is undefined. This might happen if you modded a standard truck and the player I using one from the paintjobs which we updated. In that case you might want to include a older version of the paintjob definitions and textures in your mod.
 
== Changes in fonts ==
The font files now contain information about the sizes of underlying textures. You need to update all image definition lines to include the size.
 
For example:
<pre class="sii">image:/font/big_0.mat
</pre>
 
If the texture associated with /font/big_0.mat would have dimensions of 256x512 the new line should be.
<pre class="sii">image:/font/big_0.mat, 256, 512
</pre>
 
== Unit name checks ==
Many from the world definition files (e.g. /world/sign.sii) expect that the full unit names are starting with fixed prefix component (e.g. "sign.") which is followed by a single component with the name (There are few exceptions. When in doubt, see the naming used in the original file which is part of the game). Depending on the situation, the game might sometimes locate the units only using the name component or it might construct the full name from the fixed prefix and the name and locate the unit using this full name. To ensure that the game will find the unit using both methods, the units must use the expected naming convention.
 
For example the names of sign units are expected to start with "sign." so "fkmm070" or "add.navsg001" are <strong>not</strong> valid names and will be not found during map conversion.
 
The game will now check names in selected unit definition files and print error if name does not conform to the expected convention.
 
== Changes in ferries ==
The ferry definition format was enhanced to support addition of new connections to existing ferries without need to override the base .sii file.
 
In addition to the standard definition in the <strong>/def/ferry/&lt;name&gt;.sii</strong> files, the game will also load all files from <strong>/def/ferry/connection</strong>. Each from those files should contain a single <strong>ferry_connection</strong> unit (see example bellow) which defines connection between two ferries and must be named <strong>conn.&lt;from&gt;.&lt;to&gt;</strong> where <strong>from</strong> and <strong>to</strong> are names of respective ferries. The game will add specified connection to the base ferry definition or it will override its parameters if the connection already exists. Currently there is no way to remove existing connection using this mechanism.
 
If more than one file defines the same connection, it is undefined which one from them wins. For this reason the files should be named as <strong>&lt;from&gt;_&lt;to&gt;.sii</strong> (e.g. europoort_harwich.sii) even if the game currently does not enforce this.
 
Example of defining connection from eurpoort to harwich using a connection unit stored in <strong>/def/ferry/connection/europoort_harwich.sii</strong>
<pre class="sii">SiiNunit
{
ferry_connection: conn.europoort.harwich
{
price: 960
time: 480
distance: 207
}
}
</pre>
 
== Changes in city definitions ==
Added traffic related attributes: <ul>
<li> <strong>traffic_density_coef <br></strong> <ul>
<li> modifies the traffic spawn density around player (default value is 2.0)</li>
<li>if more cities are close enough, their density coefs are added
</li></ul> </li>
<li><strong>traffic_density_range</strong> <ul>
<li>default value is 2000.0</li>
<li>sets the maximum range <em>beyond city border</em> at which the traffic_density_coef is still applied</li>
<li>the value of traffic_density_coef applied is decreasing with distance: maximum value is at the border and 0.0 at the traffic_density_range
</li></ul>
</li></ul>
 
== Changes in road looks ==
The roads now support specifying different number of lanes in left and right part. They are defined using new <strong>lane_count_left</strong> and <strong>lane_count_right</strong> attributes. The <strong>ai_lane_count</strong> and <strong>one_way</strong> attributes are now obsolete. To keep backward compatibility with existing definitions, the game will override the value of the new attributes if <strong>ai_lane_count</strong> or <strong>one_way</strong> attributes are set in the definition. Please note that this fallback might be disabled in some future patch so it is highly recommended to update the looks to use the new mechanism. The feature only controls the AI behavior on the road and has no effect on the visualization of the roads. Support for more custom definition of road visualization including more lanes is planed for some future patch.
 
The <strong>ai_road_offset</strong> and <strong>actor_lane_count</strong> attributes are obsolete and ignored.
 
The <strong>ai_speed_type</strong> attribute is now enum with following values: none (-1), city (0), regular (1), highway (2). Direct numeric values still work at this time and are compatible with the previous state however using the name is preferred.
 
== Changes in road materials ==
To allow independent addition of road and sidewalk materials we extracted them to separate files ( <strong>road_material.sii</strong> and <strong>road_sidewalk.sii</strong>) which support the <strong>.&lt;idofyourmod&gt;.sii</strong> convention and suffixed/prefixed unit names. The values of the corresponding arrays inside <strong>road.sii</strong> are ignored.
 
When converting the map from old format, the material indices are converted to units which are suffixed by the same value (i.e. index 5 is mapped to unit road_mat.5). If you added materials which conflicts with the materials we added in this patch, you might want to use the renaming functionality to move your new material to new suffixed representation.
 
== Changes in terrain materials ==
As with road materials, the <strong>terrain_material.sii</strong> was changed to allow independent addition The <strong>.&lt;idofyourmod&gt;.sii</strong> convention and suffixed/preffixed unit names are supported.
 
When converting the map from old format, the material indices are converted to units which are suffixed by the same value (i.e. index 5 is mapped to unit terrain_mat.5). If you added materials which conflicts with the materials we added in this patch, you might want to use the renaming functionality to move your new material to new suffixed representation.
 
== Changes in semaphores ==
The game now supports semaphore profiles referenced from prefabs.
 
The characteristics of the semaphores are defined in <strong>semaphore_profile.sii</strong>. When locating the profile to use, the game locates unit named <strong>tr_sem_prof.&lt;profile_name&gt;.&lt;country_code&gt;</strong> and if that fails, it attempts to find <strong>tr_sem_prof.&lt;profile_name&gt;</strong>
 
Semaphore visualization models are defined in <strong>semaphore_model.sii</strong>. When locating the model to use, the game locates unit named <strong>tr_sem_mdl.&lt;profile_name&gt;.&lt;country_code&gt;</strong> and if that fails, it attempts to find <strong>tr_sem_mdl.&lt;profile_name&gt;</strong>
 
=== Semaphore prfiles ===
Most profile attributes are arrays. When applying a profile, semaphore IDs are used as indexes. Prefab semaphores must have their 'type' set to '(use profile)'.
 
If there is no value for some ID, the last value from the corresponding array attribute is used <ul>
<li><strong>model</strong> - array of tokens (suffixes of semaphore model names from <em>semaphore_model.sii</em> without country suffixes)</li>
<li><strong>type </strong>- array of enum values:
<ul>
<li><strong>barrier_distance - </strong>a barrier activated by proximity of an object (road crossings)</li>
<li><strong>barrier_manual - </strong>a barrier, which is closed until a condition is met (tollgates, gas stations)</li>
<li><strong>model_only - </strong>if set, the current instance will be only a visual representation of a real traffic semaphore</li>
<li><strong>traffic_light - </strong>standard traffic light</li>
<li><strong>traffic_light_blockable - </strong>traffic light which is blocked by passing vehicles (controlling of one-way road segments, e.g. roadworks)</li>
<li><strong>traffic_light_major - </strong>standard traffic light with a 'major road' sign</li>
<li><strong>traffic_light_minor - </strong>standard traffic light with a 'minor road' sign
</li></ul> </li>
<li><strong>interval </strong>- array of float4 values (Green, Orange, Red, Orange)</li>
<li><strong>cycle </strong>- array of float values (semaphore cycle shift)</li>
<li><strong>id_map</strong> - array of indexes <ul>
<li> in some cases (e.g. <em>model_only</em> types used for road crossings), multiple semaphores need to be linked to some other semaphore to ensure their synchronization
</li></ul> </li>
<li><strong>inherited</strong> - full name of the fallback profile (attributes not set in the current profile are taken from the inherited one)</li>
</ul>
 
== Changes in building models ==
New attributes <strong>min_scale</strong> and <strong>max_scale</strong> of the building_model unit can be used to randomize scale of the model. The <strong>model_size_override</strong> attribute is now obsolete and should be not used for new definitions.
 
New attribute <strong>rand_rot</strong> specifies maximal range in degrees by which can be the model randomly rotated along the vertical axis. The model will be rotated by random value in in <strong>&lt;-rand_rot/2;rand_rot/2&gt;</strong> from its default orientation (i.e. specifying 360 degress will give fully random rotation). To avoid visual errors on existing maps, do not set the attribute to non-zero value for models which are already used in the map.
 
== Changes in AI ==
The AI is now utilizing additional information defined in signs (see bellow) to control its behavior (e.g. speeds) so use of proper signs is important.
 
The sign_models defined in /dev/world/sign.sii now have a new optional attribute <strong>traffic_rule</strong> which references a rule defined in traffic_rules.sii specifying additional traffic-related semantics for that sign (e.g. speed limit).
 
Additional configuration file (/def/traffic_data.sii) was added which controls behavior of the AI. There are many attributes, which control the behavior of AI vehicles. However, since some of them can change or be removed in the near future, <strong>only attributes already in the configuration file are officially supported</strong>. More attributes will appear there in the near future.
 
Currently supported traffic attributes:
<ul>
<li> <em>max_vehicle_count</em> - maximum count of all active vehicles. Increasing it can lower the performance</li>
<li><em>max_truck_count</em> - maximum count of all active trucks. Increasing it can lower the performance</li>
<li><em>ai_safety_modifier</em> - modifies the general safety of AI behavior. Interval of possible values: &lt;-1.0; 1.0&gt;, where <em>-1.0</em> means 'minimum safety', <em>1.0</em> means 'maximum safety' and <em>0.0</em> means 'no change'
</li></ul>
 
The maximal speed of AI vehicles is now specified in new attribute <strong>max_speed</strong> of traffic_vehicle unit which is specified in km/h. The attribute <strong>speed</strong> is now obsolete and ignored.
 
The type of vehicle is now specified as enum-based attribute <strong>type</strong> which might have one from following values: <strong>car</strong>, <strong>truck</strong>, <strong>bus</strong>. The <strong>speed_class</strong> and <strong>use_truck_path</strong> attributes is now obsolete and ignored.
 
The vehicle shifting behavior is now described using a <strong>gearbox</strong> attribute. It allows defining different accelerations for different vehicle speeds: (speed [km/h], acceleration [m/s/s]) .
 
Default values:
 
<pre class="sii"># car default gearbox
gearbox[]: (0, 4.5)
gearbox[]: (20, 3.5)
gearbox[]: (45, 2.5)
gearbox[]: (70, 1.8)
gearbox[]: (100, 1.2)
 
# truck default gearbox
gearbox[]: (0, 1.26)
gearbox[]: (10, 1.06)
gearbox[]: (20, 0.89)
gearbox[]: (32, 0.74)
gearbox[]: (45, 0.61)
gearbox[]: (57, 0.49)
gearbox[]: (70, 0.40)
gearbox[]: (80, 0.33)
 
# bus default gearbox
gearbox[]: (0, 2.5)
gearbox[]: (15, 1.8)
gearbox[]: (25, 1.5)
gearbox[]: (50, 1.2)
gearbox[]: (70, 0.9)
</pre>
 
== Changes in prefabs ==
The new AI uses a modified format of the prefab with additional precomputed information. The game will automatically try to convert a previous format to the new one during load.
 
=== Basic structures - memory layout ===
<strong>WARNING: any information in this section can change without notice</strong>!
 
==== Navigation curves ====
<pre class="sii">struct ppd_curve_t
{
token_t name;
u32 flags;
u32 leads_to_nodes;
float3_t pos0;
float3_t pos1;
float3_t dir0;
float roll0;
float3_t dir1;
float roll1;
float length;
u32 next_curves[4];
u32 prev_curves[4];
u32 next_count;
u32 previous_count;
u32 tr_light_id;
float speed_limit; // obsolete, not used
};
</pre>
<strong>curve flags:</strong><br> <br> const unsigned PNCF_STOPPER = 0x00000001;<br> const unsigned PNCF_FORCE_NO_BLINKER = 0x00000004;<br> const unsigned PNCF_RIGHT_BLINKER = 0x00000008;<br> const unsigned PNCF_LEFT_BLINKER = 0x00000010;<br> const unsigned PNCF_SMALL_VEHICLES = 0x00000020;<br> const unsigned PNCF_LARGE_VEHICLES = 0x00000040;<br> const unsigned PNCF_PRIORITY_MASK = 0x000F0000;<br> const unsigned PNCF_PRIORITY_SHIFT = 16;<br> const unsigned PNCF_LOW_PROBABILITY = 0x00002000;<br> const unsigned PNCF_ADDITIVE_PRIORITY = 0x00008000;<br> <br> (other flags known from the previous version are obsolete)<br> <br> <strong>leads_to_nodes:</strong><br> <br> const unsigned PNLF_END_NODE_MASK = 0x000000FF;<br> const unsigned PNLF_END_NODE_SHIFT = 0;<br> const unsigned PNLF_END_LANE_MASK = 0x0000FF00;<br> const unsigned PNLF_END_LANE_SHIFT = 8;<br> const unsigned PNLF_START_NODE_MASK = 0x00FF0000;<br> const unsigned PNLF_START_NODE_SHIFT = 16;<br> const unsigned PNLF_START_LANE_MASK = 0xFF000000;<br> const unsigned PNLF_START_LANE_SHIFT = 24;
 
==== Traffic semaphores ====
<strong>NOTE: using semaphore profiles instead of setting per-instance attributes is strongly advised</strong>
<pre class="sii">struct ppd_tr_light_t
{
float3_t pos;
quat_t qrot;
u32 type;
u32 id;
float4_t intervals;
float cycle;
token_t profile;
u32 flags;
};
</pre>
<strong>semaphore types:</strong>
 
const unsigned TST_PROFILE = 0; // using values from semaphore_profile.sii instead of prefab<br>const unsigned TST_MODEL_ONLY = 1;<br>const unsigned TST_TRAFFIC_LIGHT = 2;<br>const unsigned TST_TRAFFIC_LIGHT_MINOR = 3;<br>const unsigned TST_TRAFFIC_LIGHT_MAJOR = 4;<br>const unsigned TST_BARRIER_MANUAL_TIMED = 5;<br>const unsigned TST_BARRIER_DISTANCE = 6;<br>const unsigned TST_TRAFFIC_LIGHT_BLOCKABLE = 7;
 
==== Intersections ====
<strong>intersections:</strong> <ul>
<li> <strong>INTERSECTION TYPES:</strong> <ul>
<li> <strong>start intersection</strong> - the point where two or more curves are leading from one locator <ul>
<li> automatically generated - no priority management
</li></ul> </li>
<li><strong>cross intersection</strong> - the point where two or more curves intersect <ul>
<li> non-zero priority modifiers have to be set for each intersecting curve
</li></ul> </li>
<li><strong>end intersection</strong> - the point where two or more curves are leading to one locator <ul>
<li> non-zero priority modifiers have to be set for each intersecting curve</li>
<li>a special case is <strong>lane merging</strong>: <ul>
<li> all curves have the same priority</li>
<li>vehicles will use 'zip merging' in this case
</li></ul>
</li></ul>
</li></ul>
</li></ul>
<pre class="sii">struct ppd_intersection_t
{
u32 curve_id;
float position;
float radius;
u32 flags;
};
</pre>
<strong>intersection flags:</strong><br> <br> const unsigned PIF_SIBLING_COUNT_MASK = 0x000000F0;<br> const unsigned PIF_SIBLING_COUNT_SHIFT = 4;<br> const unsigned PIF_TYPE_START = 0x00010000;<br> const unsigned PIF_TYPE_END = 0x00020000;
 
=== Important notes ===
<ul>
<li><strong>intersection structures must be generated for EVERY curve involved in an intersection</strong></li>
<li><strong>structures have to be stored in such way that the first structure contains the number of siblings (curves involved)</strong>
<ul><li><strong>all remaining siblings must immediately follow the first one and MUST HAVE THE NUMER OF SIBLINGS SET TO ZERO</strong></li></ul>
</li>
<li> <strong>AI vehicles now use prefab curves also for player movement prediction, which means<br></strong> <ul>
<li> make sure valid <strong>curves </strong>lead from/to all directions where player can drive (even if AI vehicles won't ever go there)</li>
<li>use correct <strong>blinker flags</strong> - the vehicles 'see' which blinker has the player turned on and predict its path accordingly</li>
<li>make sure there are <strong>prefab nodes</strong> in all directions where player can drive (e.g. dock entrances...) <ul>
<li> After modifying the prefab you can use "Prefab node correction" command in the replacement dialog (F3) to let the game to add the missing nodes.
</li></ul>
</li></ul>
</li></ul>
 
 
== Changes in editor ==
=== Batch renaming ===
The editor now supports a batch renaming of some types of objects based on config file. First you need to prepare configuration file describing the changes which should be applied (see bellow). Afterwards you need to load the map in the editor, press <strong>F3</strong> to open the replacement dialog, press the <strong>Batch replace</strong> button and confirm the change. Afterwards you should save and reload the map.
 
The operation requires that units for both the old and the new names exist during the operation so you will need to do the operation in separate steps by first adding units under the new names to the definitions, then doing the rename and afterwards removing the units with the old names from the definitions.
 
The configuration file must be stored as <strong>Documents\Euro Truck Simulator 2\replace.sii</strong>. The file must contain a single unit of type <strong>editor_search_replace</strong>. The unit contains string array attribute <strong>sectors</strong> which must contain names of all sectors in which to apply the changes. The sector name corresponds to base name of the files used to store that sector (e.g. sec+0001-0001). The unit also contains additional string array attributes which define the replacements. The format of the replacement string is "old_name|new_name". Following arrays are supported: <ul>
<li> <strong>ter_material</strong> - terrain materials</li>
<li><strong>road_material</strong> - road materials</li>
<li><strong>sidewalk_material</strong> - sidewalk materials</li>
<li><strong>bld_scheme</strong> - building schemes</li>
<li><strong>model</strong> - models</li>
<li><strong>vegetation</strong> - vegetations</li>
<li><strong>road_look</strong> - road looks</li>
<li><strong>ter_profile</strong> - terrain profiles</li>
<li><strong>railing</strong> - railings on roads</li>
<li><strong>sign</strong> - lamps/bollars along the road
</li></ul>
 
Example of replacement file
<pre class="sii">SiiNunit
{
editor_search_replace : .edit_replace
{
# List of sectors where the search replace should be performed
 
sectors[]: "sec-0002-0007"
sectors[]: "sec-0002-0008"
 
# Terrain material replacement old terrain material unit suffix | new terrain material unit suffix
 
ter_material[]: "24|121"
ter_material[]: "103|129"
 
# Building scheme replacement old scheme unit suffix | new scheme unit suffix
 
bld_scheme[]: "22|2sc"
 
# Model replacement old model unit suffix | new model unit suffix
 
model[]: "122|1sc"
model[]: "757|2sc"
model[]: "56a|3sc"
}
}
</pre>
 
=== Categories ===
New attribute <strong>category</strong> of model_def, sign_model, prefab_model and building_scheme units specifies a string with category to which the unit belongs. This can be used in respective editor dialogs to filter the set of the items to only items belonging to selected category.
 
=== Changes in signs ===
The signs now appear as a standalone items in the editor. If you have modified editor_data.sii, you need to update the sub_mode_types array to make the corresponding entry visible in the ui.
 
A new <strong>distance_type</strong> attribute was added to the sign definition (0 - short, 1 - close, 2 - middle, 3 - far). The <strong>short_distance</strong> attribute is now obsolete and ignored.
 
A new <strong>Follow road dir</strong> checkbox was added to the Sign properties. It aligns the sign orientation according to the near road and to keep relative position when the road moves.

Navigation menu