Changes

Games/ETS2/Modding guides/1.9

16,545 bytes added, 11:03, 11 February 2016

no edit summary

<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 not 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 /def/ferry/<name>.sii files, the game will also load all files from /def/ferry/connection. Each from those files should contain a single ferry_connection unit (see example bellow) which defines connection between two ferries and must be named conn.<from>.<to> where from and to 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 <from>_<to>.sii (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 /def/ferry/connection/europoort_harwich.sii

<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> traffic_density_coef <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>traffic_density_range <ul>

<li>default value is 2000.0</li>

<li>sets the maximum range beyond city border 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>

== Changes in road looks ==

The roads now support specifying different number of lanes in left and right part. They are defined using new lane_count_left and lane_count_right attributes. The ai_lane_count and one_way attributes are now obsolete. To keep backward compatibility with existing definitions, the game will override the value of the new attributes if ai_lane_count or one_way 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 ai_road_offset and actor_lane_count attributes are obsolete and ignored.

The ai_speed_type 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 ( road_material.sii and road_sidewalk.sii) which support the .<idofyourmod>.sii convention and suffixed/prefixed unit names. The values of the corresponding arrays inside road.sii 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 terrain_material.sii was changed to allow independent addition The .<idofyourmod>.sii 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 semaphore_profile.sii. When locating the profile to use, the game locates unit named tr_sem_prof.<profile_name>.<country_code> and if that fails, it attempts to find tr_sem_prof.<profile_name>

Semaphore visualization models are defined in semaphore_model.sii. When locating the model to use, the game locates unit named tr_sem_mdl.<profile_name>.<country_code> and if that fails, it attempts to find tr_sem_mdl.<profile_name>

=== 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>model - array of tokens (suffixes of semaphore model names from semaphore_model.sii without country suffixes)</li>

<li>type - array of enum values:

<ul>

<li>barrier_distance - a barrier activated by proximity of an object (road crossings)</li>

<li>barrier_manual - a barrier, which is closed until a condition is met (tollgates, gas stations)</li>

<li>model_only - if set, the current instance will be only a visual representation of a real traffic semaphore</li>

<li>traffic_light - standard traffic light</li>

<li>traffic_light_blockable - traffic light which is blocked by passing vehicles (controlling of one-way road segments, e.g. roadworks)</li>

<li>traffic_light_major - standard traffic light with a 'major road' sign</li>

<li>traffic_light_minor - standard traffic light with a 'minor road' sign

</li></ul> </li>

<li>interval - array of float4 values (Green, Orange, Red, Orange)</li>

<li>cycle - array of float values (semaphore cycle shift)</li>

<li>id_map - array of indexes <ul>

<li> in some cases (e.g. model_only types used for road crossings), multiple semaphores need to be linked to some other semaphore to ensure their synchronization

</li></ul> </li>

<li>inherited - 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 min_scale and max_scale of the building_model unit can be used to randomize scale of the model. The model_size_override attribute is now obsolete and should be not used for new definitions.

New attribute rand_rot 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 <-rand_rot/2;rand_rot/2> 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 traffic_rule 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, only attributes already in the configuration file are officially supported. More attributes will appear there in the near future.

Currently supported traffic attributes:

<ul>

<li> max_vehicle_count - maximum count of all active vehicles. Increasing it can lower the performance</li>

<li>max_truck_count - maximum count of all active trucks. Increasing it can lower the performance</li>

<li>ai_safety_modifier - modifies the general safety of AI behavior. Interval of possible values: <-1.0; 1.0>, where -1.0 means 'minimum safety', 1.0 means 'maximum safety' and 0.0 means 'no change'

</li></ul>

The maximal speed of AI vehicles is now specified in new attribute max_speed of traffic_vehicle unit which is specified in km/h. The attribute speed is now obsolete and ignored.

The type of vehicle is now specified as enum-based attribute type which might have one from following values: car, truck, bus. The speed_class and use_truck_path attributes is now obsolete and ignored.

The vehicle shifting behavior is now described using a gearbox 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 ===

WARNING: any information in this section can change without notice!

==== 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>

curve flags: const unsigned PNCF_STOPPER = 0x00000001; const unsigned PNCF_FORCE_NO_BLINKER = 0x00000004; const unsigned PNCF_RIGHT_BLINKER = 0x00000008; const unsigned PNCF_LEFT_BLINKER = 0x00000010; const unsigned PNCF_SMALL_VEHICLES = 0x00000020; const unsigned PNCF_LARGE_VEHICLES = 0x00000040; const unsigned PNCF_PRIORITY_MASK = 0x000F0000; const unsigned PNCF_PRIORITY_SHIFT = 16; const unsigned PNCF_LOW_PROBABILITY = 0x00002000; const unsigned PNCF_ADDITIVE_PRIORITY = 0x00008000; (other flags known from the previous version are obsolete) leads_to_nodes: const unsigned PNLF_END_NODE_MASK = 0x000000FF; const unsigned PNLF_END_NODE_SHIFT = 0; const unsigned PNLF_END_LANE_MASK = 0x0000FF00; const unsigned PNLF_END_LANE_SHIFT = 8; const unsigned PNLF_START_NODE_MASK = 0x00FF0000; const unsigned PNLF_START_NODE_SHIFT = 16; const unsigned PNLF_START_LANE_MASK = 0xFF000000; const unsigned PNLF_START_LANE_SHIFT = 24;

==== Traffic semaphores ====

NOTE: using semaphore profiles instead of setting per-instance attributes is strongly advised

<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>

semaphore types:

const unsigned TST_PROFILE = 0; // using values from semaphore_profile.sii instead of prefab const unsigned TST_MODEL_ONLY = 1; const unsigned TST_TRAFFIC_LIGHT = 2; const unsigned TST_TRAFFIC_LIGHT_MINOR = 3; const unsigned TST_TRAFFIC_LIGHT_MAJOR = 4; const unsigned TST_BARRIER_MANUAL_TIMED = 5; const unsigned TST_BARRIER_DISTANCE = 6; const unsigned TST_TRAFFIC_LIGHT_BLOCKABLE = 7;

==== Intersections ====

intersections: <ul>

<li> INTERSECTION TYPES: <ul>

<li> start intersection - the point where two or more curves are leading from one locator <ul>

<li> automatically generated - no priority management

</li></ul> </li>

<li>cross intersection - 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>end intersection - 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 lane merging: <ul>

<li> all curves have the same priority</li>

<li>vehicles will use 'zip merging' in this case

</li></ul>

<pre class="sii">struct ppd_intersection_t

{

u32 curve_id;

float position;

float radius;

u32 flags;

};

</pre>

intersection flags: const unsigned PIF_SIBLING_COUNT_MASK = 0x000000F0; const unsigned PIF_SIBLING_COUNT_SHIFT = 4; const unsigned PIF_TYPE_START = 0x00010000; const unsigned PIF_TYPE_END = 0x00020000;

<h5><a name="*Important Notes:*"></a> Important Notes: </h5> <ul>

<li>intersection structures must be generated for EVERY curve involved in an intersection</li>

<li>structures have to be stored in such way that the first structure contains the number of siblings (curves involved)

<ul><li>all remaining siblings must immediately follow the first one and MUST HAVE THE NUMER OF SIBLINGS SET TO ZERO</li></ul>

</li>

<li> AI vehicles now use prefab curves also for player movement prediction, which means <ul>

<li> make sure valid curves lead from/to all directions where player can drive (even if AI vehicles won't ever go there)</li>

<li>use correct blinker flags - the vehicles 'see' which blinker has the player turned on and predict its path accordingly</li>

<li>make sure there are prefab nodes 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>

50keda

Bureaucrats, Administrators

1,740

edits

Changes

Games/ETS2/Modding guides/1.9

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Contents

Tools & Shortcuts

Other SCS Links

Tools

MediaWiki