Open main menu
SCS Modding Wiki β

Games/ATS/Modding guides/1.29

< Games‎ | ATS/Modding guides
Revision as of 07:09, 10 November 2017 by Max (talk | contribs)

Contents

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
  • If the load failed because of some removed templates (e.g. road look us_tmpl5), copy corresponding definitions from previous versions.
  • Try to save it. The save might fail 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
  • Run shoulder check from "Map\Validate road shoulders" This will generate list of all items which could cause issues with random events (mostly models clipping through). You have following options:
    • Adjust the items so they do not cause issues by moving them or removing them
    • Mark the related road as having blocked shoulder ("Shoulder blocked" checkboxes in Road item properties) to prevent generation of events.
    • If you do not care about the issues, you can ignore the item.
  • Save map

Changes

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

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
}
Retrieved from "https://modding.scssoft.com/index.php?title=Games/ATS/Modding_guides/1.29&oldid=3385"