Games/ETS2/Modding guides/1.30

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
• Try to save it. The save might report error because of conflict between compounds. In that case check the game log without exiting the game (so you can easily repeat the save). If the log contains compound errors, you can fix them in the following way:
  • "Compound X contains item Y which also exists as independent one" - use the g_delete_uid Y console command to delete the item.
  • "Duplicate item X found in compounds:" - use the find dialog to find one from the compounds and dismiss it (using item properties). This will turn this into the previous case where compound conflicts with independent items.
• Do rebuild (F8)
• Save map

Changes

New Navigation Data

New navigation algorithm uses detailed info from traffic lanes so it can take lane counts, direction and other things into consideration. Be careful to have correct navigation data in map. For example if crossing prefab does not have a AI lane for right turn, the navigation will not turn right even if that means that it will find a much longer path.

The map_data unit in /def/map_data.sii contains a few attributes which can be used used to tweak the routing heuristic and the estimated driving time.

General values used by navigation:

• navigation_maximum_speed (25.0) - Maximum reasonable speed used for navigation computations (in m/s). Keep it small to improve efficiency of the search.
• navigation_turn_back_length (400000.0) - Length of artificial connections representing u-turn not allowed by AI lines.
• navigation_prefer_small_wide_road_penalty (10.0) - Penalty applied to roads with more than one lane in a direction when using prefer_small_roads routing mode. Multiplicative.
• navigation_special_prefab_additive_penalty (0.0) - Penalty in meters applied to paths going over special prefabs (e.g. gas stations) outside cities. Additive. Generally should be left at zero unless no gas/weight station prefab used in map includes normal road in addition to the gas station area.
• navigation_special_prefab_additive_penalty_city (0.0) - Penalty in meters applied to paths going over special prefabs (e.g. gas stations) in cities. Additive. Usually should be left at zero, see navigation_special_prefab_additive_penalty.
• navigation_gps_avoid_additive_penalty (20000.0) - Penalty in meters applied to paths going over roads or prefabs marked as "GPS Avoid". Additive.

Weights used for path finding in prefer_shorter routing mode.

• navigation_city_penalty (1.0) - Penalty applied to paths through city area. Multiplicative
• navigation_slow_road_penalty (5.0) - Penalty applied to paths through slow time area. Multiplicative

Weights used for path finding in best routing mode:

• navigation_narrow_road_max_speed_usage (0.8) - Portion of maximal speed to use on narrow roads.
• navigation_road_max_speed_usage (0.9) - Portion of maximal speed to use on normal roads.
• navigation_city_or_slowtime_speed_penalty (0.25) - Penalty applied to speed when driving through city or slow time area. Multiplicative.
• navigation_semaphore_wait_duration (90.0) - Time cost of going through semaphore in game-time seconds.
• navigation_stop_wait_duration (60.0) - Time cost of going through stop sign in game-time seconds.
• navigation_turn_own_side_duration (15.0) - Time cost of turning to the own side (e.g. right in USA/continental, left in UK). Additive.
• navigation_turn_oposite_side_duration (45.0) - Time cost of turning to the oposite side (e.g. left in USA/continental, right in UK). Additive.

Weights used for time evaluation:

• navigation_time_narrow_road_max_speed_usage (0.8) - Portion of maximal speed to use on narrow roads - time calculation.
• navigation_time_road_max_speed_usage (0.9) - Portion of maximal speed to use on normal roads - time calculation.
• navigation_time_city_or_slowtime_speed_penalty (0.85) - Penalty applied to speed when driving through city or slow time area - time calculation. Multiplicative.
• navigation_time_semaphore_wait_duration (60.0) - Time cost of going through semaphore in game-time seconds - time calculation.
• navigation_time_stop_wait_duration (30.0f) - Time cost of going through stop sign in game-time seconds - time calculation.
• navigation_time_turn_own_side_duration (10.0f) - Time cost of turning to the own side (e.g. right in USA/continental, left in UK) - time calculation. Additive.
• navigation_time_turn_oposite_side_duration (30.0) - Time cost of turning to the oposite side (e.g. left in USA/continental, right in UK) - time calculation. Additive.

A road items in editor can be marked with "GPS Avoid" flag. This will cause the navigation to apply a huge penalty to paths using this road. There is no such flag for prefab items however prefab_model definition supports a gps_avoid attribute which will enable it for all uses of that prefab in map.

Prefabs

The prefab format was changed to include separate data for use by the new navigation. The game should be able to automatically convert old prefabs with correctly formed AI lines and new version of conversion tools will generate them automatically.

Format changes

The new format adds navigational nodes. They are derived from both normal prefab nodes and AI curves. Each navigational node corresponds to either normal node or to end point of AI curve. Basically it is a simplified graph over AI curves representing places important for the navigation (e.g. for of AI lane) to reduce the size of the navigational graph.

The table of navigational nodes is stored in the same way as other tables. Offset and size of this table is stored directly after matching fields for intersection table.

Each navigational node has the following format

u8 type; // Type of node. 0 = physical node, 1 = AI curve
u16 index; // Depending on the type it is either index of normal node or index of AI curve to whose ending point this nav node corresponds
u8 connection_count; // Number of outgoing connections leading to other navigational nodes (0-4)
connection_info connections[4]; // Information about those connections. First connection_count entries are used. Rest is set to {0xffff, MAX_FLOAT, 0, 0xffff[8]}

Each connection info structure has the following format

u16 target_node; // Index of navigational node this connection leads to
float length; // Length of the connection in meters
u8 curve_count; // Number of AI curves the connection is created from, limited to 8, if more would be necessary, insert additional nav node
u16 curve_indices[8]; // Indices of the relevant AI curves in order they should be used. First curve_count entries are used, reset is set to 0xffff.

Additionally the AI curve structure was changed by adding a u32 value at its end. This value contains index of a navigational node which should be used if navigation starts from that AI curve or 0xffffffff if there is none. Basically it is a reverse mapping to the curve_indices from from nodes.

Flares Data

Flare blink unit (usually found as hookup defined models inside /unit/hookup directory) was reworked to use blinking pattern instead of just simple ON and OFF delays. Thus blink_delay_on and blink_delay_off attributes were removed and replaced with blink_pattern and blink_step_length. Unit is now defined as follows:

SiiNunit
{
flare_blink : flare.model.my_blink
{
	dir_type: wide

	blink_pattern: "X--"     # String of X and - characters, where X represents ON state and - represents OFF state.
	blink_step_length: 0.5   # Float representing duration of one step inside blink pattern in seconds.
	
	model: "/model/flare/my_flare.pmd"
}
}

Consequentially flare blink sync inherited attributes and behavior from flare blink unit and has the same two new attributes: blink_pattern and blink_step_length.

Time Zones Data

Time zones are (for now) country based. Each country has defined time_zone (integer, in minutes) and time_zone_name (string). Eg. pacific daylight time is -420 minutes with "PDT" name.

In addition there is default timezone, stored in economy_data unit (default_time_zone, default_time_zone_name), this is zone basic game time is expected int and its used every time where relevant spatial location and thus time zone is not known.

Economy Data

Some old values has been exported to economy_data unit (/def/economy_data.sii) attributes:

• tow_price_base (150.0)
• tow_price_factor (0.4)
• tow_time_base (1800.0)
• tow_time_factor (3.0)
• tow_fuel_ratio (0.3)
• truck_scales_cost (10)

Traffic

There were several changes in traffic-related data. Due to their nature, some of them have no backward compatibility provided, so please check your mods for potential problems. You shouldn't have any problems if the corresponding definitions are not modded.

Traffic lane data

All traffic lane properties (defined in: /def/world/traffic_lane.sii) are now defined through a set of traffic rules (see #Traffic rules) instead of having specific attributes for certain functions. This allows combining various 'functions' (e.g. road lines, access for vehicle types, spawning...) into traffic lanes without the need of specific attributes.

Note: There are no 'default traffic rules' defined for traffic lanes. All needed properties must be defined for each lane type manually.

Example of lane with local road speed class, spawn rules for multiple vehicle types and 'overtaking allowed' rule:

traffic_lane_data : traffic_lane.road.local
{
   speed_class: local_road
   traffic_rules[]: traffic_rule.road      # Allow access for road vehicles
   traffic_rules[]: traffic_rule.s_car_l
   traffic_rules[]: traffic_rule.s_truck_l
   traffic_rules[]: traffic_rule.s_bus_l
   traffic_rules[]: traffic_rule.s_police
   traffic_rules[]: traffic_rule.overtake_alw   # Allow overtaking (including 'wrong way')
}

Example of a traffic lane with only trucks allowed to spawn or enter it:

traffic_lane_data : traffic_lane.road.freeway.truck_lane
{
   speed_class: freeway
   traffic_rules[]: traffic_rule.s_truck_h
   traffic_rules[]: traffic_rule.trucks_only
}

Example of a traffic lane with no rules (i.e. no spawning and no vehicle access):

traffic_lane_data : traffic_lane.no_vehicles
{
   speed_class: local_road
}

Traffic lane data in road looks

All road look traffic-related properties are defined through traffic lanes (see #Traffic lane data). To define different lane configurations for various road template variants, you can use template_variants_left and template_variants_right attributes.

Example of a road look for 1+1 lane road. Only some template variants (with broken or no road lines) allow overtaking:

road_look : road.template0 {
   name:          "ca 1x1 country small border tmpl"
   template_right:      "/road_template/ca_nv/ca_1x1_small_border.pmd"


   lanes_left[]:   traffic_lane.road.local.no_overtake
   lanes_right[]:   traffic_lane.road.local.no_overtake

   template_variants_right[]: .tmpl_var.road.template0

   compatible_edges_right[]: "shldr_1m"
   compatible_edges_right[]: "shldr_05m"
   compatible_edges_right[]: "shldr_1m2"
   compatible_edges_right[]: "sw_kerb"
   compatible_edges_right[]: "sw_4m_a"
   compatible_edges_right[]: "sw_4m_c"

   shoulder_space_left:      1.0
   shoulder_space_right:      1.0

}
road_template_variant : .tmpl_var.road.template0
{
   variant_names[]: "no_lines"
   variant_names[]: "lines_broken"

   lanes_left[]:   traffic_lane.road.local
   lanes_right[]:   traffic_lane.road.local
}

Example of a freeway road look with one 'truck lane' variant and one variant with lane changing disabled at the outermost lane:

road_look : road.us_tmpl13 {
	name: 			"us 0-3 freeway tmpl"
	template_right:		"/road_template/us/us_3_freeway_one_way.pmd"

	lanes_right[]:	traffic_lane.road.freeway
	lanes_right[]:	traffic_lane.road.freeway
	lanes_right[]:	traffic_lane.road.freeway
	template_variants_right[]: .tmpl_var.road.us_tmpl13
	template_variants_right[]: .tmpl_var2.road.us_tmpl13
	compatible_edges_right[]: "sh"
	shoulder_space_right:		3.0
}
road_template_variant : .tmpl_var.road.us_tmpl13
{
	variant_names[]: "truck_lane"
	lanes_right[]:	traffic_lane.road.freeway
	lanes_right[]:	traffic_lane.road.freeway
	lanes_right[]:	traffic_lane.road.freeway.truck_lane
}
road_template_variant : .tmpl_var2.road.us_tmpl13
{
	variant_names[]: "brd_brk_ful"
	lanes_right[]:	traffic_lane.road.freeway
	lanes_right[]:	traffic_lane.road.freeway.full_out
	lanes_right[]:	traffic_lane.road.freeway.full_in
}

Traffic rules

Priority modifier

The third parameter for priority modifier traffic rules (rule: "priority") has been changed. The old definitions will not work correctly, as no backward compatibility is provided.

Example of two most common priority rules:

traffic_rule_data : traffic_rule.major_road
{
	name: "Priority road"
	rule: "priority"
	num_params[]: -1	# no prirority value change
	num_params[]: 0		# not additive
	num_params[]: 2		# type 'priority_road'
}
traffic_rule_data : traffic_rule.minor_road
{
	rule: "priority"
	num_params[]: -1 	# no prirority value change
	num_params[]: 0		# not additive
	num_params[]: 1		# type 'give_way'
}

Spawn density

The way of defining spawn density has been completely redesigned. The old definitions will not work correctly, as no backward compatibility is provided.

Instead of defining spawn coefficients, it is now possible to define traffic density flow during the day for each vehicle type separately. For better readability, all density related rules were added to traffic_rules_spawn.suiand included from traffic_rules.sii

Note: When applying a traffic density rule for the same vehicle type through both: traffic lane (see #Traffic lane data) and a traffic area item, then the traffic area rule overrides the lane rule.

Example of a car spawn density flow ('low density' version):

traffic_rule_data : traffic_rule.s_car_l
{
	# name: "Spawn density car low"
	rule: "density"
	str_params[]: "car"
	num_params[]: 7.0	# 7:00
	num_params[]: 0.15	# frequency
	num_params[]: 10	# count limit
	num_params[]: 17.0	# 17:00
	num_params[]: 0.1	# frequency
	num_params[]: 10	# count limit
	num_params[]: 0.0	# 00:00
	num_params[]: 0.05	# frequency
	num_params[]: 3		# count limit
}

Example of train spawn density (constant):

traffic_rule_data : traffic_rule.s_train_c
{
	# name: "Spawn density cargo train"
	rule: "density"
	str_params[]: "train_cargo"
	num_params[]: 0.0	# 00:00
	num_params[]: 0.03	# frequency
	num_params[]: 2		# count limit
}